TCP 到底有什麼性能問題？

概述

TCP 的性能問題本質是公平與效率的取捨問題。

TCP 實現可靠傳輸層的核心有三點：

  1. 確認與重傳 (已經可以滿足 “可靠性”，但是可能存在性能問題)

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

  3. 擁塞控制 (防止網絡鏈路過載造成丟包，避免發送方發的太快)

滑動窗口主要關注發送方到接收方的流量控制

擁塞控制更多地關注整個網絡 (鏈路) 層面的流量控制

滑動窗口和擁塞控制相互制約，使發送方可以從網絡鏈路的全局角度來自動調整發送速率，從這個角度來看，TCP 對於整個網絡的意義已經超過 “傳輸層”。

擁塞控制

相比滑動窗口，擁塞控制的視角更爲全面，會對整個網絡鏈路中的所有主機、路由器，以及降低網絡傳輸性能的有關因素進行綜合考量。

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

1. 慢啓動

慢啓動本身不會造成性能問題，因爲慢啓動時，cwnd (擁塞窗口大小值) 是指數級增長，所以 “慢啓動” 其實並不慢，這一點我們在之前的 TCP 擁塞控制實現原理 文章中已經講過了。

但是在特定場景下 (如 HTTP)，慢啓動會增加數據傳輸的 往返次數。

這裏以 Linux 爲例，內核在 3.0 之後，採用了 Google 的建議，將 cwnd 初始化爲 10 個 MSS，默認的 MTU 爲 1500, MSS 爲 1460, 那麼，第一次發送的 TCP 數據 (Segment) 總量爲:

ZGz1uN

默認情況下，ssthresh 值爲 65 KB，也就是從 慢啓動階段 進入到 擁塞避免階段 的閾值。

我們隨便訪問一個網站的主頁 (例如 stackoverflow.com), 這裏就以其首頁 html 文本數據大小 (68.8 KB) 爲例，說明一下慢啓動對於服務端發送響應數據，帶來了哪些性能影響。

  1. 第 1 次發送的數據總量爲: 14 KB

  2. 經過 1 個 RTT, cwnd 翻倍

  3. 第 2 次發送的數據總量爲: 28 KB

  4. 經過 1 個 RTT, cwnd 再次翻倍

  5. 第 3 次發送的數據總量爲: 56 KB

經過 3 次發送後，14 + 28 + 56 = 98 KB, 首頁 html 文本數據傳輸完成，一共經歷了 3 個往返次數。

當網頁資源加載完成後，一般很少再去加載其他資源 / 數據，但是此時，cwnd 也纔剛剛接近 ssthresh 閾值大小。

假設現在我們消除掉慢啓動階段，直接火力全開，第 1 次就發送數據總量: 65 KB, 那麼就只需要經歷 2 個往返次數，就可以完成數據傳輸。

2. 擁塞發生 (丟包)

在基於丟包的擁塞控制算法中 (例如 Reno、Cubic、NewReno), 認爲一旦發生丟包，就是網絡鏈路發生了擁塞，所以發送方會急劇地減小發送窗口，甚至進入短暫的等待狀態（超時重傳）。

1% 的丟包率並不只是降低 1% 的傳輸性能，而是可能降低 50% 甚至更多 (取決於具體的 TCP 實現)，此時就可能出現極端情況: 網絡花在重傳被丟掉的數據包的時間比發送新的數據包的時間還要多，所以這是造成 所謂 TCP 性能問題 的最大元兇。

丟包同時會加重網絡鏈路擁塞，假設 1 個 TCP 數據段轉發到第 N 個路由器，前 N-1 個路由器已經完成轉發，但是第 N 個路由器轉發時丟失了數據段，最終導致丟失的數據段浪費了前面所有路由器的帶寬。

TCP Reno 算法發生丟包時，性能直接腰斬

TCP Tahoe 算法發生丟包時，直接重置，進入慢啓動過程

這裏以 HTTP 場景爲例，丟包帶來的影響在 HTTP/2 中表現更爲嚴重，因爲 HTTP/2 只使用 1 個 TCP 連接進行傳輸。所以 1 次丟包會導致所有的資源下載速度變慢。而 HTTP/1.1 可能有多個獨立的 TCP 連接，1 次丟包也只會影響其中 1 個 TCP 連接，所以這種場景下 HTTP/1.1 反而會獲得更好的性能。

順序可靠性保證

雖然 TCP 確保所有數據包有序到達，但是這個順序語義保證可能會引發類似 HTTP 隊列頭部請求阻塞 (head of line blocking) 問題。

TCP 在傳輸時使用序列號 (Seq) 標識數據的順序，一旦某個數據丟失，後續的數據需要保存在接收方的 TCP 緩衝區中，等待丟失的數據重傳完成後，才能進行下一步處理 (傳遞到應用層)。

應用層無法得知 TCP 接收緩衝區的情況，所以必須等待序列 (Seq) 完整之後纔可以獲取應用數據。但是實際上，已經接收到的數據包中，很可能就有應用層可以直接處理的數據，所以，這也可以稱之爲 TCP 隊列頭部請求阻塞 (head of line blocking) 問題。

改進和優化

針對基於丟包的擁塞控制算法，最明顯的改進就是使用更爲合理的擁塞控制算法，例如可以更好地適應高帶寬、高時延、且容忍一定丟包率的 BBR 算法。

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

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

三次握手

除了擁塞控制引起的 "性能問題" 外，TCP 建立連接時的三次握手機制，在某些場景下也會引起性能問題。

對於大多數 TCP 的使用場景 (長連接 + 頻繁數據傳輸)，三次握手幾乎可以忽略不計。真正會造成性能影響的是 長時間 + 大量短連接 場景，針對這個問題， 可以考慮將短連接改造爲長連接，或者使用 TFO 技術 [1] 來進行優化。

此外，還有 2 個會引發性能問題的場景是 HTTP 和網絡切換。

HTTP

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

使用 HTTP/1.1 訪問時的瀑布圖

解決方案也很簡單：直接升級使用 HTTP/2, 在整個通信過程中，只會有 1 個 TCP 連接。

使用 HTTP/2 訪問時的瀑布圖

除此之外，有的讀者可能會想到 “弱網絡” 這個使用場景 (例如人羣密集的地鐵車廂)，但是，既然都是 “弱網絡” 了，那麼使用其他的傳輸協議也很難規避這個問題。

網絡切換

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

類似的場景，還有多個物理場所使用不同的出口公網 IP 地址，例如學校的圖書館和宿舍，公司的會議室和辦公區，當使用者切換物理空間時，也會發送重新建立 TCP 連接。

當然，該問題同樣可以通過使用 TFO 技術 [2] 來進行優化。

確認與重傳

這塊 (可能) 會引發 TCP 性能問題的原因，主要涉及到 3 點:

  1. TCP 超時重傳帶來的性能影響

  2. TCP 快速重傳的侷限性

  3. TCP 選擇性重傳解決了哪些問題

細節部分在 之前的文章中 [3] 已經詳細講過了，本文不再贅述。

小結

現代 TCP 在理想傳輸條件下，性能只受限於光速和接收方緩衝區 (內存) 大小，也就是硬件和物理。

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

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

  1. 鏈路中最小的帶寬

  2. 鏈路中最慢的硬件處理

  3. 鏈路中最小的接收緩衝區大小

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

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

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

網絡編程中，開發者遇到的實際問題，大約有 90% 都和開發者對於 TCP/IP 的理解有關。不要對 TCP 和 UDP 的相對性能做任何先驗假設，即使是很小的擦不參數改變，都可能對性能產生嚴重影響。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/2vtO3uVQAwR2aMEsPpCTvw

猜你喜歡