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。如果窗口小于这个值，链路就会空闲等待确认，带宽浪费。这个概念对调优跨国专线、卫星链路、广域网加速非常关键。