數(shù)據(jù)流分類

• 成塊數(shù)據(jù)
• 交互數(shù)據(jù)

Rlogin需要遠程系統(tǒng)（服務(wù)器）回顯我們（客戶）鍵入的字符 數(shù)據(jù)字節(jié)和數(shù)據(jù)字節(jié)的回顯都需要對方確認

?

? rlogin 每次只發(fā)送一個字節(jié)到服務(wù)器，而Telnet 可以選擇發(fā)送一行 數(shù)據(jù)確認是通過期望數(shù)據(jù)序號 Nagle算法 rlogin發(fā)送一個字節(jié)，就產(chǎn)生41字節(jié)長度的分組： 20字節(jié)IP首部，20字節(jié)TCP首部，1字節(jié)數(shù)據(jù) 防止小分組擁塞 該算法要求一個 TCP連接上最多只能有一個未被確認的未完成的小分組，在該分組的確認到達之前不能發(fā)送其他的小分組。

TCP Nagle算法&&延遲確認機制

?

TCP Nagle算法

http://baike.baidu.com/view/2468335.htm

百度百科：TCP/IP協(xié)議中，無論發(fā)送多少數(shù)據(jù)，總是要在數(shù)據(jù)前面加上協(xié)議頭，同時，對方接收到數(shù)據(jù)，也需要發(fā)送ACK表示確認。為了盡可能的利用網(wǎng)絡(luò)帶寬，TCP總是希望盡可能的發(fā)送足夠大的數(shù)據(jù)。（一個連接會設(shè)置MSS參數(shù)，因此，TCP/IP希望每次都能夠以MSS尺寸的數(shù)據(jù)塊來發(fā)送數(shù)據(jù)）。Nagle算法就是為了盡可能發(fā)送大塊數(shù)據(jù)，避免網(wǎng)絡(luò)中充斥著許多小數(shù)據(jù)塊。（減少大量小包的發(fā)送）

Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認”，是指一個數(shù)據(jù)塊發(fā)送出去后，沒有收到對方發(fā)送的ACK確認該數(shù)據(jù)已收到。

Nagle算法的規(guī)則（可參考tcp_output.c文件里tcp_nagle_check函數(shù)注釋）：

（1）如果包長度達到MSS，則允許發(fā)送；

（2）如果該包含有FIN，則允許發(fā)送；

（3）設(shè)置了TCP_NODELAY選項，則允許發(fā)送；

（4）未設(shè)置TCP_CORK選項時，若所有發(fā)出去的小數(shù)據(jù)包（包長度小于MSS）均被確認，則允許發(fā)送；

（5）上述條件都未滿足，但發(fā)生了超時（一般為200ms），則立即發(fā)送。

Nagle算法只允許一個未被ACK的包存在于網(wǎng)絡(luò)，它并不管包的大小，因此它事實上就是一個擴展的停-等協(xié)議（停止等待ARQ協(xié)議），只不過它是基于包停-等的，而不是基于字節(jié)停-等的。Nagle算法完全由TCP協(xié)議的ACK機制決定，這會帶來一些問題，比如如果對端ACK回復(fù)很快的話，Nagle事實上不會拼接太多的數(shù)據(jù)包，雖然避免了網(wǎng)絡(luò)擁塞，網(wǎng)絡(luò)總體的利用率依然很低。

?

Nagle算法的應(yīng)用場景

在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.

可見編程模型對“減少網(wǎng)絡(luò)上小包數(shù)量”的影響，言外之意，Nagle算法是個有針對性的優(yōu)化-針對交互式應(yīng)用，不是放之四海而皆準(zhǔn)的標(biāo)準(zhǔn)，要想有一個比較好的方案，別指望它了，還是應(yīng)用程序自己搞定才是正解！要想Nagle算法真的能夠減少網(wǎng)絡(luò)上小包數(shù)量而又不引入明顯延遲，對TCP數(shù)據(jù)的產(chǎn)生方式是有要求的，交互式應(yīng)用是其初始針對的對象，，Nagle算法要求數(shù)據(jù)必須是“乒乓型”的，也就是說，數(shù)據(jù)流有明確的邊界且一來一回，類似人機交互的那種，比如telnet這種遠程終端登錄程序，數(shù)據(jù)是人從鍵盤敲入的，邊界基本上就是擊鍵，一來一回就是輸入回顯和處理回顯。Nagle算法在上面的場景中保證了下一個小包發(fā)送之前，所有發(fā)出的包已經(jīng)得到了確認，再次我們看到，Nagle算法并沒有阻止發(fā)送小包，它只是阻止了發(fā)送大量的小包。

換句話說，所謂的“乒乓型”模式就是“write-read-write-read”模式-人機交互模式，但是對于Wiki中指出的“write-write-read”(很多的request/response模式C/S服務(wù)就是這樣的，比如HTTP)-程序交互模式，Nagle算法和延遲ACK（延遲確認機制）拔河的惡果就會被放大。

有一篇很好的文章http://baus.net/on-tcp_cork/《TCP_CORK: More than you ever wanted to know》，文章說，Nagle算法對于數(shù)據(jù)來自于user input的那種應(yīng)用是有效的，但是對于數(shù)據(jù)generated ?by applications using stream oriented protocols，Nagle算法純粹引入了延遲，這個觀點我非常贊同，因為對于人而言，TCP登錄俄遠程計算機就是一個處理機，人希望自己的操作馬上展示結(jié)果，其模式就是write-read-write-read的，但是對于程序而言，其數(shù)據(jù)產(chǎn)生邏輯就不像人機交互那么固定，因此你就不能假定程序依照任何序列進行網(wǎng)絡(luò)IO，而Nagle算法是和數(shù)據(jù)IO的序列相關(guān)的。實際上就算接收端沒有啟用延遲ACK，Nagle算法應(yīng)用于write-write-read序列也是有問題的，作者的意思是，平白無故地引入了額外的延遲。

難道真的有這么復(fù)雜嗎？作者沒有提出如何靠編程把問題解決，但是Nagle算法的Wiki頁面上提到了”盡量編寫好的代碼而不要依賴TCP內(nèi)置的所謂的算法“來優(yōu)化TCP的行為。

?

TCP_NODELAY 套接字選項

默認情況下，發(fā)送數(shù)據(jù)采用Negle 算法。這樣雖然提高了網(wǎng)絡(luò)吞吐量，但是實時性卻降低了，在一些交互性很強的應(yīng)用程序來說是不允許的，

使用TCP_NODELAY選項可以禁止Negale 算法。?

?

延遲確認機制（TCP delayed acknowledgment）

wiki的解釋https://en.wikipedia.org/wiki/TCP_delayed_acknowledgment

1989 RFC 1122定義，全名Delayed Acknowledgment，簡稱延遲ACK，翻譯為延遲確認。?

與Nagle算法一樣，延遲ACK的目的也是為了減少網(wǎng)絡(luò)中傳輸大量的小報文數(shù)，但該報文數(shù)是針對ACK報文的。?

一個來自發(fā)送端的報文到達接收端，TCP會延遲ACK的發(fā)送，希望應(yīng)用程序會對剛剛收到的數(shù)據(jù)進行應(yīng)答，這樣就可以用新數(shù)據(jù)將ACK捎帶過去。 注意：

• 當(dāng)有兩個未確認的包需要確認時，立即發(fā)送ACK

?

當(dāng)Nagle算法遇到Delayed ACK

在一個有數(shù)據(jù)傳輸?shù)腡CP連接中，如果只有數(shù)據(jù)發(fā)送方啟用Nagle算法，在其連續(xù)發(fā)送多個小報文時，Nagle算法機制會減少網(wǎng)絡(luò)中的小報文數(shù)量。這就意味著，同樣傳輸相同大小的應(yīng)用數(shù)據(jù)，在網(wǎng)絡(luò)上的報文個數(shù)卻不同。?

舉個例子，發(fā)送端需要連續(xù)發(fā)送5個寫操作（應(yīng)用程序?qū)?shù)據(jù)寫入到緩沖池的動作）的小報文，首先發(fā)送第一個，由于Nagle算法的作用，在未收到第一個報文確認前，發(fā)送端在等待寫操作的同時進行讀操作，接收端并未啟用延遲確認（視TCP delay ACK時間為0），盡管剛收到該報文就發(fā)出確認，但由于網(wǎng)絡(luò)延時的原因，在收集齊另外4個小報文后，發(fā)送方才收到了第一個報文的ACK，則后面的4個報文會一起發(fā)送出去（大小未超過MSS），接收端再次ACK。

?

在上述發(fā)送5個小報文的過程中，只用了4個報文就實現(xiàn)了。但如果發(fā)送端未啟用Nagle算法，完成整個過程則至少需要8個報文或10個報文才能實現(xiàn)，這里接收端未啟用延遲確認，如下圖所示。啟用Nagle算法和未啟用Nagle算法的場景中，從完成數(shù)據(jù)發(fā)送的時間來看，未啟用Nagle算法的方式花費的時間會更長一些，如下圖所示。這里基本看到了Nagle算法的好處了。

?

還是上述數(shù)據(jù)傳輸場景，發(fā)送端未啟用Nagle算法，但接收端延遲確認默認時間為200ms，來看看這時的情況。?RFC 1122規(guī)定，Delayed ACK對單個的小報文可以延長確認的時間，但不允許有兩個連續(xù)的小報文不被確認。所以，當(dāng)發(fā)送端連續(xù)發(fā)送兩個報文后，接收端必須給予確認。這時的數(shù)據(jù)傳輸情況如下圖，只有當(dāng)?shù)?個報文到達后，接收端由于延遲確認機制，會導(dǎo)致200ms的延時存在。

?

接下來看看，當(dāng)Nagle算法遇到Delayed ACK時會是什么情況。按照常理推斷，兩種深思熟慮的功能設(shè)計，應(yīng)該是1+1>2的效果。具體如何，還是請事實說話。

先繼續(xù)看上面的假設(shè)場景，該場景要求發(fā)送端向接收端發(fā)送5個連續(xù)的寫操作數(shù)據(jù)，但網(wǎng)絡(luò)延時較大，同時發(fā)送端啟用Nagle算法，接收端Delayed ACK默認為200ms。?

發(fā)送方先發(fā)出一個小報文，接收端收到后，由于延遲確認的機制，等待發(fā)送方的下一個報文到達。而發(fā)送方由于Nagle算法機制，在未接收到第一個報文的確認前，不會發(fā)送已讀取到的報文。 ?在這種場景下，暫不考慮應(yīng)用處理時間，完成整個數(shù)據(jù)傳輸所需時間為2RTT+400ms，貌似情況不是特別糟糕。

?

如果上述其他條件不變，發(fā)送方應(yīng)用寫操作延時稍微變大，或發(fā)送端的應(yīng)用操作延時稍大，我們再看看，完成這個操作的延時情況。?

發(fā)送方先發(fā)出一個小報文，接收端收到后，由于延遲確認的機制，等待發(fā)送方的下一個報文到達。由于發(fā)送方應(yīng)用數(shù)據(jù)寫操作延時較大，在經(jīng)過RTT+200ms后，讀取到了下一個需要發(fā)送的內(nèi)容，此時接收到了第一個報文的確認，而網(wǎng)絡(luò)中未有沒被確認的報文，發(fā)送方需要再將第二個小報文發(fā)送出去，以此類推，直到最后一個小報文被發(fā)送，且接收到該報文的確認，此時整個數(shù)據(jù)傳輸過程完成。?

在這種情景下，完成整個數(shù)據(jù)傳輸所需時間則為5RTT+5*200ms，明顯增大了不少。如果相同情境下，有成千上萬的小報文發(fā)送，則整體使用時間相當(dāng)可觀了。

?

在實際情況下，如果發(fā)送方程序做了一系列的寫、寫、讀操作的現(xiàn)象，這樣的操作都會觸發(fā)Nagle和延遲ACK算法之間的交互作用，應(yīng)該盡量避免。

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

轉(zhuǎn)載于:https://www.cnblogs.com/Aiapple/p/7289389.html

總結(jié)

以上是生活随笔為你收集整理的Nagle算法延时确认的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。