所謂的流量控制， 就是告誡對方傳送速率不要太快， 要讓接收來來得及接收資料。
形容如下；
甲向乙傳送資料。經過tcp三握手連線以後， 當乙告訴甲：「我的接受視窗rwnd = 400」（這裡rwnd表示receiver window的意思）。所以，傳送方的傳送視窗不能超過接收方給出的接受視窗的數值。而tcp視窗的單位是位元組， 而不是報文段。
假設每個報文的長度為100位元組， 報文段的序號初始值設定為1。
1、主機乙對該傳輸過程進行了三次流量控制。（按道理說，seq 1 和 sql 101傳送後主機乙放回的rwnd = 200， 但是在該應答中返回的是300， 那可能是因為主機b呼叫recv函式讀取了100位元組， 後續若遇到此類情況， 皆是如此處理）。
2、seq因為沒有傳送成功，第一次流量控制ack= 201，rwnd = 300； 在經過三次傳送過， seq = 201， 再次傳送屬於超時重傳。
3、最後返回的ack應答中， rwnd = 0， 表示甲主機不能再向乙主機傳輸資料了。 等待乙主機的程序讀取資料。
4、如果乙主機的快取空間又空閒了。 那麼乙主機將會向甲主機傳送ack = 1， rwnd = 400的應答， 如果該應答在傳輸的過程中丟失了。甲主機將會一直等待乙主機的非零視窗通知， 而乙主機也一直在等待甲主機傳送的資料，在沒有其他措施的情況下， 這種相互等待將會一直死鎖下去
由4小點我們引入了乙個新的措施， 叫做持續及時器：
tcp連線的任何一段， 如果收到了0視窗通知， 那麼將會啟動持續計時器。當持續計時器的時間到了後， 該端將會傳送乙個零視窗的探測報文段（攜帶乙個位元組的資料），如果還是收到了零視窗通知， 將繼續重新啟動計時器， 重複該步驟， 直到打破死鎖位置。
由上圖所示， 甲主機的傳送視窗為20， 乙主機的接受視窗是20.
1）、甲主機開始接收到了來自乙主機ack = 29， win = 20的視窗通知。 那麼甲主機就傳送序號為[29,49)裡面的資料， 理想乙主機希望接受[29,49)序號的資料。
2）、可能因為序號為31的位元組資料丟失、又或者是滯留在網路當中， 導致資料不能完全接受， 那麼乙主機傳送ack = 31， win = 20的通知視窗給對端
3）、甲主機有接受ack = 31， win = 20,的通知視窗。 接受並且傳送序號為[31,51)裡面的資料， 又因為可能序號為35的位元組丟失重複以上操作
通過客戶端不斷向服務寫入資料， 但是伺服器端並不讀取任何資料進入睡眠狀態。
伺服器程式**片段：
for(;;)
}else if(n == 0) break;
else
}
抓包結果：
1、了解滑動視窗的含義。
2、怎麼通過發動視窗來控制流量的（即工作流程）
3、拓展
TCP滑動視窗與流量控制
tcp採用可變滑動視窗來實現流量控制。tcp連線的兩端互動作用，互相提供資料流的相關資訊，包括報文段序列號 ack號和視窗大小 即接收端的可用空間 傳送端根據這些資訊動態調節視窗大小來控制傳送，以達到流量控制的目的。每個tcp頭部的視窗大小字段表明接收端可用快取空間的大小，以位元組為單位。該字段長度...
滑動視窗 TCP流量控制
問題 如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。看下圖的通訊過程 1.傳送端發起連線，宣告最大段尺寸是 1460 初始序號是 0，視窗大小是 4k，表示 我的接收緩衝...
流量控制 滑動視窗
1.流量控制 我們都知道當網路上資料流量超過網路硬體負荷時就會出現網路擁塞，就是我們平常遇到的網路緩慢的現象。對應影響網路速度的原因主要有網路傳輸裝置的效能和傳輸的資料多少，網路傳輸裝置包含傳送接收主機 路由器 傳輸線路等。為了解決這個問題，tcp引入了流量控制，顧名思義，就是採用某種方法，控制收發...