再說TCP神奇的40ms

版權聲明：本文由安斌原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/186

來源：騰雲閣 https://www.qcloud.com/community

 

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

背景

給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. 若是發送內容大於1個MSS， 當即發送；
2. 若是以前沒有包未被確認， 當即發送；
3. 若是以前有包未被確認， 緩存發送內容；
4. 若是收到ack， 當即發送緩存的內容。

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

基本原理是：

1. 若是收到的數據內容大於一個MSS， 發送ACK；
2. 若是收到了接收窗口覺得的數據， 發送ACK；
3. 若是處於quick mode， 發送ACK；
4. 若是收到亂序的數據， 發送ACK；
5. 其餘， 延遲發送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的兩端來入手。

服務端：

1. 關閉tcp_delay_ack, 這樣， 每一個tcp請求包都會有一個ack及時響應， 不會出現延遲的狀況。 操做方式：
   echo 1 > /proc/sys/net/ipv4/tcp_no_delay_ack
   可是， 每一個tcp請求都返回一個ack包， 致使網絡包量的增長，關閉tcp延遲確認後， 網絡包量大概增長了80%，在高峯期影響仍是比較明顯。
   
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的時候，再發送出去， 服務端當即返回響應， 客戶端繼續發送後續的數據， 完成交互，避免時延。

參考資料：
http://jerrypeng.me/2013/08/mythical-40ms-delay-and-tcp-nodelay/
http://blog.163.com/xychenbaihu@yeah/blog/static/132229655201231214038740/
http://blog.chinaunix.net/uid-28387257-id-3658980.html
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_input.c