滑動視窗機制

滑動視窗協議是傳輸層進行流控的一種措施，接收方通過通告發送方自己的視窗大小，從而控制傳送方的傳送速度，從而達到防止傳送方傳送速度過快而導致自己被淹沒的目的，並且滑動視窗分為接收視窗和傳送視窗。

滑動視窗協議的基本原理就是在任意時刻，傳送方都維持了一個連續的允許傳送的幀的序號，稱為傳送視窗；同時，接收方也維持了一個連續的允許接收的幀的序號，稱為接收視窗。傳送視窗和接收視窗的序號的上下界不一定要一樣，甚至大小也可以不同。不同的滑動視窗協議視窗大小一般不同。傳送方視窗內的序列號代表了那些已經被髮送，但是還沒有被確認的幀，或者是那些可以被髮送的幀。

要了解滑動視窗機制必須回顧ACK的作用。我們知道如果接收方成功的接收到資料，那麼會回覆一個ACK資料，其中ACK中包含兩個非常重要的資訊：

• 期望接收下一位元組的序號n。
• 當前滑動視窗的大小m。

而ACK所攜帶的滑動視窗的大小m便是我們滑動視窗機制中的主角了，由它來負責機制的通訊。通訊過程下圖所示：

滑動視窗基本原理

• 對於TCP會話的傳送方，任何時候在其傳送快取內的資料都可以分為4類，“已經發送並得到對端ACK的”，“已經發送但還未收到對端ACK的”，“未傳送但對端允許傳送的”，“未傳送且對端不允許傳送”。“已經發送但還未收到對端ACK的”和“未傳送但對端允許傳送的”這兩部分資料稱之為傳送視窗。

  
  當收到接收方新的ACK對於傳送視窗中後續位元組的確認是，視窗滑動，滑動原理如下圖。
  
  當收到ACK=36時視窗滑動。

• 對於TCP的接收方，在某一時刻在它的接收快取記憶體在3種。“已接收”，“未接收準備接收”，“未接收並未準備接收”（由於ACK直接由TCP協議棧回覆，預設無應用延遲，不存在“已接收未回覆ACK”）。其中“未接收準備接收”稱之為接收視窗。傳送視窗與接收視窗關係TCP是雙工的協議，會話的雙方都可以同時接收、傳送資料。TCP會話的雙方都各自維護一個“傳送視窗”和一個“接收視窗”。其中各自的“接收視窗”大小取決於應用、系統、硬體的限制（TCP傳輸速率不能大於應用的資料處理速率）。各自的“傳送視窗”則要求取決於對端通告的“接收視窗”，要求相同。
  

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

• 最基本的傳輸可靠性來源於“確認重傳”機制。
• TCP的滑動視窗的可靠性也是建立在“確認重傳”基礎上的。
• 傳送視窗只有收到對端對於本段傳送視窗內位元組的ACK確認，才會移動傳送視窗的左邊界。
• 接收視窗只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有位元組未接收但收到後面位元組的情況下，視窗不會移動，並不對後續位元組確認。以此確保對端會對這些資料重傳。
• 應用程式在需要（如記憶體不足）時，通過API通知TCP協議棧縮小TCP的接收視窗。然後TCP協議棧在下個段傳送時包含新的視窗大小通知給對端，對端按通知的視窗來改變傳送視窗，以此達到減緩傳送速率的目的。