滑動視窗基本原理

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協議棧在下個段傳送時包含新的視窗大小通知給對端，對端按通知的視窗來改變傳送視窗，以此達到減緩傳送速率的目的。