TCP中的Nagle演算法

TCP中的Nagle演算法

一. Nagel演算法TCP/IP協議中,無論發送多少資料,總是要在資料前面加上協議頭,同時,對方接收到資料,也需要發送ACK表示確認.為了儘可能的利用網路頻寬,TCP總是希望儘可能的發送足夠大的資料.(在一個串連中會設定MSS參數,因此,TCP/IP希望每次都能夠以MSS尺寸的資料區塊來發送資料).Nagle演算法就是為了儘可能發送大塊資料,避免網路中充斥著許多小資料區塊.
基於包停-等的,而不是基於位元組停-等的.Nagle演算法完全由TCP協議的ACK機制決定,這會帶來一些問題,比如如果對端ACK回複很快的話,Nagle事實上不會拼接太多的資料包,雖然避免了網路擁塞,網路總體的利用率依然很低.

注意： BSD的實現是允許在空閑連結上發送大的寫操作剩下的最後的小段,也就是說,當超過1個MSS資料發送時,核心先依次發送完n個MSS的資料包,然後再發送尾部的小資料包,其間不再延時等待(假設網路不阻塞且接收視窗足夠大).

二.TCP_NODELAY 選項

預設情況下,發送資料採用Negale演算法.這樣雖然提高了網路輸送量,但是即時性卻降低了,在一些互動性很強的應用程式來說是不允許的,使用TCP_NODELAY選項可以禁止Negale 演算法.此時，應用程式向核心遞交的每個資料包都會立即發送出去.需要注意的是,雖然禁止了Negale 演算法,但網路的傳輸仍然受到TCP確認延遲機制的影響.
 

三.TCP_CORK 選項所謂的CORK就是塞子的意思,形象地理解就是用CORK將串連塞住,使得資料先不發出去,等到拔去塞子後再發出去.設定該選項後,核心會儘力把小資料包拼接成一個大的資料包(一個MTU)再發送出去,當然若一定時間後(一般為200ms,該值尚待確認),核心仍然沒有組合成一個MTU時也必鬚髮送現有的資料(不可能讓資料一直等待吧).
四.Nagle演算法與CORK演算法區別

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