TCP 滑動窗口（發送窗口和接收窗口）

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

========================END========================