tcp實(shí)現(xiàn)中tcp_incr_quickack()函數(shù)的問題

IanFang

tcp_input.c里面有如下定義：
static void tcp_incr_quickack(struct tcp_opt *tp)
{
        unsigned quickacks = tp->rcv_wnd/(2*tp->ack.rcv_mss);

        if (quickacks==0)
                quickacks=2;
        if (quickacks > tp->ack.quick)
                tp->ack.quick = min(quickacks, TCP_MAX_QUICKACKS);
}

ack.quick的意義是不是啟動(dòng)快速重傳時(shí)所要接收到的dup ack的個(gè)數(shù)？
如果是的話為什么ack.quick的值要用tp->rcv_wnd和tp->ack.rcv_mss去估算？
我覺得應(yīng)該是用tp->snd_wnd和tp->mss_cache去估算，因?yàn)檫@個(gè)ack的個(gè)數(shù)應(yīng)視接收端能容納的數(shù)據(jù)

段來定，如果接受端窗口容納不了這么多段的數(shù)據(jù)，那根本不可能有這如此數(shù)目的重復(fù)ack發(fā)過來，

因此也就不能觸發(fā)快速重傳算法。（內(nèi)核版本2.4.22)

十分不解，請高手指點(diǎn)。謝謝。

lmarsin

struct {...} icsk_ack

延時(shí)確認(rèn)控制數(shù)據(jù)塊，以下是對各字段的簡要描述。

__u8 pending

標(biāo)識當(dāng)前需發(fā)送確認(rèn)的緊急程度和狀態(tài)。在數(shù)據(jù)從內(nèi)核空間復(fù)制到用戶空間時(shí)會檢測該狀態(tài)，如果需要?jiǎng)t立即發(fā)送確認(rèn)；而在計(jì)算rcv_mss時(shí)，會根據(jù)情況調(diào)整此狀態(tài)。由于pending是按位存儲的，因此多個(gè)狀態(tài)可以同時(shí)存在。

pending	描述
ICSK_ACK_SCHED	有ACK需要發(fā)送，是立即發(fā)送還是延時(shí)發(fā)送，還需要看其他標(biāo)志，也是能否發(fā)送確認(rèn)的前提。在接收到有負(fù)荷的TCP段后，會設(shè)置該標(biāo)志。
ICSK_ACK_TIMER	延時(shí)發(fā)送ACK定時(shí)器已經(jīng)啟動(dòng)。
ICSK_ACK_PUSHED	只要有ACK需要發(fā)送，并且pingpong為0時(shí)，ACK可以立即發(fā)送。
ICSK_ACK_PUSHED2	只要有ACK需要發(fā)送，都可以立即發(fā)送，不管是否在快速發(fā)送模式中。

__u8 quick

標(biāo)識在快速發(fā)送確認(rèn)模式中，可以快速發(fā)送ACK段的數(shù)量。與pingpong一同作為判斷是否在快速發(fā)送確認(rèn)模式下的條件，如果要延時(shí)發(fā)送確認(rèn)，則必須要在延時(shí)發(fā)送確認(rèn)模式下。

__u8 pingpong

標(biāo)識啟用或禁用快速確認(rèn)模式。通過TCP_QUICKACK選項(xiàng)可以設(shè)置其值。

pingpong	描述
0	不延時(shí)ACK段的發(fā)送，而是進(jìn)行快速發(fā)送。
1	將會延時(shí)發(fā)送ACK。

在快速確認(rèn)模式下，會立即發(fā)送ACK。整個(gè)TCP處理過程中，如果需要還會進(jìn)入到正常模式運(yùn)行，也就是說，這個(gè)標(biāo)志的設(shè)置不是永久性的，而只是在當(dāng)時(shí)啟用/禁用快速確認(rèn)模式，在這之后，根據(jù)如延時(shí)確認(rèn)超時(shí)、數(shù)據(jù)傳輸因素等，有可能會再次進(jìn)入或離開快速確認(rèn)模式。

__u8 blocked

軟中斷和用戶進(jìn)程是不能同時(shí)占有鎖定套接口的，因此如果套接口已被用戶進(jìn)程鎖定，而此時(shí)延時(shí)ACK定時(shí)器被觸發(fā)，在邏輯上說此時(shí)應(yīng)該發(fā)送ACK，但由于套接口被用戶進(jìn)程鎖定了不能訪問，因此只能置blocked標(biāo)志為1，表示“套接口被用戶進(jìn)程鎖定了，現(xiàn)不能發(fā)送ACK，如果有機(jī)會立即發(fā)送ACK”，這些機(jī)會包括接收到數(shù)據(jù)之后和將數(shù)據(jù)復(fù)制到用戶空間之后。

__u32 ato

用來計(jì)算延時(shí)確認(rèn)的估值，在接收到TCP段時(shí)會根據(jù)本次與上次接收的時(shí)間間隔來調(diào)整該值，而在設(shè)置延時(shí)確認(rèn)定時(shí)器時(shí)也會根據(jù)條件調(diào)整該值。

unsignedlong timeout

當(dāng)前的延時(shí)確認(rèn)時(shí)間，超時(shí)后會發(fā)送ACK。

__u32 lrcvtime

標(biāo)識最近一次接收到數(shù)據(jù)包的時(shí)間。

__u16 last_seg_size

最后一個(gè)接收到的段的長度，用來計(jì)算rcv_mss。

__u16 rcv_mss

由最近接收到段計(jì)算出的MSS，主要用來確定是否執(zhí)行延時(shí)確認(rèn)。

lmarsin

TCP接收到數(shù)據(jù)后，需發(fā)送相應(yīng)的確認(rèn)，但如果只是為了確認(rèn)就發(fā)送一個(gè)段，這樣會增加不必要的網(wǎng)路流量，而解決這個(gè)問題的最好方法就是延遲確認(rèn)，因?yàn)?/font>ACK不占用TCP段資源，因此可以將ACK與數(shù)據(jù)一起發(fā)送給對端。因此TCP使用兩種模式來處理確認(rèn)接收到的數(shù)據(jù)，即快速確認(rèn)和延遲確認(rèn)。在整個(gè)TCP發(fā)送和接收過程中，由于網(wǎng)絡(luò)擁塞、接收到小包等原因會在快速確認(rèn)和延遲確認(rèn)模式之間切換。

當(dāng)TCP進(jìn)入延遲確認(rèn)模式，通常接收到兩個(gè)TCP段產(chǎn)生一個(gè)確認(rèn)或者延遲在0.5秒之內(nèi)產(chǎn)生一個(gè)確認(rèn)。

盡管代碼中也有檢測是否在快速確認(rèn)模式的函數(shù)，但事實(shí)上確定使用快速確認(rèn)還是延遲確認(rèn)有些復(fù)雜，存在多個(gè)條件。在以下任何一種情況都會導(dǎo)致快速確認(rèn)：

1)在FIN_WAIT_1和FIN_WAIT_2狀態(tài)下接收到FIN；

2)在SYN_SENT狀態(tài)下，PAWS校驗(yàn)失敗或接收到已確認(rèn)的段，發(fā)送DACK；

3)在接收的慢速路徑處理中，PAWS校驗(yàn)失敗或收到已確認(rèn)的段，發(fā)送DACK；

4)接收到多個(gè)全尺寸的段且接收窗口的右端已更新；

5)快速確認(rèn)模式下；

6)亂序TCP段隊(duì)列中還有待處理段；

7)連續(xù)接收到2個(gè)小包，即小于536字節(jié)的段；

IanFang

謝謝lmarsin ，我偏得有點(diǎn)遠(yuǎn)了。。呵呵