如果一個 TCP 連接的一端啟用了 Nagle‘s Algorithm，而另一端啟用了 TCP Delayed Ack，而發送的數據包又比較小，則可能會出現這樣的情況：發送端在等 待接收端對上一個packet 的 Ack 才發送當前的 packet，而接收端則正好延遲了 此 Ack 的發送，那么這個正要被發送的 packet 就會同樣被延遲。當然 Delayed Ack 是有個超時機制的，而默認的超時正好就是40ms。
1.Delayed Ack
tcp協議規定在接受到數據段時需要向對方發送一個確認,但如果只是單純的發送一個確認,代價會比較高(20字節的ip首部,20字節的tcp首部),最好能附帶響應數據一起發送給對?方.所以tcp在何時發送ack給對方有以下規定:
1) 當有響應數據要發送時,ack會隨響數據立即發送給對方.
2) 如果沒有響應數據,ack的發?送將會有一個延遲,以等待看是否有響應數據可以一起發送?,這稱是"Delayed Ack".但這個延遲最多不會超過500ms,一般為200ms.如果在200ms內有數據要發送,那么ack會隨數據一起立即發送給對方.注意這里的延遲200ms,不是指的從接受到對方數據到發送ack的最長等待時間差.而是指的內核啟動的一個定時器,它每隔200ms就查看下是否有ack要發送.例如:假設定時器在0ms時啟動,對方的數據段在
185ms時到達,那么ack最遲會在200ms時發送,而不是385ms時發送.
3) 如果在等待發送ack期間,對方的第二個數據段又到達了,這時要立即發送ack.但是如果對方的三個數據段相繼?到達,那么第二個數據段到達時ack立即發送,但第三個數據段到達時是否立即發送,則取決于上面兩條.
2.Nagle Algorithm
當tcp協議用來傳輸小的數據段時代碼是很高的,并且如果傳輸是在廣域網上,那可能就會引起網絡擁塞.Nagle算法就是用來解決這個問題.該算法要求一個TCP連接上最多只能有一個未被確認(未收到Ack確認)的未完成的小分組，在該分組的確認到達之前不能發送其他的小分組。相反TCP收集這些少量的分組，并在確認到來時以一?個分組的方式發出去.Host Requirements RFC聲明TCP必須實現Nagle算法，但必須為應用提供一種方法來關閉該算法在某個連接上執行。
納格算法是合并(coalescing)一定數量的輸出資料后一次送出。特別的是，只要有已送出的封包尚未確認，傳送者會持續緩沖封包，直到累積一定數量的資料才送出。
算法如下如下：
if 有新資料要傳送
if 訊窗大小 >= MSS and 可傳送的資料 >= MSS
? ? 立刻傳送完整MSS大小的segment
else
? ? ?if ?管線中有尚未確認的資料
? ? ? ? ?在下一個確認(ACK)封包收到前，將資料排進緩沖區佇列
? ? ?else
? ? ? ? ?(?MSS=最大segment大小)
為什么要同時介紹這兩個知識呢？
因為這兩個技術同時使用的話會出現問題，下面來看一下問題的出現場景:
A 和B進行數據傳輸 : ?A運行Nagle算法，B運行delayed ACK算法
1. A->B 發一個packet(數據包), B不回應，delay ACK
2. A-> 再發一個packet(數據包)
3. B收到第二個packet(數據包)，這時候會回應第一個packet(數據包)，即第一個ACK
4. 假設這時候A里的數據已經
此時問題就來了，因為A沒有收到第二個packet的ACK確認，同時數據
當然我們從上面可以看到這種等待機制還是有副作用的，那就是需要等待：一項數據表明：
在以太網上,傳輸100000字節僅需1ms,但由于delayed ack和nagle的作用卻要花費201ms,這顯然對程序的效率產生了很大影響.
TCP/IP協議中，無論發送多少數據，總是要在數據前面加上協議頭，同時，對方接收到數據，也需要發送ACK表示確認。為了盡可能的利用網絡帶寬，TCP總是希望盡可能的發送足夠大的數據。（一個連接會設置MSS參數，因此，TCP/IP希望每次都能夠以MSS尺寸的數據塊來發送數據）。
Nagle算法就是為了盡可能發送大塊數據，避免網絡中充斥著許多小數據塊。
Nagle算法的基本定義是任意時刻，最多只能有一個未被確認的小段。
所謂“小段”，指的是小于MSS尺寸的數據塊，
所謂“未被確認”，是指一個數據塊發送出去后，沒有收到對方發送的ACK確認該數據已收到。
舉個例子，比如之前的blog中的實驗，一開始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算法，還有一個ACK延遲機制。當Server端收到數據之后，它并不會馬上向client端發送ACK，而是會將ACK的發送延遲一段時間（假設為t），它希望在t時間內server端會向client端發送應答數據，這樣ACK就能夠和應答數據一起發送，就像是應答數據捎帶著ACK過去。在我之前的時間中，t大概就是40ms。這就解釋了為什么'/r/n'(B塊)總是在A塊之后40ms才發出。
如果你覺著nagle算法太搗亂了，那么可以通過設置TCP_NODELAY將其禁用。當然，更合理的方案還是應該使用一次大數據的寫操作，而不是多次小數據的寫操作。
