在TCP協(xié)議與”流”通信中，我們建立了滑窗(sliding window)的基本概念。通過滑窗與ACK的配合，我們一方面實(shí)現(xiàn)了TCP傳輸?shù)目煽啃?，另一方面也一定程度上提高了效率。其工作方式如下面的視頻所示：
視頻鏈接：http://v.youku.com/v_show/id_XNDg1NDUyMDUy.html
然而，之前的解釋只是概念性的。TCP為了達(dá)到更好的傳輸效率，對(duì)上面的工作方式進(jìn)行了許多改進(jìn)。The devil is in the details.?我們需要深入到細(xì)節(jié)，才能看清楚TCP協(xié)議的智慧所在。
累計(jì)ACK
在TCP連接中，我們通過將ACK回復(fù)“附著”在其他數(shù)據(jù)片段的方式，減少了ACK回復(fù)所消耗的流量。但這并不是全部的故事。TCP協(xié)議并不是對(duì)每個(gè)片段都發(fā)送ACK回復(fù)。TCP協(xié)議實(shí)際采用的是累計(jì)ACK回復(fù)(accumulative acknowledgement)。接收方往往利用一個(gè)ACK回復(fù)來知會(huì)連續(xù)多個(gè)片段的成功接收。通過累計(jì)ACK，所需要的ACK回復(fù)通常可以降到50%。
如下圖所示，橙色為已經(jīng)接收的片段。方框?yàn)榛?，滑窗可容納3個(gè)片段。
累計(jì)ACK
滑窗還沒接收到片段7時(shí)，已接收到片段8，9。這樣就在滑窗中制造了一個(gè)“空穴”(hole)。當(dāng)滑窗最終接收到片段7時(shí)，滑窗送出一個(gè)回復(fù)號(hào)為10的ACK回復(fù)。發(fā)送方收到該回復(fù)，會(huì)意識(shí)到，片段10之前的片段已經(jīng)按照次序被成功接收。整個(gè)過程中節(jié)約了片段7和片段8所需的兩個(gè)ACK回復(fù)。
此外，接收方在接收到片斷，并應(yīng)該回復(fù)ACK的時(shí)候，會(huì)故意延遲一些時(shí)間。如果在延遲的時(shí)間里，有后續(xù)的片段到達(dá)，就可以利用累計(jì)ACK來一起回復(fù)了。
滑窗結(jié)構(gòu)
在之前的討論中，我們以片段為單位，來衡量滑窗的大小的。真實(shí)的滑窗是以byte為單位表示大小，但這并不會(huì)對(duì)我們之前的討論造成太大的影響。
發(fā)送方滑窗可以分為下面兩個(gè)部分。offered window為整個(gè)滑窗的大小。
接收方滑窗可分為三個(gè)部分：
可以看到，接收方的滑窗相對(duì)于發(fā)送方的滑窗多了一個(gè)“Received; ACKed; Not Sent to Proc”的部分。接收方接收到的文本流必須等待進(jìn)程來讀取。如果進(jìn)程正忙于做別的事情，那么這些文本流即使已經(jīng)正確接收，還是需要暫時(shí)占用接收緩存。當(dāng)出現(xiàn)上述占用時(shí)，滑窗的可用部分(也就是圖中advertised window)就會(huì)縮水。這意味著接收方的處理能力下降。如果這個(gè)時(shí)候發(fā)送方依然按照之前的速率發(fā)送數(shù)據(jù)給接收方，接收方將無力接收這些數(shù)據(jù)。
流量控制
TCP協(xié)議會(huì)根據(jù)情況自動(dòng)改變滑窗大小，以實(shí)現(xiàn)流量控制。流量控制(flow control)是指接收方將advertised window的大小通知給發(fā)送方，從而指導(dǎo)發(fā)送方修改offered window的大小。接收方將該信息放在TCP頭部的window size區(qū)域：
發(fā)送方在收到window size的通知時(shí)，會(huì)調(diào)整自己滑窗的大小，讓offered window和advertised window相符。這樣，發(fā)送窗口變小，文本流發(fā)送速率降低，從而減少了接收方的負(fù)擔(dān)。
零窗口
advertised window大小有可能變?yōu)?，這意味著接收方的接收能力降為0。發(fā)送方收到大小為0的advertised window通知時(shí)，停止發(fā)送。
零窗口
當(dāng)接收方經(jīng)過處理，再次產(chǎn)生可用的advertised window時(shí)，接收方會(huì)通過純粹的ACK回復(fù)來通知發(fā)送方，讓發(fā)送方恢復(fù)發(fā)送。然而，ACK回復(fù)的傳送并不是可靠的。如果該ACK回復(fù)丟失，那么TCP傳輸將陷入死鎖(deadlock)狀態(tài)。
為此，發(fā)送方會(huì)在零窗口后，不斷探測(cè)接收方的窗口。窗口探測(cè)(window probe)時(shí)，發(fā)送方會(huì)向接收方發(fā)送包含1 byte文本流的TCP片段，并等待ACK回復(fù)(該ACK回復(fù)包含有window size)。由于有1 byte的數(shù)據(jù)存在，所以該傳輸是可靠的，而不用擔(dān)心ACK回復(fù)丟失的問題。如果探測(cè)結(jié)果顯示窗口依然為0，發(fā)送方會(huì)等待更長(zhǎng)的時(shí)間，然后再次進(jìn)行窗口探測(cè)，直到TCP傳輸恢復(fù)。
白癡窗口綜合癥
滑窗機(jī)制有可能犯病，比如白癡窗口綜合癥 (Silly Window Syndrome)。假設(shè)這樣一種情形：接收方宣布(advertise)一個(gè)小的窗口，發(fā)送方根據(jù)advertised window，發(fā)送一個(gè)小的片段。接收方的小窗口被填滿，經(jīng)過處理，接收方再宣布一個(gè)小的窗口…… 這就是“白癡窗口綜合癥”：TCP通信的片段中包含的數(shù)據(jù)量很小。在這樣的情況下，TCP通信的片段所含的信息都很小，網(wǎng)絡(luò)流量主要是TCP片段的頭部，從而造成流量的浪費(fèi) (由于TCP頭部很大，我們希望每個(gè)TCP片段中含有比較多的數(shù)據(jù))。
如果發(fā)送方不斷發(fā)送小的片段，也會(huì)造成“白癡窗口”。為了解決這個(gè)問題，需要從兩方面入手。TCP中有相關(guān)的規(guī)定，要求：
1. 接收方宣告的窗口必須達(dá)到一定的尺寸，否則等待。
2. 除了一些特殊情況，發(fā)送方發(fā)送的片段必須達(dá)到一定的尺寸，否則等待。特殊情況主要是指需要最小化延遲的TCP應(yīng)用(比如命令行互動(dòng))。
總結(jié)
累計(jì)ACK減少了TCP傳輸過程中所需的ACK流量。通過流量管理，TCP連接兩端的工作能力可以匹配，從而減少不不要的傳輸浪費(fèi)。累計(jì)ACK和流量控制都是TCP協(xié)議的重要特征。
TCP協(xié)議相當(dāng)復(fù)雜，并充斥著各種細(xì)節(jié)。然而TCP協(xié)議又是如此重要的一個(gè)協(xié)議，引領(lǐng)風(fēng)騷三十年，可以說是互聯(lián)網(wǎng)的奇跡。這些細(xì)節(jié)正是TCP協(xié)議成功的原因，并值得我們深入了解。
【TCP/IP詳解】系列教程
TCP-IP協(xié)議詳解(1)網(wǎng)絡(luò)協(xié)議概觀
TCP-IP協(xié)議詳解(2) 以太網(wǎng)與WiFi協(xié)議
TCP-IP協(xié)議詳解(3) IP/ARP/RIP/BGP協(xié)議
TCP-IP協(xié)議詳解(6) ICMP協(xié)議
TCP-IP協(xié)議詳解(8) TCP協(xié)議與流通信
TCP-IP協(xié)議詳解(13) DNS協(xié)議
