今天分享一篇文章，是關(guān)于 TCP 擁塞控制對(duì)數(shù)據(jù)延遲產(chǎn)生的影響的。作者在服務(wù)延遲變高之后進(jìn)行抓包分析，結(jié)果發(fā)現(xiàn)時(shí)間花在了 TCP 本身的機(jī)制上面：客戶端并不是將請(qǐng)求一股腦發(fā)送給服務(wù)端，而是只發(fā)送了一部分，等到接收到服務(wù)端的 ACK，然后繼續(xù)再發(fā)送，這就造成了額外的 RTT，這個(gè)額外的 RTT 是由 TCP 的擁塞控制導(dǎo)致的

這是上周在項(xiàng)目上遇到的一個(gè)問(wèn)題，在內(nèi)網(wǎng)把問(wèn)題用英文分析了一遍，覺(jué)得挺有用的，所以在博客上打算再寫(xiě)一次。

問(wèn)題是這樣的：我們?cè)诋?dāng)前的環(huán)境中，網(wǎng)絡(luò)延遲 <1ms，服務(wù)的延遲是 2ms，現(xiàn)在要遷移到一個(gè)新的環(huán)境，新的環(huán)境網(wǎng)絡(luò)自身延遲(來(lái)回的延遲，RTT，本文中談到延遲都指的是 RTT 延遲)是 100ms，那么請(qǐng)問(wèn)，服務(wù)的延遲應(yīng)該是多少？

我們的預(yù)期是 102ms 左右，但是現(xiàn)實(shí)中，發(fā)現(xiàn)實(shí)際的延遲漲了不止 100ms，P99 到了 300ms 左右。

從日志中，發(fā)現(xiàn)有請(qǐng)求的延遲的確很高，但是模式就是 200ms, 300ms 甚至 400ms 左右，看起來(lái)是多花了幾個(gè) RTT。

接下來(lái)就根據(jù)日志去抓包，最后發(fā)現(xiàn)，時(shí)間花在了 TCP 本身的機(jī)制上面，這些高延遲的請(qǐng)求都發(fā)生在 TCP 創(chuàng)建連接之后。

首先是 TCP 創(chuàng)建連接的時(shí)間，TCP 創(chuàng)建連接需要三次握手，需要額外增加一個(gè) RTT。為什么不是兩個(gè) RTT？因?yàn)檫^(guò)程是這樣的：

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

即第三個(gè)包，在 A 發(fā)給 B 之后，A 就繼續(xù)發(fā)送下面的數(shù)據(jù)了，所以可以認(rèn)為這第三個(gè)包不會(huì)占用額外的時(shí)間。

這樣的話，延遲會(huì)額外增加一個(gè) RTT，加上本身數(shù)據(jù)傳輸?shù)囊粋€(gè) RTT，那么，我們能觀察到的最高的 RTT 應(yīng)該是 2 個(gè) RTT，即 200ms，那么為什么會(huì)看到 400ms 的請(qǐng)求呢？

從抓包分析看，我發(fā)現(xiàn)在建立 TCP 連接之后，客戶端并不是將請(qǐng)求一股腦發(fā)送給服務(wù)端，而是只發(fā)送了一部分，等到接收到服務(wù)端的 ACK，然后繼續(xù)在發(fā)送，這就造成了額外的 RTT。看到這里我恍然大悟，原來(lái)是 cwnd 造成的。

cwnd 如何分析，之前的博文中也提到過(guò)。簡(jiǎn)單來(lái)說(shuō)，這是 TCP 層面的一個(gè)機(jī)制，為了避免網(wǎng)絡(luò)賽車，在建立 TCP 連接之后，發(fā)送端并不知道這個(gè)網(wǎng)絡(luò)到底能承受多大的流量，所以發(fā)送端會(huì)發(fā)送一部分?jǐn)?shù)據(jù)，如果 OK，滿滿加大發(fā)送數(shù)據(jù)的量。這就是 TCP 的慢啟動(dòng)。

那么慢啟動(dòng)從多少開(kāi)始呢？

Linux 中默認(rèn)是 10.

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

也就是說(shuō)，在小于 cwnd=10 * MSS=1448bytes = 14480bytes 數(shù)據(jù)的情況下，我們可以用 2 RTT 發(fā)送完畢數(shù)據(jù)。即 1 個(gè) RTT 用于建立 TCP 連接，1個(gè) RTT 用于發(fā)送數(shù)據(jù)。

下面這個(gè)抓包可以證明這一點(diǎn)，我在 100ms 的環(huán)境中，從一端發(fā)送了正好 14480 的數(shù)據(jù)，恰好是用了 200ms：

100ms 用于建立連接，100ms 用于發(fā)送數(shù)據(jù)

如果發(fā)送的數(shù)據(jù)小于 14480 bytes（大約是 14K），那么用的時(shí)間應(yīng)該是一樣的。

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

多出來(lái)一個(gè) 100ms 用于傳輸這個(gè)額外的 byte

慢啟動(dòng)，顧名思義，只發(fā)生在啟動(dòng)階段，如果第一波發(fā)出去的數(shù)據(jù)都能收到確認(rèn)，那么證明網(wǎng)絡(luò)的容量足夠，可以一次性發(fā)送更多的數(shù)據(jù)，這時(shí) cwnd 就會(huì)繼續(xù)增大了（取決于具體擁塞控制的算法）。

這就是額外的延遲的來(lái)源了?；氐轿覀兊陌咐?，這個(gè)用戶的請(qǐng)求大約是 30K，響應(yīng)也大約是 30K，而 cwnd 是雙向的，即兩端分別進(jìn)行慢啟動(dòng)，所以，請(qǐng)求發(fā)送過(guò)來(lái) +1 RTT，響應(yīng) +1 RTT，TCP 建立連接 +1 RTT，加上本身數(shù)據(jù)傳輸就有 1 RTT，總共 4RTT，就解釋的通了。

解決辦法也很簡(jiǎn)單，兩個(gè)問(wèn)題都可以使用 TCP 長(zhǎng)連接來(lái)解決。

PS：其實(shí)，到這里讀者應(yīng)該發(fā)現(xiàn)，這個(gè)服務(wù)本身的延遲，在這種情況下，也是 4個(gè) RTT，只不過(guò)網(wǎng)絡(luò)環(huán)境 A 的延遲很小，在 1ms 左右，這樣服務(wù)自己處理請(qǐng)求的延遲要遠(yuǎn)大于網(wǎng)絡(luò)的延遲，1 個(gè) RTT 和 4 個(gè) RTT 從監(jiān)控上幾乎看不出區(qū)別。

PPS：其實(shí)，以上內(nèi)容，比如 “慢啟動(dòng)，顧名思義，只發(fā)生在啟動(dòng)階段“，以及 ”兩個(gè)問(wèn)題都可以使用 TCP 長(zhǎng)連接來(lái)解決“ 的表述是不準(zhǔn)確的，詳見(jiàn)我們后面又遇到的一個(gè)問(wèn)題：TCP 長(zhǎng)連接 CWND reset 的問(wèn)題分析。

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

這里的 thread 的討論，有人提出了一種方法：大意是允許讓?xiě)?yīng)用程序通過(guò)socket參數(shù)來(lái)設(shè)置 CWND 的初始值：

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

——然后就被罵了個(gè)狗血淋頭。

Stephen Hemminger 說(shuō) IETF TCP 的家伙已經(jīng)覺(jué)得 Linux 里面的很多東西會(huì)允許不安全的應(yīng)用了。這么做只會(huì)證明他們的想法。這個(gè) patch 需要做很多 researech 才考慮。

如果 misuse，比如，應(yīng)用將這個(gè)值設(shè)置的很大，那么假設(shè)一種情況：網(wǎng)絡(luò)發(fā)生擁堵了，這時(shí)候應(yīng)用不知道網(wǎng)絡(luò)的情況，如果建立連接的話，還是使用一個(gè)很大的initcwnd來(lái)啟動(dòng)，會(huì)加劇擁堵，情況會(huì)原來(lái)越壞，永遠(yuǎn)不會(huì)自動(dòng)恢復(fù)。

David Miller 的觀點(diǎn)是，應(yīng)用不可能知道鏈路 (Route) 上的特點(diǎn)：

initcwnd是一個(gè)路由鏈路上的特點(diǎn)，不是 by application 決定的；

只有人才可能清楚整個(gè)鏈路的質(zhì)量，所以這個(gè)選項(xiàng)只能由人 by route 設(shè)置。

所以現(xiàn)在只能 by route 設(shè)置。

我實(shí)驗(yàn)了一下，將 cwnd 設(shè)置為 40:

通過(guò) ip route 命令修改

然后在實(shí)驗(yàn)，可以看到這時(shí)候，client 發(fā)送的時(shí)候，可以一次發(fā)送更多的數(shù)據(jù)了。

后記

現(xiàn)在看這個(gè)原因，如果懂一點(diǎn) TCP，很快就明白其中的原理，很簡(jiǎn)單。

但是現(xiàn)實(shí)情況是，監(jiān)控上只能看到 latency 升高了，但是看不出具體是哪一些請(qǐng)求造成的，只知道這個(gè)信息的話，那可能的原因就很多了。到這里，發(fā)現(xiàn)問(wèn)題之后，一般就進(jìn)入了扯皮的階段：中間件的用戶拿著監(jiān)控（而不是具體的請(qǐng)求日志）去找平臺(tái)，平臺(tái)感覺(jué)是網(wǎng)絡(luò)問(wèn)題，將問(wèn)題丟給網(wǎng)絡(luò)團(tuán)隊(duì)，網(wǎng)絡(luò)團(tuán)隊(duì)去檢查他們自己的監(jiān)控，說(shuō)他們那邊顯示網(wǎng)絡(luò)沒(méi)有問(wèn)題（網(wǎng)絡(luò)層的延遲當(dāng)然沒(méi)有問(wèn)題）。

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

先從日志中查找到具體的高延遲的請(qǐng)求。監(jiān)控是用來(lái)發(fā)現(xiàn)問(wèn)題的，而不是用來(lái) debug 的；

從日志分析時(shí)間到底花在了哪一個(gè)階段；

通過(guò)抓包，或者其他手段，驗(yàn)證步驟2 （這個(gè)過(guò)程略微復(fù)雜，因?yàn)橐獜谋姸噙B接和數(shù)據(jù)包中找到具體一個(gè) TCP 的數(shù)據(jù)流）

我發(fā)現(xiàn)在大公司里面，這個(gè)問(wèn)題往往牽扯了多個(gè)團(tuán)隊(duì)，大家在沒(méi)有確認(rèn)問(wèn)題就出現(xiàn)在某一個(gè)團(tuán)隊(duì)負(fù)責(zé)的范圍內(nèi)的時(shí)候，就沒(méi)有人去這么查。

我在排查的時(shí)候，還得到一些錯(cuò)誤信息，比如開(kāi)發(fā)者告訴我 TCP 連接的保持時(shí)間是 10min，然后我從日志看，1min 內(nèi)連續(xù)的請(qǐng)求依然會(huì)有高延遲的請(qǐng)求，所以就覺(jué)得是 TCP 建立連接 overhead 之外的問(wèn)題。最后抓包才發(fā)現(xiàn)明顯的 SYN 階段包，去和開(kāi)發(fā)核對(duì)邏輯，才發(fā)現(xiàn)所謂的 10min 保持連接，只是在 Server 側(cè)一段做的，Client 側(cè)不關(guān)心這個(gè)時(shí)間會(huì)將 TCP 直接關(guān)掉。

幸好抓到的包不會(huì)騙人。

審核編輯：劉清