一般來說，我們總是希望傳輸數據的更快一些，但假設發送方把數據發送的非常快。而接收方來不及接收，這就可能造成數據的丟失。流量控制就是讓發送方的發送速率不要太快。讓接收方來得及接收。
對於成塊數據流，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個字節。這樣，網絡的效率非常低。要解決問題。可讓接收方等待一段時間，或者等到接收方緩存已有一半空暇的空間。僅僅要出現這兩種情況之中的一個。接收方就發回確認報文，並向發送方通知當前的窗體大小。
此外。發送方也不要發送太小的報文段。而是把數據報積累成足夠大的報文段。或達到接收方緩存的空間的一半大小時再發送給接收端。