TCP/IP協議中，無論發送多少數據，總是要在數據前面加上協議頭，同時，對方接收到數據，也需要發送ACK表示確認。為了盡可能的利用網絡帶寬，TCP總是希望盡可能的發送足夠大的數據。（一個連接會設置MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的數據塊來發送數據）。Nagle算法就是為了盡可能發送大塊數據，避免網絡中充斥著許多小數據塊。

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

????????Nagle算法的規則（：

??????（1）如果包長度達到MSS，則允許發送；

??????（2）如果該包含有FIN，則允許發送；

??????（3）設置了TCP_NODELAY選項，則允許發送；

??????（4）未設置TCP_CORK選項時，若所有發出去的小數據包（包長度小于MSS）均被確認，則允許發送；

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

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

??????Nagle算法是silly?window?syndrome(SWS)預防算法的一個半集。SWS算法預防發送少量的數據，Nagle算法是其在發送方的實現，而接收方要做的時不要通告緩沖空間的很小增長，不通知小窗口，除非緩沖區空間有顯著的增長。這里顯著的增長定義為完全大小的段（MSS）或增長到大于最大窗口的一半。

?注意：BSD的實現是允許在空閑鏈接上發送大的寫操作剩下的最后的小段，也就是說，當超過1個MSS數據發送時，內核先依次發送完n個MSS的數據包，然后再發送尾部的小數據包，其間不再延時等待。（假設網絡不阻塞且接收窗口足夠大）。

?????舉個例子，一開始client端調用socket的write操作將一個int型數據（稱為A塊）寫入到網絡中，由于此時連接是空閑的（也就是說還沒有未被確認的小段），因此這個int型數據會被馬上發送到server端，接著，client端又調用write操作寫入‘\r\n’（簡稱B塊），這個時候，A塊的ACK沒有返回，所以可以認為已經存在了一個未被確認的小段，所以B塊沒有立即被發送，一直等待A塊的ACK收到（大概40ms之后），B塊才被發送。整個過程如圖所示：

??????這里還隱藏了一個問題，就是A塊數據的ACK為什么40ms之后才收到？這是因為TCP/IP中不僅僅有nagle算法，還有一個TCP確認延遲機制?。當Server端收到數據之后，它并不會馬上向client端發送ACK，而是會將ACK的發送延遲一段時間（假設為t），它希望在t時間內server端會向client端發送應答數據，這樣ACK就能夠和應答數據一起發送，就像是應答數據捎帶著ACK過去。在我之前的時間中，t大概就是40ms。這就解釋了為什么'\r\n'（B塊）總是在A塊之后40ms才發出。

???????當然，TCP確認延遲40ms并不是一直不變的，TCP連接的延遲確認時間一般初始化為最小值40ms，隨后根據連接的重傳超時時間（RTO）、上次收到數據包與本次接收數據包的時間間隔等參數進行不斷調整。另外可以通過設置TCP_QUICKACK選項來取消確認延遲。

??????關于TCP確認延遲的詳細介紹可參考：http://blog.csdn.net/turkeyzhou/article/details/6764389

2.?TCP_NODELAY?選項

??????默認情況下，發送數據采用Negale?算法。這樣雖然提高了網絡吞吐量，但是實時性卻降低了，在一些交互性很強的應用程序來說是不允許的，使用TCP_NODELAY選項可以禁止Negale?算法。

??????此時，應用程序向內核遞交的每個數據包都會立即發送出去。需要注意的是，雖然禁止了Negale?算法，但網絡的傳輸仍然受到TCP確認延遲機制的影響。

3.?TCP_CORK?選項

?????所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數據先不發出去，等到拔去塞子后再發出去。設置該選項后，內核會盡力把小數據包拼接成一個大的數據包（一個MTU）再發送出去，當然若一定時間后（一般為200ms，該值尚待確認），內核仍然沒有組合成一個MTU時也必須發送現有的數據（不可能讓數據一直等待吧）。

??????然而，TCP_CORK的實現可能并不像你想象的那么完美，CORK并不會將連接完全塞住。內核其實并不知道應用層到底什么時候會發送第二批數據用于和第一批數據拼接以達到MTU的大小，因此內核會給出一個時間限制，在該時間內沒有拼接成一個大包（努力接近MTU）的話，內核就會無條件發送。也就是說若應用層程序發送小包數據的間隔不夠短時，TCP_CORK就沒有一點作用，反而失去了數據的實時性（每個小包數據都會延時一定時間再發送）。

4.?Nagle算法與CORK算法區別

?????Nagle算法和CORK算法非常類似，但是它們的著眼點不一樣，Nagle算法主要避免網絡因為太多的小包（協議頭的比例非常之大）而擁塞，而CORK算法則是為了提高網絡的利用率，使得總體上協議頭占用的比例盡可能的小。如此看來這二者在避免發送小包上是一致的，在用戶控制的層面上，Nagle算法完全不受用戶socket的控制，你只能簡單的設置TCP_NODELAY而禁用它，CORK算法同樣也是通過設置或者清除TCP_CORK使能或者禁用之，然而Nagle算法關心的是網絡擁塞問題，只要所有的ACK回來則發包，而CORK算法卻可以關心內容，在前后數據包發送間隔很短的前提下（很重要，否則內核會幫你將分散的包發出），即使你是分散發送多個小數據包，你也可以通過使能CORK算法將這些內容拼接在一個包內，如果此時用Nagle算法的話，則可能做不到這一點。

????實際上Nagle算法并不是很復雜，他的主要職責是數據的累積，實際上有兩個門檻：一個就是緩?沖區中的字節數達到了一定量，另一個就是等待了一定的時間（一般的Nagle算法都是等待200ms）；這兩個門檻的任何一個達到都必須發送數據了。一般?情況下，如果數據流量很大，第二個條件是永遠不會起作用的，但當發送小的數據包時，第二個門檻就發揮作用了，防止數據被無限的緩存在緩沖區不是好事情哦。?了解了TCP的Nagle算法的原理之后我們可以自己動手來實現一個類似的算法了，在動手之前我們還要記住一個重要的事情，也是我們動手實現Nagle算?法的主要動機就是我想要緊急發送數據的時候就要發送了，所以對于上面的兩個門檻之外還的增加一個門檻就是緊急數據發送。

????對于我現在每秒鐘10次數據發送，每次數據發送量固定在85~100字節的應用而言，如果采用默認的開啟Nagle算法，我在發送端，固定每幀數據85個，間隔100ms發送一次，我在接受端（阻塞方式使用）接受的數據是43?138交替出現，可能就是這個算法的時間閾值問題，如果關閉Nagle算法，在接收端就可以保證數據每次接收到的都是85幀。

????Nagle算法適用于小包、高延遲的場合，而對于要求交互速度的b/s或c/s就不合適了。socket在創建的時候，默認都是使用Nagle算法的，這會導致交互速度嚴重下降，所以需要setsockopt函數來設置TCP_NODELAY為1.不過取消了Nagle算法，就會導致TCP碎片增多，效率可能會降低。

關閉nagle算法,以免影響性能，因為控制時控制端要發送很多數據量很小的數據包,需要馬上發送。

?const?char?chOpt?=?1;

int?nErr?=?setsockopt(pContext->m_Socket,?IPPROTO_TCP,?TCP_NODELAY,?&chOpt,?sizeof(char));

if?(nErr?==?-1)

{

????TRACE(_T("setsockopt()?error\n"),WSAGetLastError());

????return;

}

總結

以上是生活随笔為你收集整理的socket中的nagle算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。