我們來說一說TCP神奇的40ms

qcloud發表於2018-12-24
TCP

本文由雲+社群發表

TCP是一個複雜的協議，每個機制在帶來優勢的同時也會引入其他的問題。 Nagel演算法和delay ack機制是減少傳送端和接收端包量的兩個機制， 可以有效減少網路包量，避免擁塞。但是，在特定場景下， Nagel演算法要求網路中只有一個未確認的包， 而delay ack機制需要等待更多的資料包， 再傳送ACK回包， 導致傳送和接收端等待對方傳送資料， 造成死鎖， 只有當delay ack超時後才能解開死鎖，進而導致應用側對外的延時高。 其他文字已經介紹了相關的機制， 已經有一些文章介紹這種時延的場景。本文結合具體的tcpdump包，分析觸發delay ack的場景，相關的核心引數， 以及規避的方案。

背景

給redis加了一個proxy層， 壓測的時候發現， 對寫入命令，資料長度大於2k後， 效能下降非常明顯， 只有直連redis-server的1/10. 而get請求影響並不是那麼明顯。

img

分析

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

img

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. 如果傳送內容大於1個MSS， 立即傳送；
  2. 如果之前沒有包未被確認， 立即傳送；
  3. 如果之前有包未被確認， 快取傳送內容；
  4. 如果收到ack， 立即傳送快取的內容。

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

img

基本原理是：

  1. 如果收到的資料內容大於一個MSS， 傳送ACK；
  2. 如果收到了接收視窗以為的資料， 傳送ACK；
  3. 如果處於quick mode， 傳送ACK；
  4. 如果收到亂序的資料， 傳送ACK；
  5. 其他， 延遲傳送ACK

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

img

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

img

如上圖所示， 預設pingpong = 0， 表示非互動式的， 服務端收到資料後， 立即返回ACK， 當服務端有資料響應時，服務端將pingpong = 1， 以後的互動中， 服務端不會立即返回ack，而是等待有資料或者ACK超時後響應。

問題

按照前面的的原理分析，應該每次都有ACK延遲的，為什麼我們測試小於2K的資料時， 效能並沒有受到影響呢？

繼續分析tcpdump包：

img

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

img

再分析2K的場景：

img

如下表所示， 第22個包傳送的資料小於MSS， 同時，pingpong = 1， 被認為是互動模式， 期待通過捎帶ACK的方式來減少網路的包量。 但是， 服務端收到的資料，並不是一個完整的包，不能產生一次應答。服務端只能在等待40ms超時後，傳送ACK響應包。

同時，從客戶端來看，如果在傳送一個包， 也可以打破已收資料 > MSS的限制。 但是，客戶端受Nagel演算法的限制， 一次只能有一個包未被確認，其他的資料只能被快取起來， 等待傳送。

img

觸發場景

一次tcp請求的資料， 不能在服務端產生一次響應，或者小於一個MSS

規避方案

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

服務端：

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

img

2.設定TCP_QUICKACK屬性。 但是需要每次recv後再設定一次。 對應我們的場景不太適合，需要修改服務端redis原始碼。

客戶端：

  1. 關閉nagel演算法，即設定socket tcp_no_delay屬性。static void _set_tcp_nodelay(int fd) { int enable = 1; setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, (void*)&enable, sizeof(enable)); }
  2. 避免多次寫， 再讀取的場景， 合併成一個大包的寫；避免一次請求分成多個包傳送， 最開始傳送的包小於一個MSS，對我們的場景， 把第22號包的1424個位元組快取起來， 大於一個MSS的時候，再傳送出去， 服務端立即返回響應， 客戶端繼續傳送後續的資料， 完成互動，避免時延。

此文已由作者授權騰訊雲+社群釋出

相關文章