如果一個(gè) TCP 連接的一端啟用了 Nagle‘s Algorithm，而另一端啟用了 TCP Delayed Ack，而發(fā)送的數(shù)據(jù)包又比較小，則可能會(huì)出現(xiàn)這樣的情況：發(fā)送端在等 待接收端對(duì)上一個(gè)packet 的 Ack 才發(fā)送當(dāng)前的 packet，而接收端則正好延遲了 此 Ack 的發(fā)送，那么這個(gè)正要被發(fā)送的 packet 就會(huì)同樣被延遲。當(dāng)然 Delayed Ack 是有個(gè)超時(shí)機(jī)制的，而默認(rèn)的超時(shí)正好就是40ms。

背景

給redis加了一個(gè)proxy層， 壓測(cè)的時(shí)候發(fā)現(xiàn)， 對(duì)寫(xiě)入命令，數(shù)據(jù)長(zhǎng)度大于2k后， 性能下降非常明顯， 只有直連redis-server的1/10. 而get請(qǐng)求影響并不是那么明顯。

分析

觀察系統(tǒng)的負(fù)載和網(wǎng)絡(luò)包量情況， 都比較低， 網(wǎng)絡(luò)包量也比較小， proxy內(nèi)部的耗時(shí)也比較短。 無(wú)賴只能祭出tcpdump神奇， 果然有妖邪。

22號(hào)tcp請(qǐng)求包， 42ms后服務(wù)端才返回了ack。 初步懷疑是網(wǎng)絡(luò)層的延時(shí)導(dǎo)致了耗時(shí)增加。Google和km上找資料， 大概的解釋是這樣： 由于客戶端打開(kāi)了Nagel算法， 服務(wù)端未關(guān)閉延遲ack， 會(huì)導(dǎo)致延遲ack超時(shí)后，再發(fā)送ack，引起超時(shí)。

原理

Nagel算法，轉(zhuǎn)自維基百科

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

簡(jiǎn)單講， Nagel算法的規(guī)則是：

如果發(fā)送內(nèi)容大于1個(gè)MSS， 立即發(fā)送；
如果之前沒(méi)有包未被確認(rèn)， 立即發(fā)送；
如果之前有包未被確認(rèn)， 緩存發(fā)送內(nèi)容；
如果收到ack， 立即發(fā)送緩存的內(nèi)容。

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

基本原理是：

如果收到的數(shù)據(jù)內(nèi)容大于一個(gè)MSS， 發(fā)送ACK；
如果收到了接收窗口以為的數(shù)據(jù)， 發(fā)送ACK；
如果處于quick mode， 發(fā)送ACK；
如果收到亂序的數(shù)據(jù)， 發(fā)送ACK；
其他， 延遲發(fā)送ACK

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

影響quick mode的一個(gè)因素是 ping pong的狀態(tài)。 Pingpong是一個(gè)狀態(tài)值， 用來(lái)標(biāo)識(shí)當(dāng)前tcp交互的狀態(tài)， 以預(yù)測(cè)是否是W-R-W-R-W-R這種交互式的通訊模式， 如果處于， 可以用延遲ack， 利用Read的回包， 將Write的回包， 捎帶給發(fā)送方。

如上圖所示， 默認(rèn)pingpong = 0， 表示非交互式的， 服務(wù)端收到數(shù)據(jù)后， 立即返回ACK， 當(dāng)服務(wù)端有數(shù)據(jù)響應(yīng)時(shí)，服務(wù)端將pingpong = 1， 以后的交互中， 服務(wù)端不會(huì)立即返回ack，而是等待有數(shù)據(jù)或者ACK超時(shí)后響應(yīng)。

問(wèn)題

按照前面的的原理分析，應(yīng)該每次都有ACK延遲的，為什么我們測(cè)試小于2K的數(shù)據(jù)時(shí)， 性能并沒(méi)有受到影響呢？
繼續(xù)分析tcpdump包：

按照Nagel算法和延遲ACK機(jī)制， 上面的交互如下圖所示， 由于每次發(fā)生的數(shù)據(jù)都包含了完整的請(qǐng)求， 服務(wù)端處理完成后， 向客戶端返回命令響應(yīng)時(shí)， 將請(qǐng)求的ACK捎帶給客戶端，節(jié)約一次網(wǎng)絡(luò)包。

再分析2K的場(chǎng)景：

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

觸發(fā)場(chǎng)景

一次tcp請(qǐng)求的數(shù)據(jù)， 不能在服務(wù)端產(chǎn)生一次響應(yīng)，或者小于一個(gè)MSS

規(guī)避方案

只有同時(shí)客戶端打開(kāi)Nagel算法， 服務(wù)端打開(kāi)tcp_delay_ack才會(huì)導(dǎo)致前面的死鎖狀態(tài)。 解決方案可以從TCP的兩端來(lái)入手。

服務(wù)端：

關(guān)閉tcp_delay_ack, 這樣， 每個(gè)tcp請(qǐng)求包都會(huì)有一個(gè)ack及時(shí)響應(yīng)， 不會(huì)出現(xiàn)延遲的情況。 操作方式：
echo 1 > /proc/sys/net/ipv4/tcp_no_delay_ack
但是， 每個(gè)tcp請(qǐng)求都返回一個(gè)ack包， 導(dǎo)致網(wǎng)絡(luò)包量的增加，關(guān)閉tcp延遲確認(rèn)后， 網(wǎng)絡(luò)包量大概增加了80%，在高峰期影響還是比較明顯。

設(shè)置TCP_QUICKACK屬性。 但是需要每次recv后再設(shè)置一次。 對(duì)應(yīng)我們的場(chǎng)景不太適合，需要修改服務(wù)端redis源碼。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。