TCP/IP(十一)TCP滑動視窗和用賽控制

標籤：

目前建立在TCP協議上的網路通訊協定特別多，有telnet，ssh，有ftp，有http等等。這些協議又可以根據資料輸送量來大致分成兩大類：(1)互動資料類型，例如telnet，ssh，這種類型的協議在大多數情況下只是做小流量的資料交換，比如說按一下鍵盤，回顯一些文字等等。(2)資料成塊類型，例如ftp，這種類型的協議要求TCP能盡量的運載資料，把資料的輸送量做到最大，並儘可能的提高效率。針對這兩種情況，TCP給出了兩種不同的策略來進行資料轉送。

1.TCP的互動資料流

對於互動性要求比較高的應用，TCP給出兩個策略來提高發送效率和減低網路負擔：（1）捎帶ACK。(2)Nagle演算法（一次盡量多的發資料）。通常，在網路速度很快的情況下，比如用lo介面進行telnet通訊，當按下字母鍵並要求回顯的時候，用戶端和伺服器將經曆 發送按鍵資料->伺服器發送按鍵資料的ack -> 伺服器端發送回顯資料->用戶端發送回顯資料的ACK的過程，而其中的資料流量將是40bit + 41bit+41bit+40bit = 162bit，如果在廣域網路裡面，這種小分組的TCP流量將會造成很大的網路負擔。

1.1.捎帶ACK的發送方式

這個策略是說，當主機收到遠程主機的TCP資料報之後，通常不馬上發送ACK資料報，而是等上一個短暫的時間，如果這段時間裡面主機還有發送到遠程主機的TCP資料報，那麼就把這個ACK資料報“捎帶”著發送出去，把本來兩個TCP資料報整合成一個發送。一般的，這個時間是200ms。可以明顯地看到這個策略可以把TCP資料報的利用率提高很多。

1.2.Nagle演算法

上過bbs的人應該都會有感受，就是在網路慢的時候發貼，有時鍵入一串字串以後，經過一段時間，用戶端“發瘋”一樣突然回顯出很多內容，就好像資料一下子傳過來了一樣，這就是Nagle演算法的作用。

Nagle演算法是說，當主機A給主機B發送了一個TCP資料報並進入等待主機B的ACK資料報的狀態時，TCP的輸出緩衝區裡面只能有一個TCP資料報，並且，這個資料報不斷地收集後來的資料，整合成一個大的資料報，等到B主機的ACK包一到，就把這些資料“一股腦”的發送出去。雖然這樣的描述有些不準確，但還算形象和易於理解，我們同樣可以體會到這個策略對於低減網路負擔的好處。

在編寫插口程式的時候，可以通過TCP_NODELAY來關閉這個演算法。並且，使用這個演算法看情況的，比如基於TCP的X視窗協議，如果處理滑鼠事件時還是用這個演算法，那麼“延遲”可就非常大了。

2.TCP的成塊資料流

對於FTP這樣對於資料輸送量有較高要求的要求，將總是希望每次盡量多的發送資料到對方主機，就算是有點“延遲”也無所謂。TCP也提供了一整套的策略來支援這樣的需求。TCP協議中有16個bit表示“視窗”的大小，這是這些策略的核心。

2.1.傳輸資料時ACK的問題

在解釋滑動視窗前，需要看看ACK的應答策略，一般來說，發送端發送一個TCP資料報，那麼接收端就應該發送一個ACK資料報。但是事實上卻不是這樣，發送端將會連續發送資料盡量填滿接受方的緩衝區，而接受方對這些資料只要發送一個ACK報文來回應就可以了，這就是ACK的累積特性，這個特性大大減少了發送端和接收端的負擔。

2.2.滑動視窗

滑動視窗本質上是描述接受方的TCP資料報緩衝區大小的資料，發送方根據這個資料來計算自己最多能發送多長的資料。如果發送方收到接受方的視窗大小為0的TCP資料報，那麼發送方將停止發送資料，等到接受方發送視窗大小不為0的資料報的到來。書中的P211和P212很好的解釋了這一點。

關於滑動視窗協議，書上還介紹了三個術語，分別是：

1. 視窗合攏：當視窗從左邊向右邊靠近的時候，這種現象發生在資料被發送和確認的時候。
2. 視窗張開：當視窗的右邊沿向右邊移動的時候，這種現象發生在接受端處理了資料以後。
3. 視窗收縮：當視窗的右邊沿向左邊移動的時候，這種現象不常發生。

TCP就是用這個視窗，慢慢的從資料的左邊移動到右邊，把處於視窗範圍內的資料發送出去（但不用發送所有，只是處於視窗內的資料可以發送。）。這就是視窗的意義。圖20-6解釋了這一點。視窗的大小是可以通過socket來制定的，4096並不是最理想的視窗大小，而16384則可以使輸送量大大的增加。

2.3.資料擁塞

上面的策略用於區域網路內傳輸還可以，但是用在廣域網路中就可能會出現問題，最大的問題就是當傳輸時出現了瓶頸（比如說一定要經過一個slip低速鏈路）所產生的大量資料堵塞問題（擁塞），為瞭解決這個問題，TCP發送方需要確認串連雙方的線路的資料最大輸送量是多少。這，就是所謂的擁塞視窗。

擁塞視窗的原理很簡單，TCP發送方首先發送一個資料報，然後等待對方的回應，得到回應後就把這個視窗的大小加倍，然後連續發送兩個資料報，等到對方回應以後，再把這個視窗加倍（先是2的指數倍，到一定程度後就變成現行增長，這就是所謂的慢啟動），發送更多的資料報，直到出現逾時錯誤，這樣，發送端就瞭解到了通訊雙方的線路承載能力，也就確定了擁塞視窗的大小，發送方就用這個擁塞視窗的大小發送資料。要觀察這個現象是非常容易的，我們一般在下載資料的時候，速度都是慢慢“衝起來的”

以上就是TCP資料轉送的大致流程，雖然並不細緻，但是足以描述TCP的工作原理，重點是TCP的流量控制原理，滑動視窗，擁塞視窗，ACK累計確認等知識點。

=========================================

滑動視窗詳解：

TCP 滑動視窗（發送視窗和接收視窗）

TCP的滑動視窗主要有兩個作用，一是提供TCP的可靠性，二是提供TCP的流控特性。同時滑動視窗機制還體現了TCP面向位元組流的設計思路。

TCP的Window是一個16bit位欄位，它代表的是視窗的位元組容量，也就是TCP的標準視窗最大為2^16-1=65535個位元組。

另外在TCP的選項欄位中還包含了一個TCP視窗擴大因子，option-kind為3，option-length為3個位元組，option-data取值範圍0-14。視窗擴大因子用來擴大TCP視窗，可把原來16bit的視窗，擴大為31bit。

滑動視窗基本原理

1）對於TCP會話的發送方，任何時候在其發送緩衝內的資料都可以分為4類，“已經發送並得到對端ACK的”，“已經發送但還未收到對端ACK的”，“未發送但對端允許發送的”，“未發送且對端不允許發送”。“已經發送但還未收到對端ACK的”和“未發送但對端允許發送的”這兩部分資料稱之為發送視窗（中間兩部分）。

當收到接收方新的ACK對於發送視窗中後續位元組的確認是，視窗滑動，滑動原理如。

當收到ACK=36時視窗滑動。

2）對於TCP的接收方，在某一時刻在它的接收緩衝記憶體在3種。“已接收”，“未接收準備接收”，“未接收並未準備接收”（由於ACK直接由TCP協議棧回複，預設無應用延遲，不存在“已接收未回複ACK”）。其中“未接收準備接收”稱之為接收視窗。

發送視窗與接收視窗關係

TCP是雙工的協議，會話的雙方都可以同時接收、發送資料。TCP會話的雙方都各自維護一個“發送視窗”和一個“接收視窗”。其中各自的“接收視窗”大小取決於應用、系統、硬體的限制（TCP傳輸速率不能大於應用的資料處理速率）。各自的“發送視窗”則要求取決於對端通告的“接收視窗”，要求相同。

滑動視窗實現面向流的可靠性

最基本的傳輸可靠性來源於“確認重傳”機制。

TCP的滑動視窗的可靠性也是建立在“確認重傳”基礎上的。

發送視窗只有收到對端對於本段發送視窗內位元組的ACK確認，才會移動發送視窗的左邊界。

接收視窗只有在前面所有的段都確認的情況下才會移動左邊界。當在前面還有位元組未接收但收到後面位元組的情況下，視窗不會移動，並不對後續位元組確認。以此確保對端會對這些資料重傳。

滑動視窗的流控特性

TCP的滑動視窗是動態，我們可以想象成小學常見的一個數學題，一個水池，體積V，每小時進水量V1，出水量V2。當水池滿了就不允許再注入了，如果有個液壓系統控制水池大小，那麼就可以控制水的注入速率和量。這樣的水池就類似TCP的視窗。應用根據自身的處理能力變化，通過本端TCP接收視窗大小控制來對對對端的發送視窗流量限制。

應用程式在需要（如記憶體不足）時，通過API通知TCP協議棧縮小TCP的接收視窗。然後TCP協議棧在下個段發送時包含新的視窗大小通知給對端，對端按通知的視窗來改變發送視窗，以此達到減緩發送速率的目的。

========================END========================

TCP/IP(十一)TCP滑動視窗和用賽控制