概述

TCP 的性能問題本質(zhì)是公平與效率的取舍問題。

TCP 實(shí)現(xiàn)可靠傳輸層的核心有三點(diǎn)：

(1) 確認(rèn)與重傳 (已經(jīng)可以滿足 “可靠性”，但是可能存在性能問題)

(2) 滑動(dòng)窗口 (也就是流量控制，為了提高吞吐量，充分利用鏈路帶寬，避免發(fā)送方發(fā)的太慢)

(3) 擁塞控制 (防止網(wǎng)絡(luò)鏈路過載造成丟包，避免發(fā)送方發(fā)的太快)

• 滑動(dòng)窗口主要關(guān)注發(fā)送方到接收方的流量控制
• 擁塞控制更多地關(guān)注整個(gè)網(wǎng)絡(luò) (鏈路) 層面的流量控制

滑動(dòng)窗口和擁塞控制相互制約，使發(fā)送方可以從網(wǎng)絡(luò)鏈路的全局角度來自動(dòng)調(diào)整發(fā)送速率，從這個(gè)角度來看，TCP 對(duì)于整個(gè)網(wǎng)絡(luò)的意義已經(jīng)超過 “傳輸層”。

擁塞控制

相比滑動(dòng)窗口，擁塞控制的視角更為全面，會(huì)對(duì)整個(gè)網(wǎng)絡(luò)鏈路中的所有主機(jī)、路由器，以及降低網(wǎng)絡(luò)傳輸性能的有關(guān)因素進(jìn)行綜合考量。

既然擁塞控制要考慮這么多因素，那就不可避免地會(huì)在某些場(chǎng)景下存在所謂 “性能問題”，下面來具體分析下。

1. 慢啟動(dòng)

慢啟動(dòng)本身不會(huì)造成性能問題，因?yàn)槁龁?dòng)時(shí)，cwnd (擁塞窗口大小值) 是指數(shù)級(jí)增長(zhǎng)，所以 “慢啟動(dòng)” 其實(shí)并不慢，這一點(diǎn)我們?cè)谥暗?nbsp;TCP 擁塞控制實(shí)現(xiàn)原理 文章中已經(jīng)講過了。

但是在特定場(chǎng)景下 (如 HTTP)，慢啟動(dòng)會(huì)增加數(shù)據(jù)傳輸?shù)?nbsp;往返次數(shù)。

這里以 Linux 為例，內(nèi)核在 3.0 之后，采用了 Google 的建議，將 cwnd 初始化為 10 個(gè) MSS，默認(rèn)的 MTU 為 1500, MSS 為 1460, 那么，第一次發(fā)送的 TCP 數(shù)據(jù) (Segment) 總量為:

默認(rèn)情況下，ssthresh 值為 65 KB，也就是從 慢啟動(dòng)階段 進(jìn)入到 擁塞避免階段 的閾值。

我們隨便訪問一個(gè)網(wǎng)站的主頁 (例如 stackoverflow.com), 這里就以其首頁 html 文本數(shù)據(jù)大小 (68.8 KB) 為例，說明一下慢啟動(dòng)對(duì)于服務(wù)端發(fā)送響應(yīng)數(shù)據(jù)，帶來了哪些性能影響。

• 第 1 次發(fā)送的數(shù)據(jù)總量為: 14 KB
• 經(jīng)過 1 個(gè) RTT, cwnd 翻倍
• 第 2 次發(fā)送的數(shù)據(jù)總量為: 28 KB
• 經(jīng)過 1 個(gè) RTT, cwnd 再次翻倍
• 第 3 次發(fā)送的數(shù)據(jù)總量為: 56 KB

經(jīng)過 3 次發(fā)送后，14 + 28 + 56 = 98 KB, 首頁 html 文本數(shù)據(jù)傳輸完成，一共經(jīng)歷了 3 個(gè)往返次數(shù)。

當(dāng)網(wǎng)頁資源加載完成后，一般很少再去加載其他資源/數(shù)據(jù)，但是此時(shí)，cwnd 也才剛剛接近 ssthresh 閾值大小。

假設(shè)現(xiàn)在我們消除掉慢啟動(dòng)階段，直接火力全開，第 1 次就發(fā)送數(shù)據(jù)總量: 65 KB, 那么就只需要經(jīng)歷 2 個(gè)往返次數(shù)，就可以完成數(shù)據(jù)傳輸。

2. 擁塞發(fā)生 (丟包)

在基于丟包的擁塞控制算法中 (例如 Reno、Cubic、NewReno), 認(rèn)為一旦發(fā)生丟包，就是網(wǎng)絡(luò)鏈路發(fā)生了擁塞，所以發(fā)送方會(huì)急劇地減小發(fā)送窗口，甚至進(jìn)入短暫的等待狀態(tài)（超時(shí)重傳）。

1% 的丟包率并不只是降低 1% 的傳輸性能，而是可能降低 50% 甚至更多 (取決于具體的 TCP 實(shí)現(xiàn))，此時(shí)就可能出現(xiàn)極端情況: 網(wǎng)絡(luò)花在重傳被丟掉的數(shù)據(jù)包的時(shí)間比發(fā)送新的數(shù)據(jù)包的時(shí)間還要多，所以這是造成 所謂 TCP 性能問題 的最大元兇。

丟包同時(shí)會(huì)加重網(wǎng)絡(luò)鏈路擁塞，假設(shè) 1 個(gè) TCP 數(shù)據(jù)段轉(zhuǎn)發(fā)到第 N 個(gè)路由器，前 N-1 個(gè)路由器已經(jīng)完成轉(zhuǎn)發(fā)，但是第 N 個(gè)路由器轉(zhuǎn)發(fā)時(shí)丟失了數(shù)據(jù)段，最終導(dǎo)致丟失的數(shù)據(jù)段浪費(fèi)了前面所有路由器的帶寬。

TCP Reno 算法發(fā)生丟包時(shí)，性能直接腰斬

TCP Tahoe 算法發(fā)生丟包時(shí)，直接重置，進(jìn)入慢啟動(dòng)過程

這里以 HTTP 場(chǎng)景為例，丟包帶來的影響在 HTTP/2 中表現(xiàn)更為嚴(yán)重，因?yàn)?nbsp;HTTP/2 只使用 1 個(gè) TCP 連接進(jìn)行傳輸。所以 1 次丟包會(huì)導(dǎo)致所有的資源下載速度變慢。而 HTTP/1.1 可能有多個(gè)獨(dú)立的 TCP 連接，1 次丟包也只會(huì)影響其中 1 個(gè) TCP 連接，所以這種場(chǎng)景下 HTTP/1.1 反而會(huì)獲得更好的性能。

3.順序可靠性保證

雖然 TCP 確保所有數(shù)據(jù)包有序到達(dá)，但是這個(gè)順序語義保證可能會(huì)引發(fā)類似 HTTP 隊(duì)列頭部請(qǐng)求阻塞 (head of line blocking) 問題。

TCP 在傳輸時(shí)使用序列號(hào) (Seq) 標(biāo)識(shí)數(shù)據(jù)的順序，一旦某個(gè)數(shù)據(jù)丟失，后續(xù)的數(shù)據(jù)需要保存在接收方的 TCP 緩沖區(qū)中，等待丟失的數(shù)據(jù)重傳完成后，才能進(jìn)行下一步處理 (傳遞到應(yīng)用層)。

應(yīng)用層無法得知 TCP 接收緩沖區(qū)的情況，所以必須等待序列 (Seq) 完整之后才可以獲取應(yīng)用數(shù)據(jù)。但是實(shí)際上，已經(jīng)接收到的數(shù)據(jù)包中，很可能就有應(yīng)用層可以直接處理的數(shù)據(jù)，所以，這也可以稱之為 TCP 隊(duì)列頭部請(qǐng)求阻塞 (head of line blocking) 問題。

4.改進(jìn)和優(yōu)化

針對(duì)基于丟包的擁塞控制算法，最明顯的改進(jìn)就是使用更為合理的擁塞控制算法，例如可以更好地適應(yīng)高帶寬、高時(shí)延、且容忍一定丟包率的 BBR 算法。

如果保證 TCP 可以在 0 丟包 的前提下傳輸數(shù)據(jù)，那么自然而然可以最大化利用帶寬。

??: 思考: 如果高丟包的情況下，使用 UDP 會(huì)獲得更好的性能嗎？

三次握手

除了擁塞控制引起的 "性能問題" 外，TCP 建立連接時(shí)的三次握手機(jī)制，在某些場(chǎng)景下也會(huì)引起性能問題。

對(duì)于大多數(shù) TCP 的使用場(chǎng)景 (長(zhǎng)連接 + 頻繁數(shù)據(jù)傳輸)，三次握手幾乎可以忽略不計(jì)。真正會(huì)造成性能影響的是 長(zhǎng)時(shí)間 + 大量短連接 場(chǎng)景，針對(duì)這個(gè)問題， 可以考慮將短連接改造為長(zhǎng)連接，或者使用 TFO 技術(shù)[1] 來進(jìn)行優(yōu)化。

此外，還有 2 個(gè)會(huì)引發(fā)性能問題的場(chǎng)景是 HTTP 和網(wǎng)絡(luò)切換。

1.HTTP

在 HTTP/1.1 版本中，訪問不同的的資源時(shí) (CSS, Javascript, images ...) 會(huì)使用多個(gè) TCP 連接會(huì)產(chǎn)生大量的延遲，如下圖所示。

使用 HTTP/1.1 訪問時(shí)的瀑布圖

解決方案也很簡(jiǎn)單：直接升級(jí)使用 HTTP/2, 在整個(gè)通信過程中，只會(huì)有 1 個(gè) TCP 連接。

使用 HTTP/2 訪問時(shí)的瀑布圖

除此之外，有的讀者可能會(huì)想到 “弱網(wǎng)絡(luò)” 這個(gè)使用場(chǎng)景 (例如人群密集的地鐵車廂)，但是，既然都是 “弱網(wǎng)絡(luò)” 了，那么使用其他的傳輸協(xié)議也很難規(guī)避這個(gè)問題。

2.網(wǎng)絡(luò)切換

TCP 連接遷移：受限于 TCP 四元組 的限制，如果源 IP 發(fā)生變化，則需要重新建立 TCP 連接，從而導(dǎo)致延遲暫停 (例如當(dāng)前設(shè)備從 Wifi 切換到蜂窩網(wǎng)絡(luò))。

類似的場(chǎng)景，還有多個(gè)物理場(chǎng)所使用不同的出口公網(wǎng) IP 地址，例如學(xué)校的圖書館和宿舍，公司的會(huì)議室和辦公區(qū)，當(dāng)使用者切換物理空間時(shí)，也會(huì)發(fā)送重新建立 TCP 連接。

當(dāng)然，該問題同樣可以通過使用 TFO 技術(shù)[2] 來進(jìn)行優(yōu)化。

確認(rèn)與重傳

這塊 (可能) 會(huì)引發(fā) TCP 性能問題的原因，主要涉及到 3 點(diǎn):

• TCP 超時(shí)重傳帶來的性能影響
• TCP 快速重傳的局限性
• TCP 選擇性重傳解決了哪些問題

細(xì)節(jié)部分在 之前的文章中[3] 已經(jīng)詳細(xì)講過了，本文不再贅述。

小結(jié)

現(xiàn)代 TCP 在理想傳輸條件下，性能只受限于光速和接收方緩沖區(qū) (內(nèi)存) 大小，也就是硬件和物理。

硬件方面，有例如 TOE, NIC 的各種助攻和加速。

所以最終 TCP 在理想情況下的硬件性能受限于:

• 鏈路中最小的帶寬
• 鏈路中最慢的硬件處理
• 鏈路中最小的接收緩沖區(qū)大小

三者結(jié)合起來，也就是通信過程中的所謂 “瓶頸鏈路”。

如果不存在硬件性能限制，也就是在足夠的帶寬、足夠的內(nèi)存、足夠的處理速度的前提下，TCP 的性能理論上只受限于物理，也就是光速。

最后，再次搬上大佬語錄:

網(wǎng)絡(luò)編程中，開發(fā)者遇到的實(shí)際問題，大約有 90% 都和開發(fā)者對(duì)于 TCP/IP 的理解有關(guān)。不要對(duì) TCP 和 UDP 的相對(duì)性能做任何先驗(yàn)假設(shè)，即使是很小的擦不參數(shù)改變，都可能對(duì)性能產(chǎn)生嚴(yán)重影響。