在TCP協議與”流”通信中，我們建立了滑窗(sliding window)的基本概念。通過滑窗與ACK的配合，我們一方面實現了TCP傳輸的可靠性，另一方面也一定程度上提高了效率。其工作方式如下面的視頻所示：
視頻鏈接： http://v.youku.com/v_show/id_XNDg1NDUyMDUy.html
然而，之前的解釋只是概念性的。TCP爲了達到更好的傳輸效率，對上面的工作方式進行了許多改進。The devil is in the details. 我們需要深入到細節，才能看清楚TCP協議的智慧所在。
累計ACK
在TCP連接中，我們通過將ACK回覆“附着”在其他數據片段的方式，減少了ACK回覆所消耗的流量。但這並不是全部的故事。TCP協議並不是對每個片段都發送ACK回覆。TCP協議實際採用的是累計ACK回覆(accumulative acknowledgement)。接收方往往利用一個ACK回覆來知會連續多個片段的成功接收。通過累計ACK，所需要的ACK回覆通常可以降到50%。
如下圖所示，橙色爲已經接收的片段。方框爲滑窗，滑窗可容納3個片段。
累計ACK
滑窗還沒接收到片段7時，已接收到片段8，9。這樣就在滑窗中製造了一個“空穴”(hole)。當滑窗最終接收到片段7時，滑窗送出一個回覆號爲10的ACK回覆。發送方收到該回復，會意識到，片段10之前的片段已經按照次序被成功接收。整個過程中節約了片段7和片段8所需的兩個ACK回覆。
此外，接收方在接收到片斷，並應該回復ACK的時候，會故意延遲一些時間。如果在延遲的時間裏，有後續的片段到達，就可以利用累計ACK來一起回覆了。
滑窗結構
在之前的討論中，我們以片段爲單位，來衡量滑窗的大小的。真實的滑窗是以byte爲單位表示大小，但這並不會對我們之前的討論造成太大的影響。
發送方滑窗可以分爲下面兩個部分。offered window爲整個滑窗的大小。
接收方滑窗可分爲三個部分：
可以看到，接收方的滑窗相對於發送方的滑窗多了一個“Received; ACKed; Not Sent to Proc”的部分。接收方接收到的文本流必須等待進程來讀取。如果進程正忙於做別的事情，那麼這些文本流即使已經正確接收，還是需要暫時佔用接收緩存。當出現上述佔用時，滑窗的可用部分(也就是圖中advertised window)就會縮水。這意味着接收方的處理能力下降。如果這個時候發送方依然按照之前的速率發送數據給接收方，接收方將無力接收這些數據。
流量控制
TCP協議會根據情況自動改變滑窗大小，以實現流量控制。流量控制(flow control)是指接收方將advertised window的大小通知給發送方，從而指導發送方修改offered window的大小。接收方將該信息放在TCP頭部的window size區域：
發送方在收到window size的通知時，會調整自己滑窗的大小，讓offered window和advertised window相符。這樣，發送窗口變小，文本流發送速率降低，從而減少了接收方的負擔。
零窗口
advertised window大小有可能變爲0，這意味着接收方的接收能力降爲0。發送方收到大小爲0的advertised window通知時，停止發送。
零窗口
當接收方經過處理，再次產生可用的advertised window時，接收方會通過純粹的ACK回覆來通知發送方，讓發送方恢復發送。然而，ACK回覆的傳送並不是可靠的。如果該ACK回覆丟失，那麼TCP傳輸將陷入死鎖(deadlock)狀態。
爲此，發送方會在零窗口後，不斷探測接收方的窗口。窗口探測(window probe)時，發送方會向接收方發送包含1 byte文本流的TCP片段，並等待ACK回覆(該ACK回覆包含有window size)。由於有1 byte的數據存在，所以該傳輸是可靠的，而不用擔心ACK回覆丟失的問題。如果探測結果顯示窗口依然爲0，發送方會等待更長的時間，然後再次進行窗口探測，直到TCP傳輸恢復。
白癡窗口綜合症
滑窗機制有可能犯病，比如白癡窗口綜合症 (Silly Window Syndrome)。假設這樣一種情形：接收方宣佈(advertise)一個小的窗口，發送方根據advertised window，發送一個小的片段。接收方的小窗口被填滿，經過處理，接收方再宣佈一個小的窗口…… 這就是“白癡窗口綜合症”：TCP通信的片段中包含的數據量很小。在這樣的情況下，TCP通信的片段所含的信息都很小，網絡流量主要是TCP片段的頭部，從而造成流量的浪費 (由於TCP頭部很大，我們希望每個TCP片段中含有比較多的數據)。
如果發送方不斷髮送小的片段，也會造成“白癡窗口”。爲了解決這個問題，需要從兩方面入手。TCP中有相關的規定，要求：
1. 接收方宣告的窗口必須達到一定的尺寸，否則等待。
2. 除了一些特殊情況，發送方發送的片段必須達到一定的尺寸，否則等待。特殊情況主要是指需要最小化延遲的TCP應用(比如命令行互動)。
總結
累計ACK減少了TCP傳輸過程中所需的ACK流量。通過流量管理，TCP連接兩端的工作能力可以匹配，從而減少不不要的傳輸浪費。累計ACK和流量控制都是TCP協議的重要特徵。
TCP協議相當複雜，並充斥着各種細節。然而TCP協議又是如此重要的一個協議，引領風騷三十年，可以說是互聯網的奇蹟。這些細節正是TCP協議成功的原因，並值得我們深入瞭解。
轉載：http://www.code123.cc/1286.html