TCP 吞吐量
使用 Mathis 公式計算理論 TCP 吞吐量
如何使用TCP 吞吐量
- 1輸入 RTT（往返時間）和丟包率。
- 2輸入 MSS（最大段大小，通常 1460 位元組）。
- 3讀取該路徑可維持的最大 TCP 吞吐率。
TCP 吞吐率（Mathis 公式）
吞吐率 ≤ (MSS / RTT) × C / √(丟包率)，C ≈ 0.93Mathis 公式刻畫了受丟包和往返時間制約的 TCP 連線吞吐上限。
即便極小丟包（如 0.1%）也會在長 RTT 鏈路上大幅壓低吞吐，這正是高丟包衛星/WAN 鏈路感覺慢的原因。
TCP 吞吐量有個硬上限：**吞吐 ≤ 視窗大小 ÷ RTT**。這是滑動視窗協議的根本約束——視窗內的資料發出去後必須等確認（ACK）回來才能繼續發，一個 RTT 內最多隻能發「一個視窗」的資料。所以即使頻寬是 1 Gbps，如果視窗只有 64 KB 而 RTT 是 200 ms，吞吐量就被限制在 64 KB ÷ 0.2 s = 2.6 Mbps。**這叫「長肥管道」問題（Long Fat Network）。**
解決辦法是**開啟 TCP 視窗縮放（Window Scaling，RFC 7323）**：在三次握手時協商一個縮放因子，把視窗從最大 64 KB 擴充套件到最大 1 GB。現代作業系統（Windows Vista+、Linux 2.6.8+、macOS）預設都開啟了。所以現在跑不滿頻寬通常是別的原因：接收方應用讀取慢導致視窗通告變小、中間裝置緩衝不足、或者丟包率過高（**哪怕 0.1% 的丟包也能讓 TCP 吞吐驟降**）。
| RTT | 預設視窗 64 KB | 視窗 256 KB | 視窗 1 MB | 需要視窗（跑滿 1 Gbps） |
|---|---|---|---|---|
| 1 ms（同機房） | 512 Mbps | 2 Gbps | 8 Gbps | 125 KB |
| 10 ms（同城） | 52 Mbps | 210 Mbps | 838 Mbps | 1.25 MB |
| 50 ms（跨省） | 10.5 Mbps | 42 Mbps | 168 Mbps | 6.25 MB |
| 200 ms（中美） | 2.6 Mbps | 10.5 Mbps | 42 Mbps | 25 MB |
| 300 ms（衛星） | 1.7 Mbps | 7 Mbps | 28 Mbps | 37.5 MB |
TCP 視窗大小決定的最大吞吐量（不同 RTT）
常見問題
為什麼 1% 丟包影響這麼大？
吞吐率隨 1/√丟包率 變化，1% 丟包可把容量壓到無丟包時的約 10%。
增大視窗有用嗎？
只到 BDP 為止；無論視窗多大，丟包仍會封頂 Mathis 上限。
如何改善？
降低 RTT 或丟包（更優路徑、FEC、BBR 等 TCP 變體），而非只加頻寬。
為什麼丟包對 TCP 影響這麼大？
因為 TCP 把丟包當作**擁塞訊號**，一旦檢測到就大幅降速（Reno 演算法直接把視窗減半），然後線性增長試探。數學上吞吐量大致與 1/√丟包率 成反比：丟包率 0.01% 時還能跑到接近滿速，0.1% 時只剩約 30%，1% 時只剩約 10%。所以長距離鏈路對丟包極其敏感，這也是為什麼 BBR、QUIC 等新擁塞演算法改用「頻寬時延探測」而非「丟包」來判斷擁塞。
BDP 是什麼？怎麼算？
BDP（Bandwidth-Delay Product，頻寬時延乘積）= 頻寬 × RTT，表示「管道里正在飛行的資料量」。要讓鏈路跑滿，TCP 視窗至少要等於 BDP。例如 1 Gbps、RTT 50 ms：BDP = 10⁹ × 0.05 ÷ 8 = 6.25 MB。如果視窗小於這個值，鏈路就會空閒等待確認，頻寬浪費。這個概念對調優跨國專線、衛星鏈路、廣域網加速非常關鍵。