滑動視窗 (TCP流量控制)

介紹UDP時我們描述了這樣的問題：如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。TCP協議通過“滑動視窗（Sliding Window）”機制解決這一問題。看下圖的通訊過程：

滑動視窗

1. 傳送端發起連線，宣告最大段尺寸是1460，初始序號是0，視窗大小是4K，表示“我的接收緩衝區還有4K位元組空閒，你發的資料不要超過4K”。接收端應答連線請求，宣告最大段尺寸是1024，初始序號是8000，視窗大小是6K。傳送端應答，三方握手結束。

2. 傳送端發出段4-9，每個段帶1K的資料，傳送端根據視窗大小知道接收端的緩衝區滿了，因此停止傳送資料。

3. 接收端的應用程式提走2K資料，接收緩衝區又有了2K空閒，接收端發出段10，在應答已收到6K資料的同時宣告視窗大小為2K。

4. 接收端的應用程式又提走2K資料，接收緩衝區有4K空閒，接收端發出段11，重新宣告視窗大小為4K。

5. 傳送端發出段12-13，每個段帶2K資料，段13同時還包含FIN位。

6. 接收端應答接收到的2K資料（6145-8192），再加上FIN位佔一個序號8193，因此應答序號是8194，連線處於半關閉狀態，接收端同時宣告視窗大小為2K。

7. 接收端的應用程式提走2K資料，接收端重新宣告視窗大小為4K。

8. 接收端的應用程式提走剩下的2K資料，接收緩衝區全空，接收端重新宣告視窗大小為

9. 接收端的應用程式在提走全部資料後，決定關閉連線，發出段17包含FIN位，傳送端應答，連線完全關閉。

上圖在接收端用小方塊表示1K資料，實心的小方塊表示已接收到的資料，虛線框表示接收緩衝區，因此套在虛線框中的空心小方塊表示視窗大小，從圖中可以看出，隨著應用程式提走資料，虛線框是向右滑動的，因此稱為滑動視窗。

從這個例子還可以看出，傳送端是一K一K地傳送資料，而接收端的應用程式可以兩K兩K地提走資料，當然也有可能一次提走3K或6K資料，或者一次只提走幾個位元組的資料。也就是說，應用程式所看到的資料是一個整體，或說是一個流（stream），在底層通訊中這些資料可能被拆成很多資料包來發送，但是一個數據包有多少位元組對應用程式是不可見的，