Delay ack（延遲確認）

正常情況下服務器收到一個請求時就會立即回復ACK確認給客戶端，然后客戶端再發送下一個包，服務器再進行回復。有時候服務器回復的ACK包有長度，但實際內容長度為0，這也沒關系屬于正常的。不過一次發送一次確認效率比較低，能不能收多次批量確認一次呢？這就是延遲確認。

Delay ack是說收到包不立即回復ack，而是等一會兒默認200毫秒，看看這段時間是否有還有包發過來（屬于同一客戶端）如果有就一起發送ACK確認，如果超時了還沒有等到那么就直接發送這一個確認包。在延遲確認期間ack不是立即發送而是等待200毫秒，如果有就一起發送，或者如果湊夠2個ack包就一起發送；如果在等200毫秒還沒有就發送者一個ACK包。

所以正常情況下抓包都是一個數據包后面緊跟一個ACK確認包。

Nagle算法

如果服務器接收窗口大于MSS并且客戶端要發送的數據大于一個MSS長度（1460）的就立即發送；否則就等待前面發出去包是不是還沒有ACK，如果沒有剩下的小包就等前面的ack返回之后再發送。也就是說包很小，然后又有包發給服務器而且還沒有收到ack，那么就等等ack返回之后再發送剩下的包。

如果客戶端啟用Nagle并且服務器啟用了delay ack會怎么樣？

比如客戶端發送一個HTTP請求給服務器，這個請求有1560個字節，握手的MSS是1460個字節。那么這1560個字節就會分成2個TCP包，第一個1460，第二個100。第一個發送出去后，服務器收到，因為延遲確認，服務器等待200毫秒，客戶端開啟了Nagle（默認開啟）由于第二個包100字節很小，所有它就等待前一個包的ack返回后再進行發送，這時雙方就進入互相等待的階段，直到200毫秒超時，服務器發送ack，然后客戶端再發送剩余的一個包。

再說一個例子引用自：http://www.stuartcheshire.org/papers/nagledelayedack/

傳輸數據是99，900字節，速度5.2M每秒；如果傳輸數據是100，000字節速度是2.7M每秒。多了10字節為什么速度下降這么多？

99,900 bytes = 68 全尺寸包 1448字節每個包，另外剩余1436字節最后一個包

100,000 bytes = 69 全尺寸包 1448字節每個包，另外剩余88字節最后一個包

說明：一個MSS是1460，為什么上面一個包是1448呢？因為那12個字節，因為Windows操作系統是1460，蘋果或者其他操作系統多了一個時間戳選項，TCP分段大小就少了所以是1448個字節。上面的例子是按照Linux操作系統來說的。

68個包會立即發發送，因為68是偶數，所以服務器最后肯定收到2個包，然后發送ACK給客戶端，然后客戶端立即發送剩余的1436字節，整個過程沒有等待。如果是69個包由于是奇數，服務器最后一次收到是1個包，所以等待200毫秒，然后客戶端由于剩下88個字節也會等待，這樣就增加了整體傳輸時間，超時之后再發送最后一個88個字節。

上圖是傳輸100，000字節

上圖是傳輸99，900字節

轉載于:https://blog.51cto.com/littledevil/1966546

總結

以上是生活随笔為你收集整理的TCP/IP之（四）Delay ack 和 Nagle算法的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。