TCP Nagle算法&&延遲確認機制
- 發表於 3年前
- 閱讀 1367
- 收藏 0
- 點贊 0
- 評論 0
【騰訊雲】買域名送雲解析+SSL證書+建站！>>> 
TCP Nagle算法&&延遲確認機制
TCP Nagle算法
http://baike.baidu.com/view/2468335.htm
百度百科：TCP/IP協議中，無論發送多少數據，總是要在數據前面加上協議頭，同時，對方接收到數據，也需要發送ACK表示確認。為了盡可能的利用網絡帶寬，TCP總是希望盡可能的發送足夠大的數據。（一個連接會設置MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的數據塊來發送數據）。
Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。所謂“小段”，指的是小於MSS尺寸的數據塊，所謂“未被確認”，是指一個數據塊發送出去後，沒有收到對方發送的ACK確認該數據已收到。
Nagle算法的規則（可參考tcp_output.c文件裏tcp_nagle_check函數註釋）：
（1）如果包長度達到MSS，則允許發送；
（2）如果該包含有FIN，則允許發送；
（3）設置了TCP_NODELAY選項，則允許發送；
（4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小於MSS）均被確認，則允許發送；
（5）上述條件都未滿足，但發生了超時（一般為200ms），則立即發送。
Nagle算法只允許一個未被ACK的包存在於網絡，它並不管包的大小，因此它事實上就是一個擴展的停-等協議（停止等待ARQ協議），只不過它是基於包停-等的，而不是基於字節停-等的。Nagle算法完全由TCP協議的ACK機制決定，這會帶來一些問題，比如如果對端ACK回復很快的話，Nagle事實上不會拼接太多的數據包，雖然避免了網絡擁塞，網絡總體的利用率依然很低。
Nagle算法的應用場景
在Nagle算法的Wiki主頁，有這麽一段話：
In general, since Nagle‘s algorithm is only a defense against careless applications, it will not benefit a carefully written application that takes proper care of buffering; the algorithm has either no effect, or negative effect on the application.
可見編程模型對“減少網絡上小包數量”的影響，言外之意，Nagle算法是個有針對性的優化-針對交互式應用，不是放之四海而皆準的標準，要想有一個比較好的方案，別指望它了，還是應用程序自己搞定才是正解！要想Nagle算法真的能夠減少網絡上小包數量而又不引入明顯延遲，對TCP數據的產生方式是有要求的，交互式應用是其初始針對的對象，，Nagle算法要求數據必須是“乒乓型”的，也就是說，數據流有明確的邊界且一來一回，類似人機交互的那種，比如telnet這種遠程終端登錄程序，數據是人從鍵盤敲入的，邊界基本上就是擊鍵，一來一回就是輸入回顯和處理回顯。Nagle算法在上面的場景中保證了下一個小包發送之前，所有發出的包已經得到了確認，再次我們看到，Nagle算法並沒有阻止發送小包，它只是阻止了發送大量的小包。
換句話說，所謂的“乒乓型”模式就是“write-read-write-read”模式-人機交互模式，但是對於Wiki中指出的“write-write-read”(很多的request/response模式C/S服務就是這樣的，比如HTTP)-程序交互模式，Nagle算法和延遲ACK（延遲確認機制）拔河的惡果就會被放大。
有一篇很好的文章http://baus.net/on-tcp_cork/《TCP_CORK: More than you ever wanted to know》，文章說，Nagle算法對於數據來自於user input的那種應用是有效的，但是對於數據generated by applications using stream oriented protocols，Nagle算法純粹引入了延遲，這個觀點我非常贊同，因為對於人而言，TCP登錄俄遠程計算機就是一個處理機，人希望自己的操作馬上展示結果，其模式就是write-read-write-read的，但是對於程序而言，其數據產生邏輯就不像人機交互那麽固定，因此你就不能假定程序依照任何序列進行網絡IO，而Nagle算法是和數據IO的序列相關的。實際上就算接收端沒有啟用延遲ACK，Nagle算法應用於write-write-read序列也是有問題的，作者的意思是，平白無故地引入了額外的延遲。
難道真的有這麽復雜嗎？作者沒有提出如何靠編程把問題解決，但是Nagle算法的Wiki頁面上提到了”盡量編寫好的代碼而不要依賴TCP內置的所謂的算法“來優化TCP的行為。
TCP_NODELAY 套接字選項
默認情況下，發送數據采用Negle 算法。這樣雖然提高了網絡吞吐量，但是實時性卻降低了，在一些交互性很強的應用程序來說是不允許的，
使用TCP_NODELAY選項可以禁止Negale 算法。
延遲確認機制（TCP delayed acknowledgment）
wiki的解釋https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment
1989 RFC 1122定義，全名Delayed Acknowledgment，簡稱延遲ACK，翻譯為延遲確認。
與Nagle算法一樣，延遲ACK的目的也是為了減少網絡中傳輸大量的小報文數，但該報文數是針對ACK報文的。
一個來自發送端的報文到達接收端，TCP會延遲ACK的發送，希望應用程序會對剛剛收到的數據進行應答，這樣就可以用新數據將ACK捎帶過去。
當Nagle算法遇到Delayed ACK
在一個有數據傳輸的TCP連接中，如果只有數據發送方啟用Nagle算法，在其連續發送多個小報文時，Nagle算法機制會減少網絡中的小報文數量。這就意味著，同樣傳輸相同大小的應用數據，在網絡上的報文個數卻不同。
舉個例子，發送端需要連續發送5個寫操作（應用程序將數據寫入到緩沖池的動作）的小報文，首先發送第一個，由於Nagle算法的作用，在未收到第一個報文確認前，發送端在等待寫操作的同時進行讀操作，接收端並未啟用延遲確認（視TCP delay ACK時間為0），盡管剛收到該報文就發出確認，但由於網絡延時的原因，在收集齊另外4個小報文後，發送方才收到了第一個報文的ACK，則後面的4個報文會一起發送出去（大小未超過MSS），接收端再次ACK。
在上述發送5個小報文的過程中，只用了4個報文就實現了。但如果發送端未啟用Nagle算法，完成整個過程則至少需要8個報文或10個報文才能實現，這裏接收端未啟用延遲確認，如下圖所示。啟用Nagle算法和未啟用Nagle算法的場景中，從完成數據發送的時間來看，未啟用Nagle算法的方式花費的時間會更長一些，如下圖所示。這裏基本看到了Nagle算法的好處了。
還是上述數據傳輸場景，發送端未啟用Nagle算法，但接收端延遲確認默認時間為200ms，來看看這時的情況。 RFC 1122規定，Delayed ACK對單個的小報文可以延長確認的時間，但不允許有兩個連續的小報文不被確認。所以，當發送端連續發送兩個報文後，接收端必須給予確認。這時的數據傳輸情況如下圖，只有當第5個報文到達後，接收端由於延遲確認機制，會導致200ms的延時存在。
接下來看看，當Nagle算法遇到Delayed ACK時會是什麽情況。按照常理推斷，兩種深思熟慮的功能設計，應該是1+1>2的效果。具體如何，還是請事實說話。
先繼續看上面的假設場景，該場景要求發送端向接收端發送5個連續的寫操作數據，但網絡延時較大，同時發送端啟用Nagle算法，接收端Delayed ACK默認為200ms。
發送方先發出一個小報文，接收端收到後，由於延遲確認的機制，等待發送方的下一個報文到達。而發送方由於Nagle算法機制，在未接收到第一個報文的確認前，不會發送已讀取到的報文。 在這種場景下，暫不考慮應用處理時間，完成整個數據傳輸所需時間為2RTT+400ms，貌似情況不是特別糟糕。
如果上述其他條件不變，發送方應用寫操作延時稍微變大，或發送端的應用操作延時稍大，我們再看看，完成這個操作的延時情況。
發送方先發出一個小報文，接收端收到後，由於延遲確認的機制，等待發送方的下一個報文到達。由於發送方應用數據寫操作延時較大，在經過RTT+200ms後，讀取到了下一個需要發送的內容，此時接收到了第一個報文的確認，而網絡中未有沒被確認的報文，發送方需要再將第二個小報文發送出去，以此類推，直到最後一個小報文被發送，且接收到該報文的確認，此時整個數據傳輸過程完成。
在這種情景下，完成整個數據傳輸所需時間則為5RTT+5*200ms，明顯增大了不少。如果相同情境下，有成千上萬的小報文發送，則整體使用時間相當可觀了。
在實際情況下，如果發送方程序做了一系列的寫、寫、讀操作的現象，這樣的操作都會觸發Nagle和延遲ACK算法之間的交互作用，應該盡量避免。
===========================END===========================
TCP Nagle算法&&延遲確認機制