速讀原著-TCP/IP(TCP滑動窗口)

• 2020 年 3 月 11 日
• 筆記

第20章 TCP的成塊數據流

20.3 滑動窗口

圖2 0 – 4用可視化的方法顯示了我們在前一節觀察到的滑動窗口協議。

在這個圖中，我們將位元組從 1至11進行標號。接收方通告的窗口稱為提出的窗口（ o ff e r e d w i n d o w），它覆蓋了從第4位元組到第9位元組的區域，表明接收方已經確認了包括第 3位元組在內的數據，且通告窗口大小為 6。回顧第1 7章，我們知道窗口大小是與確認序號相對應的。發送方計算它的可用窗口，該窗口表明多少數據可以立即被發送。

當接收方確認數據後，這個滑動窗口不時地向右移動。窗口兩個邊沿的相對運動增加或減少了窗口的大小。我們使用三個術語來描述窗口左右邊沿的運動：

1. 稱窗口左邊沿向右邊沿靠近為窗口合攏。這種現象發生在數據被發送和確認時。
2. 當窗口右邊沿向右移動時將允許發送更多的數據，我們稱之為窗口張開。這種現象發生在另一端的接收進程讀取已經確認的數據並釋放了 T C P的接收快取時。
3. 當右邊沿向左移動時，我們稱之為窗口收縮。 Host Requirements RFC強烈建議不要使用這種方式。但T C P必須能夠在某一端產生這種情況時進行處理。第 2 2 . 3節給出了這樣的一個

例子，一端希望向左移動右邊沿來收縮窗口，但沒能夠這樣做。圖2 0 – 5表示了這三種情況。因為窗口的左邊沿受另一端發送的確認序號的控制，因此不可能向左邊移動。如果接收到一個指示窗口左邊沿向左移動的 A C K，則它被認為是一個重複 A C K， 並被丟棄。

如果左邊沿到達右邊沿，則稱其為一個零窗口，此時發送方不能夠發送任何數據。

一個例子

圖2 0 – 6顯示了在圖2 0 – 1所示的數據傳輸過程中滑動窗口協議的動態性。

以該圖為例可以總結如下幾點：

1. 發送方不必發送一個全窗口大小的數據。
2. 來自接收方的一個報文段確認數據並把窗口向右邊滑動。這是因為窗口的大小是相對於確認序號的。
3. 正如從報文段7到報文段8中變化的那樣，窗口的大小可以減小，但是窗口的右邊沿卻不能夠向左移動。
4. 接收方在發送一個 A C K前不必等待窗口被填滿。在前面我們看到許多實現每收到兩個報文段就會發送一個A C K。

下面我們可以看到更多的滑動窗口協議動態變化的例子。