TCP 協(xié)議可以說是今天互聯(lián)網(wǎng)的基石，作為可靠的傳輸協(xié)議，在今天幾乎所有的數(shù)據(jù)都會通過 TCP 協(xié)議傳輸，然而 TCP 在設(shè)計(jì)之初沒有考慮到現(xiàn)今復(fù)雜的網(wǎng)絡(luò)環(huán)境，當(dāng)你在地鐵上或者火車上被斷斷續(xù)續(xù)的網(wǎng)絡(luò)折磨時(shí)，你可能都不知道這一切可能都是 TCP 協(xié)議造成的。本文會分析 TCP 協(xié)議為什么在弱網(wǎng)環(huán)境下有嚴(yán)重的性能問題[^1]。

底層的數(shù)據(jù)傳輸協(xié)議在設(shè)計(jì)時(shí)必須要對帶寬的利用率和通信延遲進(jìn)行權(quán)衡和取舍，所以想要解決實(shí)際生產(chǎn)中的全部問題是不可能的，TCP 選擇了充分利用帶寬，為流量而設(shè)計(jì)，期望在盡可能短的時(shí)間內(nèi)傳輸更多的數(shù)據(jù)[^2]。

在網(wǎng)絡(luò)通信中，從發(fā)送方發(fā)出數(shù)據(jù)開始到收到來自接收方的確認(rèn)的時(shí)間被叫做往返時(shí)延（Round-Trip Time，RTT）。

弱網(wǎng)環(huán)境是丟包率較高的特殊場景，TCP 在類似場景中的表現(xiàn)很差，當(dāng) RTT 為 30ms 時(shí)，一旦丟包率達(dá)到了 2%，TCP 的吞吐量就會下降 89.9%[^3]，從下面的表中我們可以看出丟包對 TCP 的吞吐量極其顯著的影響：

RTTTCP 吞吐量TCP 吞吐量（2% 丟包率）0 ms93.5 Mbps3.72 Mbps30 ms16.2 Mbps1.63 Mbps60 ms8.7 Mbps1.33 Mbps90 ms5.32 Mbps0.85 Mbps

本文將分析在弱網(wǎng)環(huán)境下（丟包率高）影響 TCP 性能的三個(gè)原因：

TCP 的擁塞控制算法會在丟包時(shí)主動降低吞吐量；

TCP 的三次握手增加了數(shù)據(jù)傳輸?shù)难舆t和額外開銷；

TCP 的累計(jì)應(yīng)答機(jī)制導(dǎo)致了數(shù)據(jù)段的傳輸；

在上述的三個(gè)原因中，擁塞控制算法是導(dǎo)致 TCP 在弱網(wǎng)環(huán)境下有著較差表現(xiàn)的首要原因，三次握手和累計(jì)應(yīng)答兩者的影響依次遞減，但是也加劇了 TCP 的性能問題。

擁塞控制

TCP 擁塞控制算法是互聯(lián)網(wǎng)上主要的擁塞控制措施，它使用一套基于線増積減（Additive increase/multiplicative decrease，AIMD）的網(wǎng)絡(luò)擁塞控制方法來控制擁塞[^4]，也是造成 TCP 性能問題的主要原因。

第一次發(fā)現(xiàn)的互聯(lián)網(wǎng)擁塞崩潰是在 1986 年，NSFnet 階段一的骨干網(wǎng)的處理能力從 32,000bit/s 降到了 40bit/s，該骨干網(wǎng)的處理能力直到 1987 和 1988 年，TCP 協(xié)議實(shí)現(xiàn)了擁塞控制之后才得到解決[^5]。正是因?yàn)榘l(fā)生過網(wǎng)絡(luò)阻塞造成的崩潰，所以 TCP 的擁塞控制算法就認(rèn)為只要發(fā)生了丟包當(dāng)前網(wǎng)絡(luò)就發(fā)生了擁堵，從這一假設(shè)出發(fā)，TCP 就使用了慢啟動和線增積減[^6]的機(jī)制實(shí)現(xiàn)擁塞控制。

tcp-congestion-control

圖 1 - TCP 的擁塞控制機(jī)制

每一個(gè) TCP 連接都會維護(hù)一個(gè)擁塞控制窗口（Congestion Window），擁塞控制窗口的作用有兩個(gè)：

防止發(fā)送方向接收方發(fā)送了太多數(shù)據(jù)，導(dǎo)致接收方無法處理；

防止 TCP 連接的任意一方向網(wǎng)絡(luò)中發(fā)送大量數(shù)據(jù)，導(dǎo)致網(wǎng)絡(luò)擁塞崩潰；

除了擁塞窗口大小（cwnd）之外，TCP 連接的雙方都有接收窗口大小（rwnd），在 TCP 連接建立之初，發(fā)送方和接收方都不清楚對方的接收窗口大小，所以通信雙方需要一套動態(tài)的估算機(jī)制改變數(shù)據(jù)傳輸?shù)乃俣龋?TCP 三次握手期間，通信雙方會通過 ACK 消息通知對方自己的接收窗口大小，接收窗口大小一般是帶寬延遲乘積（Bandwidth-delay product, BDP）決定的[^7]，不過在這里我們就不展開介紹了。

客戶端能夠同時(shí)傳輸?shù)淖畲髷?shù)據(jù)段的數(shù)量是接收窗口大小和擁塞窗口大小的最小值，即 min(rwnd, cwnd)。TCP 連接的初始擁塞窗口大小是一個(gè)比較小的值，在 Linux 中是由 TCP_INIT_CWND 定義的[^8]：

/* TCP initial congestion window as per rfc6928 */#define TCP_INIT_CWND10

初始擁塞控制窗口的大小從出現(xiàn)之后被多次修改，幾個(gè)名為 Increasing TCP's Initial Window 的 RFC 文檔：RFC2414[^9]、RFC3390[^10] 和 RFC6928[^11] 分別增加了 initcwnd 的值以適應(yīng)不斷提高的網(wǎng)絡(luò)傳輸速度和帶寬。

tcp-congestion-window

圖 2 - TCP 擁塞控制窗口的線増積減

如上圖所示，TCP 連接發(fā)送方的擁塞控制窗口大小會根據(jù)接收方的響應(yīng)而變化：

線性增長：當(dāng)發(fā)送方收到了接收方的 ACK 時(shí)，擁塞窗口大小會加一；

積式減少：當(dāng)發(fā)送方發(fā)送的數(shù)據(jù)包丟包時(shí)，擁塞控制窗口會減半；

如果 TCP 連接剛剛建立，由于 Linux 系統(tǒng)的默認(rèn)設(shè)置，客戶端能夠同時(shí)發(fā)送 10 個(gè)數(shù)據(jù)段，假設(shè)我們網(wǎng)絡(luò)的帶寬是 10M，RTT 是 40ms，每個(gè)數(shù)據(jù)段的大小是 1460 字節(jié)，那么使用 BDP 計(jì)算的通信雙方窗口大小上限應(yīng)該是 35，這樣才能充分利用網(wǎng)絡(luò)的帶寬：

然而擁塞控制窗口的大小從 10 漲到 35 需要 2RTT 的時(shí)間，具體的過程如下：

發(fā)送方向接收方發(fā)送 initcwnd = 10 個(gè)數(shù)據(jù)段（消耗 0.5RTT）；

接收方接收到 10 個(gè)數(shù)據(jù)段后向發(fā)送方發(fā)送 ACK（消耗 0.5RTT）；

發(fā)送方接收到發(fā)送方的 ACK，擁塞控制窗口大小由于 10 個(gè)數(shù)據(jù)段的成功發(fā)送 +10，當(dāng)前擁塞控制窗口大小達(dá)到 20；

發(fā)送方向接收方發(fā)送 20 個(gè)數(shù)據(jù)段（消耗 0.5RTT）；

接收方接收到 20 個(gè)數(shù)據(jù)段后向發(fā)送方發(fā)送 ACK（消耗 0.5RTT）；

發(fā)送方接收到發(fā)送方的 ACK，擁塞控制窗口大小由于 20 個(gè)數(shù)據(jù)段的成功發(fā)送 +20，當(dāng)前擁塞控制窗口大小達(dá)到 40；

從 TCP 三次握手建立連接到擁塞控制窗口大小達(dá)到假定網(wǎng)絡(luò)狀況的最大值 35 需要 3.5RTT 的時(shí)間，即 140ms，這是一個(gè)比較長的時(shí)間了。

早期互聯(lián)網(wǎng)的大多數(shù)計(jì)算設(shè)備都通過有線網(wǎng)絡(luò)連接，出現(xiàn)網(wǎng)絡(luò)不穩(wěn)定的可能性也比較低，所以 TCP 協(xié)議的設(shè)計(jì)者認(rèn)為丟包意味著網(wǎng)絡(luò)出現(xiàn)擁塞，一旦發(fā)生丟包，客戶端瘋狂重試就可能導(dǎo)致互聯(lián)網(wǎng)的擁塞崩潰，所以發(fā)明了擁塞控制算法來解決該問題。

但是如今的網(wǎng)絡(luò)環(huán)境更加復(fù)雜，無線網(wǎng)絡(luò)的引入導(dǎo)致部分場景下的網(wǎng)絡(luò)不穩(wěn)定成了常態(tài)，所以丟包并不一定意味著網(wǎng)絡(luò)擁堵，如果使用更加激進(jìn)的策略傳輸數(shù)據(jù)，在一些場景下會得到更好的效果。

三次握手

TCP 使用三次握手建立連接應(yīng)該是全世界所有工程師都十分了解的知識點(diǎn)，三次握手的主要目的是避免歷史錯(cuò)誤連接的建立并讓通信的雙方確定初始序列號[^12]，然而三次握手的成本相當(dāng)高，在不丟包的情況下，它需要建立 TCP 連接的雙方進(jìn)行三次通信。

basic-3-way-handshake

圖 3 - 常見的 TCP 三次握手

如果我們要從北京訪問上海的服務(wù)器，由于北京到上海的直線距離約為 1000 多公里，而光速是目前通信速度的極限，所以 RTT 一定會大于 6.7ms：

然而因?yàn)楣庠诠饫w中不是直線傳播的，真正的傳輸速度會比光速慢 ~31%[^13]，而且數(shù)據(jù)需要在各種網(wǎng)絡(luò)設(shè)備之間來回跳轉(zhuǎn)，所以很難達(dá)到理論的極限值。在生產(chǎn)環(huán)境中從北京到上海的 RTT 大概在 40ms 左右，所以 TCP 建立連接所需要最短時(shí)間也需要 60ms（1.5RTT）。

在網(wǎng)絡(luò)環(huán)境較差的地鐵、車站等場景中，因?yàn)閬G包率較高，客戶端很難與服務(wù)端快速完成三次通信并建立 TCP 連接。當(dāng)客戶端長時(shí)間沒有收到服務(wù)端的響應(yīng)時(shí)，只能不斷發(fā)起重試，隨著請求次數(shù)逐漸增加，訪問的延遲也會越來越高。

由于大多數(shù)的 HTTP 請求都不會攜帶大量的數(shù)據(jù)，未被壓縮的請求和響應(yīng)頭大小在 ~200B 到 2KB 左右，而 TCP 三次握手帶來的額外開銷是 222 字節(jié)，其中以太網(wǎng)數(shù)據(jù)幀占 3 * 14 = 42 字節(jié)，IP 數(shù)據(jù)幀占 3 * 20 = 60 字節(jié)，TCP 數(shù)據(jù)幀占 120 字節(jié)：

tcp-three-way-handshake-overhead

圖 4 - TCP 三次握手的額外開銷

雖然 TCP 不會為每一個(gè)發(fā)出的數(shù)據(jù)段建立連接，但是三次握手建立連接需要的成本還是相當(dāng)高，不僅需要額外增加 1.5RTT 的網(wǎng)絡(luò)延時(shí)，還需要增加 222 字節(jié)的額外開銷，所以在弱網(wǎng)環(huán)境下，通過三次握手建立連接會加劇 TCP 的性能問題。

重傳機(jī)制

TCP 傳輸?shù)目煽啃允峭ㄟ^序列號和接收方的 ACK 來保證的，當(dāng) TCP 傳輸一個(gè)數(shù)據(jù)段時(shí)，它會將該數(shù)據(jù)段的副本放到重傳隊(duì)列上并開啟計(jì)時(shí)器[^14]：

如果發(fā)送方收到了該數(shù)據(jù)段對應(yīng)的 ACK 響應(yīng)，當(dāng)前數(shù)據(jù)段就會從重傳隊(duì)列中刪除；

如果發(fā)送方在計(jì)時(shí)器到期之間都沒有收到該數(shù)據(jù)段對應(yīng)的 ACK，就會重新發(fā)送當(dāng)前數(shù)據(jù)段；

TCP 的 ACK 機(jī)制可能會導(dǎo)致發(fā)送方重新傳輸接收方已經(jīng)收到了數(shù)據(jù)段。TCP 中的 ACK 消息表示該消息之前的全部消息都已經(jīng)被成功接收和處理，例如：

發(fā)送方向接收方發(fā)送了序號為 1-10 的消息；

接收方向發(fā)送方發(fā)送 ACK 8 響應(yīng)；

發(fā)送方認(rèn)為序號為 1-8 的消息已經(jīng)被成功接收；

這種 ACK 的方式在實(shí)現(xiàn)上比較簡單，更容易保證消息的順序性，但是在以下情況可能會導(dǎo)致發(fā)送方重傳已經(jīng)接收的數(shù)據(jù)：

tcp-retransmission-al

圖 5 - TCP 的重傳策略

如上圖所示，接收方已經(jīng)收到了序號為 2-5 的數(shù)據(jù)，但是由于 TCP ACK 的語義是當(dāng)前數(shù)據(jù)段前的全部數(shù)據(jù)段都已經(jīng)被接收和處理，所以接收方無法發(fā)送 ACK 消息，由于發(fā)送方?jīng)]有收到 ACK，所有數(shù)據(jù)段對應(yīng)的計(jì)時(shí)器就會超時(shí)并重新傳輸數(shù)據(jù)。在丟包較為嚴(yán)重的網(wǎng)絡(luò)下，這種重傳機(jī)制會造成大量的帶寬浪費(fèi)。

總結(jié)

TCP 協(xié)議的一些設(shè)計(jì)在今天來看雖然仍然具有巨大的價(jià)值，但是并不能適用于所有場景。為了解決 TCP 的性能問題，目前業(yè)界有兩種解決方案：

使用 UDP 構(gòu)建性能更加優(yōu)異、更靈活的傳輸協(xié)議，例如：QUIC[^15] 等；

通過不同的手段優(yōu)化 TCP 協(xié)議的性能，例如：選擇性 ACK（Selective ACK, SACK）[^16]，TCP 快開啟（TCP Fast Open, TFO）[^17]；

由于 TCP 協(xié)議在操作系統(tǒng)內(nèi)核中，不利于協(xié)議的更新，所以第一種方案目前發(fā)展的更好，HTTP/3 就使用了 QUIC 作為傳輸協(xié)議[^18]。我們在這里重新回顧一下導(dǎo)致 TCP 性能問題的三個(gè)重要原因：

TCP 的擁塞控制在發(fā)生丟包時(shí)會進(jìn)行退讓，減少能夠發(fā)送的數(shù)據(jù)段數(shù)量，但是丟包并不一定意味著網(wǎng)絡(luò)擁塞，更多的可能是網(wǎng)絡(luò)狀況較差；

TCP 的三次握手帶來了額外開銷，這些開銷不只包括需要傳輸更多的數(shù)據(jù)，還增加了首次傳輸數(shù)據(jù)的網(wǎng)絡(luò)延遲；

TCP 的重傳機(jī)制在數(shù)據(jù)包丟失時(shí)可能會重新傳輸已經(jīng)成功接收的數(shù)據(jù)段，造成帶寬的浪費(fèi)；

TCP 協(xié)議作為互聯(lián)網(wǎng)數(shù)據(jù)傳輸?shù)幕梢哉f是當(dāng)之無愧，雖然它確實(shí)在應(yīng)對特殊場景時(shí)有些問題，但是它的設(shè)計(jì)思想有著非常多的借鑒意義并值得我們學(xué)習(xí)。

到最后，我們還是來看一些比較開放的相關(guān)問題，有興趣的讀者可以仔細(xì)思考一下下面的問題：

QUIC 協(xié)議是能否保證丟包率較高時(shí)的傳輸性能？

除了 SACK 和 TFO 之外還有哪些手段可以優(yōu)化 TCP 的性能？