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

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

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

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

如果你覺著nagle算法太搗亂了，那么可以通過設(shè)置TCP_NODELAY將其禁用 。當然，更合理的方案還是應(yīng)該使用一次大數(shù)據(jù)的寫操作，而不是多次小數(shù)據(jù)的寫操作。

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