一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。
對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法來實現流量的控制。
後兩種就不說了，上篇博文中將已經寫得比較清楚了，對於滑動視窗機制，上篇博文中也又說到，只是沒有刻意提到用滑動視窗來實現流量的控制。下面就詳細說下利用滑動視窗機制來實現流量控制的機制，先看下圖：
我們假設a向b傳送資料。在連線建立時，b告訴了a：「我的接收視窗是 rwnd = 400 」(這裡的 rwnd 表示 receiver window) 。因此，傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。請注意，tcp的視窗單位是位元組，不是報文段。tcp連線建立時的視窗協商過程在圖中沒有顯示出來。再設每乙個報文段為100位元組長，而資料報文段序號的初始值設為1。大寫ack表示首部中的確認位ack，小寫ack表示確認欄位的值。
從圖中可以看出，b進行了三次流量控制。第一次把視窗減少到 rwnd = 300 ，第二次又減到了 rwnd = 100 ，最後減到 rwnd = 0 ，即不允許傳送方再傳送資料了。這種使傳送方暫停傳送的狀態將持續到主機b重新發出乙個新的視窗值為止。
我們考慮一種特殊情況，如果b在向a傳送了零視窗報文段後不久，b的接收快取又有了一些儲存空間，於是b向a傳送了乙個rwnd=400的報文段，然而這個報文段在傳送過程中丟失了，a就一直等待b傳送非零視窗的報文通知，而b一直等待a傳送資料，如果沒有任何措施的話，這話死鎖的局面會一直延續下去。
為了解決這個問題，tcp為每乙個連線設有乙個持續計時器(也叫堅持定時器)。只要tcp連線的一方收到對方的零視窗通知，就啟動持續計時器。若持續計時器設定的時間到期，就傳送乙個零視窗控測報文段（攜1位元組的資料），對方在收到探測報文段後，在對該報文段的確認洪給出現在的視窗值，如果視窗值仍未零，則收到這個報文段的一方就重新設定持續計時器，如果視窗不為零，那麼死鎖的僵局就被打破了。
糊塗視窗綜合症。設想一種情況，tcp接收方的快取已滿，而應用程序一次只從接收快取中讀取1位元組（這樣就使接收快取空間僅騰出1位元組），然後向傳送方傳送確認，並把視窗設定為1個位元組（但傳送的資料報為40位元組長）。接收，傳送方又發來1個位元組的資料（傳送方的ip資料報是41位元組）。接收方發回確認，仍然將視窗設定為1個位元組。這樣，網路的效率很低。要解決這個問題，可讓接收方等待一段時間，或者等到接收方快取已有一半空閒的空間。只要出現這兩種情況之一，接收方就發回確認報文，並向傳送方通知當前的視窗大小。此外，傳送方也不要傳送太小的報文段，而是把資料報積累成足夠大的報文段，或達到接收方快取的空間的一半大小時再傳送給接收端。
TCP流量控制
如果傳送端傳送的速度較快，接收端接收到資料後處理的速度較慢，而接收緩衝區的大小是固定的，就會丟失資料。tcp協議通過 滑動視窗 sliding window 機制解決這一問題。滑動視窗 傳送端發起連線，宣告最大段尺寸是1460，初始序號是0，視窗大小是4k，表示 我的接收緩衝區還有4k位元組空閒，你...
TCP流量控制
流量控制 一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法 來...
TCP流量控制
為了提高通道的利用率tcp協議不使用停止等待協議，而是使用連續arq協議，意思就是可以連續發出若干個分組然後等待確認，而不是傳送乙個分組就停止並等待該分組的確認。tcp的兩端都有傳送 接收快取和傳送 接收視窗。tcp的快取是乙個迴圈佇列，其中傳送視窗可以用3個指標表示。而傳送視窗的大小受tcp資料報...