如果一個 TCP 連接的一端啟用了 Nagle‘s Algorithm，而另一端啟用了 TCP Delayed Ack，而發送的數據包又比較小，則可能會出現這樣的情況：發送端在等 待接收端對上一個packet 的 Ack 才發送當前的 packet，而接收端則正好延遲了 此 Ack 的發送，那么這個正要被發送的 packet 就會同樣被延遲。當然 Delayed Ack 是有個超時機制的，而默認的超時正好就是40ms。

背景

給redis加了一個proxy層， 壓測的時候發現， 對寫入命令，數據長度大于2k后， 性能下降非常明顯， 只有直連redis-server的1/10. 而get請求影響并不是那么明顯。

分析

觀察系統的負載和網絡包量情況， 都比較低， 網絡包量也比較小， proxy內部的耗時也比較短。 無賴只能祭出tcpdump神奇， 果然有妖邪。

22號tcp請求包， 42ms后服務端才返回了ack。 初步懷疑是網絡層的延時導致了耗時增加。Google和km上找資料， 大概的解釋是這樣： 由于客戶端打開了Nagel算法， 服務端未關閉延遲ack， 會導致延遲ack超時后，再發送ack，引起超時。

原理

Nagel算法，轉自維基百科

if there is new data to send

  if the window size >= MSS and available data is >= MSS

    send complete MSS segment now

  else

    if there is unconfirmed data still in the pipe

      enqueue data in the buffer until an acknowledge is received

    else

      send data immediately

    end if

  end if

end if

簡單講， Nagel算法的規則是：

如果發送內容大于1個MSS， 立即發送；
如果之前沒有包未被確認， 立即發送；
如果之前有包未被確認， 緩存發送內容；
如果收到ack， 立即發送緩存的內容。

延遲ACK的源碼如下：net/ipv4/tcp_input.c

基本原理是：

如果收到的數據內容大于一個MSS， 發送ACK；
如果收到了接收窗口以為的數據， 發送ACK；
如果處于quick mode， 發送ACK；
如果收到亂序的數據， 發送ACK；
其他， 延遲發送ACK

其他都比較明確， quick mode是怎么判斷的呢？ 繼續往下看代碼：

影響quick mode的一個因素是 ping pong的狀態。 Pingpong是一個狀態值， 用來標識當前tcp交互的狀態， 以預測是否是W-R-W-R-W-R這種交互式的通訊模式， 如果處于， 可以用延遲ack， 利用Read的回包， 將Write的回包， 捎帶給發送方。

如上圖所示， 默認pingpong = 0， 表示非交互式的， 服務端收到數據后， 立即返回ACK， 當服務端有數據響應時，服務端將pingpong = 1， 以后的交互中， 服務端不會立即返回ack，而是等待有數據或者ACK超時后響應。

問題

按照前面的的原理分析，應該每次都有ACK延遲的，為什么我們測試小于2K的數據時， 性能并沒有受到影響呢？
繼續分析tcpdump包：

按照Nagel算法和延遲ACK機制， 上面的交互如下圖所示， 由于每次發生的數據都包含了完整的請求， 服務端處理完成后， 向客戶端返回命令響應時， 將請求的ACK捎帶給客戶端，節約一次網絡包。

再分析2K的場景：

如下表所示， 第22個包發送的數據小于MSS， 同時，pingpong = 1， 被認為是交互模式， 期待通過捎帶ACK的方式來減少網絡的包量。 但是， 服務端收到的數據，并不是一個完整的包，不能產生一次應答。服務端只能在等待40ms超時后，發送ACK響應包。
同時，從客戶端來看，如果在發送一個包， 也可以打破已收數據 > MSS的限制。 但是，客戶端受Nagel算法的限制， 一次只能有一個包未被確認，其他的數據只能被緩存起來， 等待發送。

觸發場景

一次tcp請求的數據， 不能在服務端產生一次響應，或者小于一個MSS

規避方案

只有同時客戶端打開Nagel算法， 服務端打開tcp_delay_ack才會導致前面的死鎖狀態。 解決方案可以從TCP的兩端來入手。

服務端：

關閉tcp_delay_ack, 這樣， 每個tcp請求包都會有一個ack及時響應， 不會出現延遲的情況。 操作方式：
echo 1 > /proc/sys/net/ipv4/tcp_no_delay_ack
但是， 每個tcp請求都返回一個ack包， 導致網絡包量的增加，關閉tcp延遲確認后， 網絡包量大概增加了80%，在高峰期影響還是比較明顯。

設置TCP_QUICKACK屬性。 但是需要每次recv后再設置一次。 對應我們的場景不太適合，需要修改服務端redis源碼。

總結

以上是生活随笔為你收集整理的Delayed Ack(Ack确认延迟)的全部內容，希望文章能夠幫你解決所遇到的問題。

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