a向b傳送資料，在連線建立的時候，b就會首先告訴a：我的接收視窗rwnd（receiver window）是400，同時我們要注意的是tcp的視窗單位是位元組，而不是報文段，預設每個報文段都是100位元組大小。
我們從圖中可以分析到：a向b傳送了序號1到100的報文段，seq表示序號，接著傳送101到201的報文段，然後201到301的報文段丟失了，這時候b向a傳送確認，ack表示確認字段是否有意義（只有當ack=1的時候確認欄位號才有意義），ack表示允許傳送的的初始序號，rwnd為300，表示還能夠傳送300位元組的報文。接著a繼續傳送了301到401，401到501的報文段，然後由於傳送方沒有收到seq=201的確認，所以通過超時重傳，將seq=201的報文段進行重傳。b又傳送了確認，表示還能傳送100位元組的報文段，a繼續傳送501到601報文段，b傳送確認，告訴rwnd=0，不能傳送新的報文段。
這裡還需要我們考慮到一種情況，接著上述的過程，如果b又有了400的快取空間，那麼就要向a傳送確認，但是不幸的是，確認報文丟失了，那麼這時候a和b都不會在進行操作，都在等對方傳送，就造成了死鎖。為了解決這個問題，tcp為每乙個連線都設有乙個持續計時器，只要tcp連線中的一方收到了另一方的零視窗通知，就啟動持續計時器。如果持續計時器的 時間到了，就傳送乙個零視窗的探測報文段（僅僅攜帶1位元組的資料）。
流量控制還必須考慮的一點是傳輸效率，我們可以採用下面三種傳送機制來傳送資料：
（1）如果快取中的資料到達了最大報文長度，那麼就傳送出去
（2）根據應用程序傳送的push指令來進行傳送資料
（3）設定乙個計時器，計時器時間到，就傳送資料
在tcp實現中，廣泛採用了nagle演算法：傳送方先把第乙個資料位元組傳送出去，將後面的資料位元組快取起來，等到接收方對這第乙個資料位元組發出確認之後，再把快取中的資料位元組全部傳送。
另外，我們需要**下怎麼解決糊塗視窗綜合症（silly window syndrome）：如果接收方的快取已經滿了，應用程序每次只從快取中讀取乙個位元組，然後接收方就向傳送方發出確認，說現在有1個位元組的空間了，接著傳送方的又傳送了乙個位元組的資料，接收方又忙了。如此迴圈下去，造成網路效率非常低。要解決這個問題，可以這樣做：讓接收方等待一段時間，不能有一點空間就進行傳送確認，知道快取中有足夠的空間才進行傳送確認操作。另外，傳送方也不要傳送太小的資料，要合理利用上面的三種機制的配合進行傳送。
（運輸層）TCP的流量控制
流量控制 讓傳送方的傳送速率不要太快，要讓接收方來得及接收。注意 傳送方的傳送視窗不能超過接收方給出的接收視窗的數值。tcp的視窗單位是位元組，不是報文段。如圖所示，說明了利用可變視窗大小進行流量控制。設主機a向主機b傳送資料。雙方確定的視窗值是400.再設每乙個報文段為100位元組長，序號的初始值...
白話TCP運輸控制 二 TCP的流量控制
上篇講的是擁塞控制，這篇講流量控制。還是以運輸糧食為場景。雖然運輸的擁塞控制能夠在運輸效率和擁塞之間達到平衡，但是運輸糧食的整體效率還受乙個關鍵因數影響，那就是對岸西村糧食的卸貨能力。假設糧食運送到對岸後，要卸放在乙個倉庫裡，隨後被運往其他地方。如果運輸的太快，倉庫載貨能力有限，糧食又沒有及時被消耗...
TCP流量控制
一般來說，我們總是希望資料傳輸的更快一些，但如果傳送方把資料傳送的很快，而接收方來不及接收，這就可能造成資料的丟失。流量控制就是讓傳送方的傳送速率不要太快，讓接收方來得及接收。對於成塊資料流，tcp利用滑動視窗機制來實現流量的控制，對於互動資料流，tcp利用捎帶ack和nagle演算法來實現流量的控...