今天分享一篇文章，是關于 TCP 擁塞控制對數據延遲產生的影響的。作者在服務延遲變高之后進行抓包分析，結果發現時間花在了 TCP 本身的機制上面：客戶端并不是將請求一股腦發送給服務端，而是只發送了一部分，等到接收到服務端的 ACK，然后繼續再發送，這就造成了額外的 RTT，這個額外的 RTT 是由 TCP 的擁塞控制導致的

這是上周在項目上遇到的一個問題，在內網把問題用英文分析了一遍，覺得挺有用的，所以在博客上打算再寫一次。

問題是這樣的：我們在當前的環境中，網絡延遲 <1ms，服務的延遲是 2ms，現在要遷移到一個新的環境，新的環境網絡自身延遲(來回的延遲，RTT，本文中談到延遲都指的是 RTT 延遲)是 100ms，那么請問，服務的延遲應該是多少？

我們的預期是 102ms 左右，但是現實中，發現實際的延遲漲了不止 100ms，P99 到了 300ms 左右。

從日志中，發現有請求的延遲的確很高，但是模式就是 200ms, 300ms 甚至 400ms 左右，看起來是多花了幾個 RTT。

接下來就根據日志去抓包，最后發現，時間花在了 TCP 本身的機制上面，這些高延遲的請求都發生在 TCP 創建連接之后。

首先是 TCP 創建連接的時間，TCP 創建連接需要三次握手，需要額外增加一個 RTT。為什么不是兩個 RTT？因為過程是這樣的：

+0       A -> B SYN 
+0.5RTT  B -> A SYN+ACK 
+1RTT    A -> B ACK 
+1RTT    A -> B Data

即第三個包，在 A 發給 B 之后，A 就繼續發送下面的數據了，所以可以認為這第三個包不會占用額外的時間。

這樣的話，延遲會額外增加一個 RTT，加上本身數據傳輸的一個 RTT，那么，我們能觀察到的最高的 RTT 應該是 2 個 RTT，即 200ms，那么為什么會看到 400ms 的請求呢？

從抓包分析看，我發現在建立 TCP 連接之后，客戶端并不是將請求一股腦發送給服務端，而是只發送了一部分，等到接收到服務端的 ACK，然后繼續在發送，這就造成了額外的 RTT。看到這里我恍然大悟，原來是 cwnd 造成的。

cwnd 如何分析，之前的博文中也提到過。簡單來說，這是 TCP 層面的一個機制，為了避免網絡賽車，在建立 TCP 連接之后，發送端并不知道這個網絡到底能承受多大的流量，所以發送端會發送一部分數據，如果 OK，滿滿加大發送數據的量。這就是 TCP 的慢啟動。

那么慢啟動從多少開始呢？

Linux 中默認是 10.

/usr/src/linux/include/net/tcp.h:
/* TCP initial congestion window as per draft-hkchu-tcpm-initcwnd-01 */
#define TCP_INIT_CWND          10

也就是說，在小于 cwnd=10 * MSS=1448bytes = 14480bytes 數據的情況下，我們可以用 2 RTT 發送完畢數據。即 1 個 RTT 用于建立 TCP 連接，1個 RTT 用于發送數據。

下面這個抓包可以證明這一點，我在 100ms 的環境中，從一端發送了正好 14480 的數據，恰好是用了 200ms：

100ms 用于建立連接，100ms 用于發送數據

如果發送的數據小于 14480 bytes（大約是 14K），那么用的時間應該是一樣的。

但是，如果多了即使 1 byte，延遲也會增加一個 RTT，即需要 300ms。下面是發送 14481 bytes 的抓包情況：

多出來一個 100ms 用于傳輸這個額外的 byte

慢啟動，顧名思義，只發生在啟動階段，如果第一波發出去的數據都能收到確認，那么證明網絡的容量足夠，可以一次性發送更多的數據，這時 cwnd 就會繼續增大了（取決于具體擁塞控制的算法）。

這就是額外的延遲的來源了。回到我們的案例，這個用戶的請求大約是 30K，響應也大約是 30K，而 cwnd 是雙向的，即兩端分別進行慢啟動，所以，請求發送過來 +1 RTT，響應 +1 RTT，TCP 建立連接 +1 RTT，加上本身數據傳輸就有 1 RTT，總共 4RTT，就解釋的通了。

解決辦法也很簡單，兩個問題都可以使用 TCP 長連接來解決。

PS：其實，到這里讀者應該發現，這個服務本身的延遲，在這種情況下，也是 4個 RTT，只不過網絡環境 A 的延遲很小，在 1ms 左右，這樣服務自己處理請求的延遲要遠大于網絡的延遲，1 個 RTT 和 4 個 RTT 從監控上幾乎看不出區別。

PPS：其實，以上內容，比如 “慢啟動，顧名思義，只發生在啟動階段“，以及 ”兩個問題都可以使用 TCP 長連接來解決“ 的表述是不準確的，詳見我們后面又遇到的一個問題：TCP 長連接 CWND reset 的問題分析。

Initial CWND 如果修改的話也有辦法。

這里的 thread 的討論，有人提出了一種方法：大意是允許讓應用程序通過socket參數來設置 CWND 的初始值：

setsockopt(fd, IPPROTO_TCP, TCP_CWND, &val, sizeof (val))

——然后就被罵了個狗血淋頭。

Stephen Hemminger 說 IETF TCP 的家伙已經覺得 Linux 里面的很多東西會允許不安全的應用了。這么做只會證明他們的想法。這個 patch 需要做很多 researech 才考慮。

如果 misuse，比如，應用將這個值設置的很大，那么假設一種情況：網絡發生擁堵了，這時候應用不知道網絡的情況，如果建立連接的話，還是使用一個很大的initcwnd來啟動，會加劇擁堵，情況會原來越壞，永遠不會自動恢復。

David Miller 的觀點是，應用不可能知道鏈路 (Route) 上的特點：

initcwnd是一個路由鏈路上的特點，不是 by application 決定的；

只有人才可能清楚整個鏈路的質量，所以這個選項只能由人 by route 設置。

所以現在只能 by route 設置。

我實驗了一下，將 cwnd 設置為 40:

通過 ip route 命令修改

然后在實驗，可以看到這時候，client 發送的時候，可以一次發送更多的數據了。

后記

現在看這個原因，如果懂一點 TCP，很快就明白其中的原理，很簡單。

但是現實情況是，監控上只能看到 latency 升高了，但是看不出具體是哪一些請求造成的，只知道這個信息的話，那可能的原因就很多了。到這里，發現問題之后，一般就進入了扯皮的階段：中間件的用戶拿著監控（而不是具體的請求日志）去找平臺，平臺感覺是網絡問題，將問題丟給網絡團隊，網絡團隊去檢查他們自己的監控，說他們那邊顯示網絡沒有問題（網絡層的延遲當然沒有問題）。

如果要查到具體原因的話，需要：

先從日志中查找到具體的高延遲的請求。監控是用來發現問題的，而不是用來 debug 的；

從日志分析時間到底花在了哪一個階段；

通過抓包，或者其他手段，驗證步驟2 （這個過程略微復雜，因為要從眾多連接和數據包中找到具體一個 TCP 的數據流）

我發現在大公司里面，這個問題往往牽扯了多個團隊，大家在沒有確認問題就出現在某一個團隊負責的范圍內的時候，就沒有人去這么查。

我在排查的時候，還得到一些錯誤信息，比如開發者告訴我 TCP 連接的保持時間是 10min，然后我從日志看，1min 內連續的請求依然會有高延遲的請求，所以就覺得是 TCP 建立連接 overhead 之外的問題。最后抓包才發現明顯的 SYN 階段包，去和開發核對邏輯，才發現所謂的 10min 保持連接，只是在 Server 側一段做的，Client 側不關心這個時間會將 TCP 直接關掉。

幸好抓到的包不會騙人。

審核編輯：劉清