TCP的滑動窗口機制
如果每次傳輸數據都只能發送一個MSS，就需要等待接收方的ACK，這顯然會極大的影響傳輸的速率。在發送數據的時候，最好的方式是一下將所有的數據全部發送出去，然后一起確認。
但是現實中確實會存在一些限制：
- 接收方的緩存（接收窗口）可能已經滿了，無法接收數據。
- 網絡的帶寬也不一定足夠大，一口發太多會導致丟包事故。
發送方要知道接收方的接收窗口和網絡這兩個限制因素中哪一個更嚴格，然后在其限制范圍內盡可能多發包。這個一口氣能發送的數據量就是傳說中的TCP發送窗口。
首先TCP在進行數據傳輸的時候都是先將數據放在數據緩沖區中的，TCP維護了兩個緩沖區，發送方緩沖區和接收方緩沖區。
- 發送方緩沖區：發送方緩沖區用於存儲已經准備就緒數據和發送了但是沒有被確認的數據。
- 接收方緩沖區：接收方緩沖區用於存儲已經被接收但是還沒有被用戶進程消費的數據。
滑動窗口機制是TCP的一種流量控制方法，該機制允許發送方在停止並等待確認前連續發送多個分組，而不必每發送一個分組就停下來等待確認，從而增加數據傳輸的速率提高應用的吞吐量。
TCP的包可以分為四種狀態
- 已發送並且已經確認的包。
- 已發送但是沒有確認的包。
- 未發送但是可以發送的包。
- 不允許被發送的包。
滑動窗口協議的基本工作流程就是由接收方通告窗口的大小，這個窗口稱為提出窗口，也就是接收方窗口。接收方提出的窗口則是被接收緩沖區所影響的，如果數據沒有被用戶進程使用那么接收方通告的窗口就會相應得到減小，發送窗口取決於接收方窗口的大小。可用窗口的大小等於接收方窗口減去發送但是沒有被確認的數據包大小。
滑動窗口機制示意流量圖
滑動窗口的動態性
零窗口（TCP Zero Window）
在接收方窗口大小變為0的時候，發送方就不能再發送數據了。但是當接收方窗口恢復的時候發送方要怎么知道那？在這個時候TCP會啟動一個零窗口（TCP Zero Window）定時探測器，向接收方詢問窗口大小，當接收方窗口恢復的時候，就可以再次發送數據。