目錄

零、答案

一、滑窗結構

二、流量控制

三、零窗口

---

零、答案

接收端告訴發送端，自己現在能夠接收的包的數量，發送端根據該數據來調整自己頻率，從而完成了 TCP 的流量控制。

一、滑窗結構

發送方滑窗可以分為下面兩個部分。offered window 為整個滑窗的大小。

?

接收方滑窗可分為三個部分：

?

可以看到，接收方的滑窗相對于發送方的滑窗多了一個 "?Received ACKed Not Sent to Proc?" 的部分。接收方接收到的文本流必須等待進程來讀取。如果進程正忙于做別的事情，那么這些文本流即使已經正確接收，還是需要暫時占用接收緩存。

當出現上述占用時，滑窗的可用部分(也就是圖中 advertised window )就會縮水。這意味著接收方的處理能力下降。如果這個時候發送方依然按照之前的速率發送數據給接收方，接收方將無力接收這些數據。

二、流量控制

如果發送端發送太快，導致接收端來不及接收，就容易造成丟失數據。流量控制是指接收方將 advertised window 的大小通知給發送方，從而指導發送方修改 offered window 的大小。接收方將該信息放在TCP頭部的 window size 區域：

發送方在收到window size的通知時，會調整自己滑窗的大小，讓 offered window 和 advertised window 相符。這樣，發送窗口變小，文本流發送速率降低，從而減少了接收方的負擔。

三、零窗口

? ? ? ? advertised window 大小有可能變為0，這意味著接收方的接收能力降為 0 。發送方收到大小為 0 的 advertised window 通知時，停止發送。

當接收方經過處理，再次產生可用的 advertised window 時，接收方會通過純粹的 ACK 回復來通知發送方，讓發送方恢復發送。然而，ACK回復的傳送并不是可靠的。如果該ACK回復丟失，那么TCP傳輸將陷入死鎖(deadlock)狀態。

為此，發送方會在零窗口后，不斷探測接收方的窗口。窗口探測（ window probe ）時，發送方會向接收方發送包含1 byte文本流的 TCP 片段，并等待 ACK 回復（ 該ACK回復包含有 window size ）。由于有1 byte的數據存在，所以該傳輸是可靠的，而不用擔心 ACK 回復丟失的問題。如果探測結果顯示窗口依然為 0，發送方會等待更長的時間，然后再次進行窗口探測，直到TCP傳輸恢復。

?

（SAW：Game Over！）

總結

以上是生活随笔為你收集整理的TCP/IP / 如何进行流量控制（ flow control ）？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。