最後更新：2026-06-24

TCP 吞吐量

TCP 吞吐量是單一 TCP 連線在網路路徑上可維持的持續資料速率。它與鏈路速率並不相同：若路徑有高延遲與偶發的封包遺失，一條 1 Gbps 的鏈路對單一連線可能也只能交付每秒幾個百萬位元。本計算機使用 Mathis 公式來估算這個單一連線上限，而這正是備份、複寫、大型上傳，以及任何跑在單一 TCP 串流上的傳輸所關心的數字。

Mathis 公式

一條受隨機封包遺失限制的長連線 TCP，最終會穩定在約莫如下的吞吐量：

其中 $MSS$ 是以位元組為單位的最大區段大小，乘以八是把這些位元組換算成位元。來回延遲 $RTT$ 以秒為單位，而 $p$ 是以小數表示的封包遺失機率。結果 $T$ 以每秒位元數呈現。

這個形式源自 TCP 壅塞控制的行為。每次遺失後，TCP 將壅塞視窗減半，再以每次來回增加一個區段的速度重建——也就是熟悉的「加法增加、乘法減少」鋸齒。對許多週期取平均後，視窗會與 $1/\sqrt{p}$ 成正比，而把視窗除以 RTT 便得到上述吞吐量。Matthew Mathis 與同事於 1997 年發表此結果，至今仍是受遺失限制 TCP 的標準粗估模型。

計算範例

取區段大小 1250 位元組、來回延遲 100 ms、封包遺失率 0.01%（小數為 0.0001）：

也就是單一連線 10 Mbps——無論底層鏈路標示為 100 Mbps 還是 10 Gbps 都一樣。決定上限的是路徑的延遲與遺失，而非原始容量。

為何延遲與遺失主導一切

分母中的兩項解釋了為何快速鏈路也可能感覺很慢：

• 來回延遲。 吞吐量與 RTT 成反比。把兩端的距離加倍，單一連線速率大約減半，因為每次視窗調整都要等一整個來回才生效。
• 封包遺失。 吞吐量隨遺失率的平方根遞減。從 0.01% 增加到 1% 遺失——上升一百倍——會讓吞吐量降為十分之一。在長路徑上，復原相當緩慢，因此即使罕見的遺失也會嚴重累積。

這種高延遲與非零遺失的組合有時被稱為「長肥網路」（long fat network），而這正是單一連線 TCP 表現不佳的場景。

模型不適用的時機

Mathis 公式假設連線受遺失限制。若路徑乾淨、TCP 接收視窗大到足以保持管線飽滿，連線就改為受鏈路速率或視窗本身限制。在此情形下，頻寬延遲乘積——頻寬乘以 RTT——告訴你視窗必須多大才能讓鏈路飽和，而 Mathis 公式不再適用。

BBR 等現代壅塞控制演算法也改變了局面：它們根據量測到的頻寬與 RTT 來調節傳送節奏，而非對每次遺失做出反應，因此對易遺失路徑的容忍度遠勝於經典的遺失導向模型所預測。請把 Mathis 估算值視為傳統遺失導向 TCP 的保守上限，並記得執行多條並行連線可將單一連線結果倍增。

提升吞吐量

由於平方根關係，降低遺失帶來最大的回報——優先追查不穩定的纜線、壅塞的節點與故障硬體。把伺服器移到離使用者更近的位置，或將內容放上 CDN 以縮短 RTT，則能依比例改善。在路徑上每一跳都支援的情況下啟用巨型訊框可提高 MSS。而當單一連線就是無法填滿管線時，並行串流或一個容忍遺失的壅塞控制演算法便能補上落差。

相關計算機

要算出在乾淨、高延遲鏈路上填滿管線所需的 TCP 視窗，請使用 頻寬延遲乘積計算機 計算機。要在已知有效速率後估算檔案傳輸所需時間，請使用 資料傳輸時間計算機 計算機。要在每秒位元數與每秒位元組數單位之間換算吞吐量數字，請使用 吞吐量（bps）換算器 計算機。