TCP 滑動視窗的簡介(寫得太好，轉載過來的)

POSTED BY ON

AUG 1, 2012 IN

|

TCP的滑動視窗主要有兩個作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同時滑動視窗機制還展現了TCP面向位元組流的設計思路。TCP

段中視窗的相關字段。

TCP的Window是一個16bit位字段，它代表的是視窗的位元組容量，也就是TCP的标準視窗最大為2^16-1=65535個位元組。

另外在TCP的選項字段中還包含了一個TCP視窗擴大因子，option-kind為3，option-length為3個位元組，option-data取值範圍0-14。視窗擴大因子用來擴大TCP視窗，可把原來16bit的視窗，擴大為31bit。

滑動視窗基本原理

1）對于TCP會話的發送方，任何時候在其發送緩存内的資料都可以分為4類，“已經發送并得到對端ACK的”，“已經發送但還未收到對端ACK的”，“未發送但對端允許發送的”，“未發送且對端不允許發送”。“已經發送但還未收到對端ACK的”和“未發送但對端允許發送的”這兩部分資料稱之為發送視窗。

當收到接收方新的ACK對于發送視窗中後續位元組的确認是，視窗滑動，滑動原理如下圖。

當收到ACK=36時視窗滑動。

2）對于TCP的接收方，在某一時刻在它的接收緩存記憶體在3種。“已接收”，“未接收準備接收”，“未接收并未準備接收”（由于ACK直接由TCP協定棧回複，預設無應用延遲，不存在“已接收未回複ACK”）。其中“未接收準備接收”稱之為接收視窗。

發送視窗與接收視窗關系

TCP是雙工的協定，會話的雙方都可以同時接收、發送資料。TCP會話的雙方都各自維護一個“發送視窗”和一個“接收視窗”。其中各自的“接收視窗”大小取決于應用、系統、硬體的限制（TCP傳輸速率不能大于應用的資料處理速率）。各自的“發送視窗”則要求取決于對端通告的“接收視窗”，要求相同。

滑動視窗實作面向流的可靠性

最基本的傳輸可靠性來源于“确認重傳”機制。

TCP的滑動視窗的可靠性也是建立在“确認重傳”基礎上的。

發送視窗隻有收到對端對于本段發送視窗内位元組的ACK确認，才會移動發送視窗的左邊界。

接收視窗隻有在前面所有的段都确認的情況下才會移動左邊界。當在前面還有位元組未接收但收到後面位元組的情況下，視窗不會移動，并不對後續位元組确認。以此確定對端會對這些資料重傳。

滑動視窗的流控特性

TCP的滑動視窗是動态的，我們可以想象成國小常見的一個數學題，一個水池，體積V，每小時進水量V1，出水量V2。當水池滿了就不允許再注入了，如果有個液壓系統控制水池大小，那麼就可以控制水的注入速率和量。這樣的水池就類似TCP的視窗。應用根據自身的處理能力變化，通過本端TCP接收視窗大小控制來對對對端的發送視窗流量限制。

應用程式在需要（如記憶體不足）時，通過API通知TCP協定棧縮小TCP的接收視窗。然後TCP協定棧在下個段發送時包含新的視窗大小通知給對端，對端按通知的視窗來改變發送視窗，以此達到減緩發送速率的目的。

參考