用于自動連接許多的小緩沖器消息;這1進程(稱為nagling)通過減少必須發(fā)送包的個數(shù)來增加網(wǎng)絡(luò)軟件系統(tǒng)的效力

優(yōu) 點
減少堵塞控制

用 于
自動連接許多的小緩沖器消息

簡介

Nagle算法是以他的發(fā)明人John Nagle的名字命名的，它用于自動連接許多的小緩沖器消息;這1進程(稱為nagling)通過減少必須發(fā)送包的個數(shù)來增加網(wǎng)絡(luò)軟件系統(tǒng)的效力。Nagle算法于1984年定義為福特航空和通訊公司IP/TCP堵塞控制方法，這使福特經(jīng)營的最早的專用TCP/IP網(wǎng)絡(luò)減少堵塞控制，從那以后這1方法得到了廣泛利用。Nagle的文檔里定義了處理他所謂的小包問題的方法，這類問題指的是利用程序1次產(chǎn)生1字節(jié)數(shù)據(jù)，這樣會致使網(wǎng)絡(luò)由于太多的包而過載(1個常見的情況是發(fā)送真?zhèn)€”胡涂窗口綜合癥(Silly Windw Syndrome)”)。從鍵盤輸入的1個字符，占用1個字節(jié)，可能在傳輸上造成41字節(jié)的包，其中包括1字節(jié)的有用信息和40字節(jié)的首部數(shù)據(jù)。這類情況轉(zhuǎn)變成了4000%的消耗，這樣的情況對輕負載的網(wǎng)絡(luò)來講還是可以接受的，但是重負載的福特網(wǎng)絡(luò)就受不了了，它沒有必要在經(jīng)過節(jié)點和網(wǎng)關(guān)的時候重發(fā)，致使包丟失和妨礙傳輸速度。吞吐量可能會妨礙乃至在1定程度上會致使連接失敗。Nagle的算法通常會在TCP程序里添加兩行代碼，在未確認數(shù)據(jù)發(fā)送的時候讓發(fā)送器把數(shù)據(jù)送到緩存里。任何數(shù)據(jù)隨后繼續(xù)直到得到明顯的數(shù)據(jù)確認或直到攢到了1定數(shù)量的數(shù)據(jù)了再發(fā)包。雖然Nagle的算法解決的問題只是局限于福特網(wǎng)絡(luò)，但是一樣的問題也可能出現(xiàn)在ARPANet。這類方法在包括因特網(wǎng)在內(nèi)的全部網(wǎng)絡(luò)里得到了推行，成了默許的履行方式，雖然在高互動環(huán)境下有些時候是沒必要要的，例如在客戶/服務(wù)器情形下。在這類情況下，nagling可以通過使用TCP_NODELAY 套接字選項關(guān)閉。

算法

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

Nagle算法的基本定義是任意時刻，最多只能有1個未被確認的小段。 所謂”小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂”未被確認”，是指1個數(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)上述條件都未滿足，但產(chǎn)生了超時(1般為200ms)，則立即發(fā)送。

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

Nagle算法是silly window syndrome(SWS)預(yù)防算法的1個半集。SWS算法預(yù)防發(fā)送少許的數(shù)據(jù)，Nagle算法是其在發(fā)送方的實現(xiàn)，而接收方要做的是不要通告緩沖空間的很小增長，不通知小窗口，除非緩沖區(qū)空間有顯著的增長。這里顯著的增長定義為完全大小的段(MSS)或增長到大于最大窗口的1半。

注意:BSD的實現(xiàn)是允許在空閑鏈接上發(fā)送大的寫操作剩下的最后的小段，也就是說，當(dāng)超過1個MSS數(shù)據(jù)發(fā)送時，內(nèi)核先順次發(fā)送完n個MSS的數(shù)據(jù)包，然后再發(fā)送尾部的小數(shù)據(jù)包，其間不再延時等待。(假定網(wǎng)絡(luò)不阻塞且接收窗口足夠大)

舉個例子，比如之前的blog中的實驗，1開始client端調(diào)用socket的write操作將1個int型數(shù)據(jù)(稱為A塊)寫入到網(wǎng)絡(luò)中，由于此時連接是空閑的(也就是說還沒有未被確認的小段)，因此這個int型數(shù)據(jù)會被馬上發(fā)送到server端，接著，client端又調(diào)用write操作寫入’\r\n’(簡稱B塊)，這個時候，A塊的ACK沒有返回，所以可以認為已存在了1個未被確認的小段，所以B塊沒有立即被發(fā)送，1直等待A塊的ACK收到(大概40ms以后)，B塊才被發(fā)送。全部進程如圖所示:

這里還隱藏了1個問題，就是A塊數(shù)據(jù)的ACK為何40ms以后才收到?這是由于TCP/IP中不單單有nagle算法，還有1個TCP確認延遲機制 。當(dāng)Server端收到數(shù)據(jù)以后，它其實不會馬上向client端發(fā)送ACK，而是會將ACK的發(fā)送延遲1段時間(假定為t)，它希望在t時間內(nèi)server端會向client端發(fā)送應(yīng)對數(shù)據(jù)，這樣ACK就可以夠和應(yīng)對數(shù)據(jù)1起發(fā)送，就像是應(yīng)對數(shù)據(jù)捎帶著ACK過去。在我之前的時間中，t大概就是40ms。這就解釋了為何’\r\n’(B塊)總是在A塊以后40ms才發(fā)出。

固然，TCP確認延遲40ms其實不是1直不變的，TCP連接的延遲確認時間1般初始化為最小值40ms，隨后根據(jù)連接的重傳超時時間(RTO)、上次收到數(shù)據(jù)包與本次接收數(shù)據(jù)包的時間間隔等參數(shù)進行不斷調(diào)劑。另外可以通過設(shè)置TCP_QUICKACK選項來取消確認延遲。

1. TCP_NODELAY 選項

默許情況下，發(fā)送數(shù)據(jù)采取Nagle 算法。這樣雖然提高了網(wǎng)絡(luò)吞吐量，但是實時性卻下降了，在1些交互性很強的利用程序來講是不允許的，使用TCP_NODELAY選項可以制止Nagle 算法。

此時，利用程序向內(nèi)核遞交的每一個數(shù)據(jù)包都會立即發(fā)送出去。需要注意的是，雖然制止了Nagle 算法，但網(wǎng)絡(luò)的傳輸依然遭到TCP確認延遲機制的影響。

1. TCP_CORK 選項

所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數(shù)據(jù)先不發(fā)出去，等到拔去塞子后再發(fā)出去。設(shè)置該選項后，內(nèi)核會盡力把小數(shù)據(jù)包拼接成1個大的數(shù)據(jù)包(1個MTU)再發(fā)送出去，固然若1定時間后(1般為200ms，該值尚待確認)，內(nèi)核依然沒有組合成1個MTU時也必須發(fā)送現(xiàn)有的數(shù)據(jù)(不可能讓數(shù)據(jù)1直等待吧)。

但是，TCP_CORK的實現(xiàn)可能其實不像你想象的那末完善，CORK其實不會將連接完全塞住。內(nèi)核其實其實不知道利用層到底甚么時候會發(fā)送第2批數(shù)據(jù)用于和第1批數(shù)據(jù)拼接以到達MTU的大小，因此內(nèi)核會給出1個時間限制，在該時間內(nèi)沒有拼接成1個大包(努力接近MTU)的話，內(nèi)核就會無條件發(fā)送。也就是說若利用層程序發(fā)送小包數(shù)據(jù)的間隔不夠短時，TCP_CORK就沒有1點作用，反而失去了數(shù)據(jù)的實時性(每一個小包數(shù)據(jù)都會延時1定時間再發(fā)送)。

1. Nagle算法與CORK算法區(qū)分

Nagle算法和CORK算法非常類似，但是它們的著眼點不1樣，Nagle算法主要避免網(wǎng)絡(luò)由于太多的小包(協(xié)議頭的比例非常之大)而堵塞，而CORK算法則是為了提高網(wǎng)絡(luò)的利用率，使得整體上協(xié)議頭占用的比例盡量的小。如此看來這2者在避免發(fā)送小包上是1致的，在用戶控制的層面上，Nagle算法完全不受用戶socket的控制，你只能簡單的設(shè)置TCP_NODELAY而禁用它，CORK算法一樣也是通過設(shè)置或清除TCP_CORK使能或禁用之，但是Nagle算法關(guān)心的是網(wǎng)絡(luò)堵塞問題，只要所有的ACK回來則發(fā)包，而CORK算法卻可以關(guān)心內(nèi)容，在前后數(shù)據(jù)包發(fā)送間隔很短的條件下(很重要，否則內(nèi)核會幫你將分散的包發(fā)出)，即便你是分散發(fā)送多個小數(shù)據(jù)包，你也能夠通過使能CORK算法將這些內(nèi)容拼接在1個包內(nèi)，如果此時用Nagle算法的話，則可能做不到這1點

Nagle算法的門坎

實際上Nagle算法其實不是很復(fù)雜，他的主要職責(zé)是數(shù)據(jù)的積累，實際上有3個門坎：
1）緩沖區(qū)中的字節(jié)數(shù)到達了1定量；
2）等待了1定的時間（1般的Nagle算法都是等待200ms）；
3）緊急數(shù)據(jù)發(fā)送。
這3個門坎的任何1個到達都必須發(fā)送數(shù)據(jù)了。1般情況下，如果數(shù)據(jù)流量很大，第2個條件是永久不會起作用的，但當(dāng)發(fā)送小的數(shù)據(jù)包時，第2個門坎就發(fā)揮作用了，避免數(shù)據(jù)被無窮的緩存在緩沖區(qū)不是好事情哦

1. Nagle算法的選項配置

   TCP_NODELAY和TCP_CORK都是禁用Nagle算法，只不過NODELAY完全關(guān)閉而TCP_CORK完全由自己決定發(fā)送時機。Linux文檔上說二者不要同時設(shè)置。

3.1 TCP_NODELAY 選項

設(shè)置該選項: setsockopt(s,IPPRO_TCP,TCP_NODELAY,(const char*)&on,sizeof(int));
讀取該選項: getsockopt(s,IPPRO_TCP,TCP_NODELAY,(char*)&on,&optlen);

默許情況下, 發(fā)送數(shù)據(jù)采取Nagle 算法. Nagle 算法是指發(fā)送方發(fā)送的數(shù)據(jù)不會立即發(fā)出,而是先放在緩沖區(qū), 等緩存區(qū)滿了再發(fā)出. 發(fā)送完1批數(shù)據(jù)后, 會等待接收方對這批數(shù)據(jù)的回應(yīng),然后再發(fā)送下1批數(shù)據(jù)。
Nagle 算法適用于發(fā)送方需要發(fā)送大批量數(shù)據(jù), 并且接收方會及時作出回應(yīng)的場合, 這類算法通過減少傳輸數(shù)據(jù)的次數(shù)來提高通訊效力。
如果發(fā)送方延續(xù)地發(fā)送小批量的數(shù)據(jù), 并且接收方不1定會立即發(fā)送響應(yīng)數(shù)據(jù), 那末Nagle算法會使發(fā)送方運行很慢。
3.2 TCP_CORK選項

TCP鏈接的進程中，默許開啟Nagle算法，進行小包發(fā)送的優(yōu)化。優(yōu)化網(wǎng)絡(luò)傳輸，統(tǒng)籌網(wǎng)絡(luò)延時和網(wǎng)絡(luò)堵塞。這個時候可以置位TCP_NODELAY關(guān)閉Nagle算法，有數(shù)據(jù)包的話直接發(fā)送保證網(wǎng)絡(luò)時效性。
在進行大量數(shù)據(jù)發(fā)送的時候可以置位TCP_CORK關(guān)閉Nagle算法保證網(wǎng)絡(luò)利用性。盡量的進行數(shù)據(jù)的組包，以最大mtu傳輸，如果發(fā)送的數(shù)據(jù)包大小太小則如果在0.6~0.8S范圍內(nèi)都沒能組裝成1個MTU時，直接發(fā)送。如果發(fā)送的數(shù)據(jù)包大小足夠間隔在0.45內(nèi)時，每次組裝1個MTU進行發(fā)送。如果間隔大于0.4~0.8S則，每過來1個數(shù)據(jù)包就直接發(fā)送。
Nagle組織包的長度是由系統(tǒng)決定的，有時候我們知道我們會每一個1分鐘產(chǎn)生1字節(jié)，共1000字節(jié)。如果完全由Nagle算法來發(fā)送的話，可能還是會1字節(jié)1字節(jié)發(fā)送[這是1種極端情況，假定返回ACK時間不是很長]。這個時候首先設(shè)置TCP_CORK能夠阻塞住TCP[盡可能阻塞住]，等我們write完1000字節(jié)以后，取消TCP_CORK，這個時候就可以夠?qū)?000字節(jié)1次發(fā)出。
總結(jié)：

TCP_CORK選項與TCP_NODELAY1樣，是控制Nagle化的。
1）打開TCP_NODELAY選項，則意味著不管數(shù)據(jù)包是多么的小，都立即發(fā)送（不斟酌堵塞窗口）。
2）如果將TCP連接比喻為1個管道，那TCP_CORK選項的作用就像1個塞子。
設(shè)置TCP_CORK選項，就是用塞子塞住管道，而取消TCP_CORK選項，就是將塞子拔掉。
當(dāng)TCP_CORK選項被設(shè)置時，TCP鏈接不會發(fā)送任何的小包，即只有當(dāng)數(shù)據(jù)量到達MSS時，才會被發(fā)送。
1般當(dāng)數(shù)據(jù)傳輸完成時，通常需要取消該選項，以防被塞住，這樣才可讓不夠MSS大小的包能及時發(fā)出去。
例以下面這段代碼：
1: int on = 1;
2: setsockopt(sockfd, SOL_TCP, TCP_CORK, &on, sizeof(on)); //set TCP_CORK
3: write(sockfd, …); //e.g., http header
4: sendfile(sockfd, …); //e.g., http body
5: on = 0;
6: setsockopt(sockfd, SOL_TCP, TCP_CORK, &on, sizeof(on)); //unset TCP_CORK

Nagle算法的基本定義是任意時刻，最多只能有1個未被確認的小段。 所謂“小段”，指的是小于MSS尺寸的數(shù)據(jù)塊，所謂“未被確認”，是指1個數(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）上述條件都未滿足，但產(chǎn)生了超時（1般為200ms），則立即發(fā)送。


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

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

注意：BSD的實現(xiàn)是允許在空閑鏈接上發(fā)送大的寫操作剩下的最后的小段，也就是說，當(dāng)超過1個MSS數(shù)據(jù)發(fā)送時，內(nèi)核先順次發(fā)送完n個MSS的數(shù)據(jù)包，然后再發(fā)送尾部的小數(shù)據(jù)包，其間不再延時等待。（假定網(wǎng)絡(luò)不阻塞且接收窗口足夠大）

    舉個例子，比如之前的blog中的實驗，1開始client端調(diào)用socket的write操作將1個int型數(shù)據(jù)（稱為A塊）寫入到網(wǎng)絡(luò)中，由于此時連接是空閑的（也就是說還沒有未被確認的小段），因此這個int型數(shù)據(jù)會被馬上發(fā)送到server端，接著，client端又調(diào)用write操作寫入‘\r\n’（簡稱B塊），這個時候，A塊的ACK沒有返回，所以可以認為已存在了1個未被確認的小段，所以B塊沒有立即被發(fā)送，1直等待A塊的ACK收到（大概40ms以后），B塊才被發(fā)送。全部進程如圖所示：

Nagle 算法 - Shiney - Shiney
這里還隱藏了1個問題，就是A塊數(shù)據(jù)的ACK為何40ms以后才收到？這是由于TCP/IP中不單單有nagle算法，還有1個TCP確認延遲機制 。當(dāng)Server端收到數(shù)據(jù)以后，它其實不會馬上向client端發(fā)送ACK，而是會將ACK的發(fā)送延遲1段時間（假定為t），它希望在t時間內(nèi)server端會向client端發(fā)送應(yīng)對數(shù)據(jù)，這樣ACK就可以夠和應(yīng)對數(shù)據(jù)1起發(fā)送，就像是應(yīng)對數(shù)據(jù)捎帶著ACK過去。在我之前的時間中，t大概就是40ms。這就解釋了為何’\r\n’（B塊）總是在A塊以后40ms才發(fā)出。
固然，TCP確認延遲40ms其實不是1直不變的，TCP連接的延遲確認時間1般初始化為最小值40ms，隨后根據(jù)連接的重傳超時時間（RTO）、上次收到數(shù)據(jù)包與本次接收數(shù)據(jù)包的時間間隔等參數(shù)進行不斷調(diào)劑。另外可以通過設(shè)置TCP_QUICKACK選項來取消確認延遲。
關(guān)于TCP確認延遲的詳細介紹可參考：http://blog.csdn.net/turkeyzhou/article/details/6764389

1. TCP_NODELAY 選項

   默許情況下，發(fā)送數(shù)據(jù)采取Negale 算法。這樣雖然提高了網(wǎng)絡(luò)吞吐量，但是實時性卻下降了，在1些交互性很強的利用程序來講是不允許的，使用TCP_NODELAY選項可以制止Negale 算法。
   
   此時，利用程序向內(nèi)核遞交的每一個數(shù)據(jù)包都會立即發(fā)送出去。需要注意的是，雖然制止了Negale 算法，但網(wǎng)絡(luò)的傳輸依然遭到TCP確認延遲機制的影響。
   

2. TCP_CORK 選項

   所謂的CORK就是塞子的意思，形象地理解就是用CORK將連接塞住，使得數(shù)據(jù)先不發(fā)出去，等到拔去塞子后再發(fā)出去。設(shè)置該選項后，內(nèi)核會盡力把小數(shù)據(jù)包拼接成1個大的數(shù)據(jù)包（1個MTU）再發(fā)送出去，固然若1定時間后（1般為200ms，該值尚待確認），內(nèi)核依然沒有組合成1個MTU時也必須發(fā)送現(xiàn)有的數(shù)據(jù)（不可能讓數(shù)據(jù)1直等待吧）。
   但是，TCP_CORK的實現(xiàn)可能其實不像你想象的那末完善，CORK其實不會將連接完全塞住。內(nèi)核其實其實不知道利用層到底甚么時候會發(fā)送第2批數(shù)據(jù)用于和第1批數(shù)據(jù)拼接以到達MTU的大小，因此內(nèi)核會給出1個時間限制，在該時間內(nèi)沒有拼接成1個大包（努力接近MTU）的話，內(nèi)核就會無條件發(fā)送。也就是說若利用層程序發(fā)送小包數(shù)據(jù)的間隔不夠短時，TCP_CORK就沒有1點作用，反而失去了數(shù)據(jù)的實時性（每一個小包數(shù)據(jù)都會延時1定時間再發(fā)送）。
   

3. Nagle算法與CORK算法區(qū)分

   Nagle算法和CORK算法非常類似，但是它們的著眼點不1樣，Nagle算法主要避免網(wǎng)絡(luò)由于太多的小包（協(xié)議頭的比例非常之大）而堵塞，而CORK算法則是為了提高網(wǎng)絡(luò)的利用率，使得整體上協(xié)議頭占用的比例盡量的小。如此看來這2者在避免發(fā)送小包上是1致的，在用戶控制的層面上，Nagle算法完全不受用戶socket的控制，你只能簡單的設(shè)置TCP_NODELAY而禁用它，CORK算法一樣也是通過設(shè)置或清除TCP_CORK使能或禁用之，但是Nagle算法關(guān)心的是網(wǎng)絡(luò)堵塞問題，只要所有的ACK回來則發(fā)包，而CORK算法卻可以關(guān)心內(nèi)容，在前后數(shù)據(jù)包發(fā)送間隔很短的條件下（很重要，否則內(nèi)核會幫你將分散的包發(fā)出），即便你是分散發(fā)送多個小數(shù)據(jù)包，你也能夠通過使能CORK算法將這些內(nèi)容拼接在1個包內(nèi)，如果此時用Nagle算法的話，則可能做不到這1點。