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將其禁用 。當然，更合理的方案還是應該使用一次大數據的寫操作，而不是多次小數據的寫操作。

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/historyasamirror/archive/2011/05/15/6423235.aspx