說明： 本文僅供學習交流。轉載請標明出處，歡迎轉載！
本文是下面文獻相關內容的總結
[1] 《TCP/IP具體解釋 卷1：協議》
[2] 《TCP/IP協議族 第4版》
[3] 《計算機網絡 第5版》
TCP流量控制的目的是限制發送端的發送速率，使得接收方可以及時接收。
TCP主要是通過滑動窗體來實現流量控制的。實際上，發送窗體的大小不僅受接收窗體rwnd的大小的限制，還受擁塞窗體cwnd窗體的限制，為了實現點到點的流量控制，本文如果擁塞窗體足夠大（即網絡鏈路比較流暢），僅考慮發送窗體swnd受接收窗體的限制。
窗體由左臂和右臂組成。左臂右移稱為關閉，右臂左移稱為收縮，右臂右移稱為打開。
發送窗體和接收窗體的移動操作
接收窗體：當接收方收到發送方的很多其它的字節時（不包含反復的報文段），接收窗體關閉。當接收緩存中的字節被接收進程pull時，接收窗體打開，通常接收窗體不會發送收縮操作。
發送窗體：發送窗體的關閉、收縮和打開受接收方的控制。當一個有效的確認時，發送窗體關閉；當接收方通告發送方同意的窗體大小能夠更大時，發送窗體會打開。當接收方通告發送方同意的窗體大小更小時。發送窗體就收縮，可是TCP強烈不建議發送窗體收縮。
注意：TCP窗體的單位是字節。不是報文段。所以TCP窗體中，每一格相應1B。
利用滑動窗體進行流量控制過程
上圖中，在發送端與接收端建立連接時，接收端告訴發送端當前接收窗體rwnd=400。所以發送端最多可以發送400B，如果每個報文段為100B。
發送端連續發送4個報文段。各自是1-100,101-200,201-300,301-400,401-500。發送后數據段101-200在路上丟失了，其它幾個報文都被接收了。並放入到接收緩存中，接收方便向發送方發送1-200報文段的ACK。並期望收到序號為201相應的報文段。同一時候設置接收窗體大小rwnd=300,發送端便重傳序號201相應的報文段。當接收端收到該報文段后，並向發送端發送前500個報文的ACK，並期望收到序號為501的報文段，並設置接收窗體rwnd=100。發送端收到該ACK報文段后，便向接收端發送序號為501-600的報文段，接收端收到該報文段后，發送ACK報文段。並設置rwnd=0，意在通知發送端不要臨時再發送數據段。
糊塗窗體綜合症
當發送應用程序產生數據的速度非常慢，或接收應用程序消耗數據的速度非常慢，或者兩者都有，都會使得發送數據的報文段非常小，使得網絡效率非常低，這個問題稱為糊塗窗體綜合症SWS(silly window syndrome)。
發送方產生的症狀
假設發送方應用程序產生數據的速度非常慢。比如一次僅僅產生1B，那么就有可能產生糊塗窗體綜合症。解決辦法是防止發送TCP一次僅僅發送1B。必須讓發送TCP等待。並把數據收集成較大的數據塊后再發送。
發送TCP須要等待多長時間再發送呢？
假設等待時間過長。則會延遲整個過程。
假設等待時間過短，最后非常可能還是發送一個個小報文段。Nagle提出了一種解決辦法，我們稱之為Nagle算法，過程例如以下：
1.發送TCP把它從應用程序收到的第一塊數據發送出去。哪怕僅僅有一個字節；
2.在發送了第一個報文段后。發送TCP先把發送應用程序興許到達的數據字節緩存起來。直到收到接收端發來的ACK，或者已積累了足夠的數據。發送TCP就能夠發送這個報文段了。
注意：足夠的數據指的是數據達到0.5*MSS（最大報文段長度的一半）或者發送窗體大小的一半時。
接收方產生的症狀
假設接收端應用程序pull速度非常慢，比如一次僅僅消耗1B的數據。若TCP接收方的緩存已滿，而應用程序一次僅僅能從接收緩存中讀取1B，然后向發送方發送ACK。並把窗體設置為1B（由於從接收緩存中取出了1B），但發送方的緩存中有非常多數據。這樣發送方有僅僅能一次發送1B，接收方發回確認，仍然將窗體設置為1B，這樣進行下去。網絡的效率非常低，此時能夠採取兩種解決方法：
方法1：採用Clark解決方法。該方法是：接收端僅僅要有數據到達就向發送端發送零值窗體ACK報文段。直到（1）緩存中有足夠大的空間能夠放入1MSS報文段，或者（2）至少有一半的緩存空間空暇。僅僅要出現這兩種情況之中的一個，接收端就向發送端發送非零值窗體ACK報文。
方法2：推遲確認。當報文段到達時並不馬上發送確認，接收方在對收到的報文段進行確認之前一直等待，直至接收緩存有足夠的空間為止。
推遲發送確認防止了發送TCP滑動它的窗體。
推遲確認的另外一個長處：降低了網絡的通信量；相應的缺點是：假設推遲的時間比較長，會使得發送方以為發送的報文丟失，而產生不必要的重傳。
總之。發送方和接收方能夠配合解決該問題。整體的思想是：發送方不發送非常小的報文段的同一時候，接收方也不要在緩存剛剛有了一點小空間就急慌忙這個非常小的窗體大小的信息通知發件人。
版權聲明：本文博客原創文章，博客，未經同意，不得轉載。