TCP 吞吐与带宽时延积

两个相隔 100 ms 的办公点之间有一条 1 Gbps 链路，本该在不到一秒内传完一个文件。实际上单条 TCP 连接往往只能跑到十分之一。问题不在链路 —— 是协议在等。TCP 要求数据被确认之后才能在途位置上被替换，而在长路径上，每一个确认都要走完一个完整的往返才能回来。如果发送方在第一个确认回来之前就用光了允许未确认的数据量，链路在每个往返里都会有一部分时间处于空闲。

决定这件事是否发生的量就是带宽时延积：要让管道被填满，需要有多少数据同时在途。它就是带宽乘以往返时延。

BDP（比特） = 带宽（比特/秒） × RTT（秒）
BDP（字节） = BDP（比特） ÷ 8

1 Gbps、RTT 100 ms：
  BDP = 1,000,000,000 × 0.1      = 100,000,000 比特
      = 100,000,000 ÷ 8          = 12,500,000 字节
      = 12.5 MB

也就是说，这条链路需要始终有 12.5 MB 的数据在途才能保持繁忙。这个数字就是后面每一项调优决策所追求的目标。

TCP 发送方在途的未确认数据量，不能超过接收方通告的窗口允许的值。由此得出一个与链路速率毫无关系的吞吐上限：

吞吐（字节/秒） = 窗口（字节） ÷ RTT（秒）

窗口 65,535 字节、RTT 100 ms：
  吞吐 = 65,535 ÷ 0.1 = 655,350 字节/秒
       = 655,350 × 8  = 5,242,800 比特/秒 ≈ 5.24 Mbps

这是 TCP 性能中最重要的一个数字。在 100 ms 路径上使用出厂默认的 65,535 字节窗口，会把单条流限制在约 5.24 Mbps —— 无论链路本身有多快。同样的窗口在 10 ms 的往返时延下能到 52.4 Mbps，这就是为什么这个问题在局域网上完全看不出来，而跨洋时却非常严重。

RFC 7323（最早是 RFC 1323）引入了窗口扩大选项。握手期间双方各自通告一个移位计数，此后发送的每一个窗口值都按值 × 2^scale 解释。扩大因子为 7 时，天花板乘以 128：

由于移位计数是协商出来的，两端都必须支持 —— 一台现代 Linux 或 macOS 主机与老旧设备通信时，仍可能拿到未扩大的窗口。另外要注意，这个扩大因子只作用于窗口字段，不作用于握手期间窗口更新里的那个值，这正是读抓包时经常差 128 倍的经典来源。

即便窗口很大，丢包也会施加自己的限制。拥塞控制把丢包视为拥塞的证据并降低发送速率，而恢复是渐进的。Mathis 公式给出了单条 Reno 式 AIMD 流的数量级上限：

吞吐 ≈ (MSS ÷ RTT) × (C ÷ √p)

  MSS = 最大报文段长度（字节）
  RTT = 往返时延（秒）
  p   = 丢包概率
  C   ≈ 1.22，对应简单的 AIMD（Reno）发送方

MSS 1460 B、RTT 100 ms、p = 1%：
  1460 ÷ 0.1        = 14,600
  1.22 ÷ √0.01      = 1.22 ÷ 0.1 = 12.2
  吞吐              = 14,600 × 12.2 = 178,120 字节/秒
                    ≈ 1.42 Mbps

丢包项位于平方根之下，这让它的惩罚格外严厉。从 0.01% 的丢包升到 1% —— 增加一百倍 —— 只让吞吐下降十倍，而不是一百倍。这也意味着，一条存在少量持续性丢包的路径，有一个无论怎么调窗口都抬不起来的硬上限。

当传输比预期慢时，真正有用的问题是：这三个限制里，哪一个正在起约束作用。每一个的应对方式都不同，用错了只是浪费时间。

最快的粗判方法：把观测到的吞吐乘以 RTT。如果结果可疑地接近 64 KB，或者接近某个整数的兆字节数，那限制就在窗口。如果接近 BDP 却远低于链路速率，就去查丢包。

上面的数字都是单条理想化流的上限。实际传输还会受 TCP 慢启动限制 —— 连接以一个很小的拥塞窗口开始，每个往返翻一倍，直到达到路径容量，所以短传输根本摸不到天花板。延迟确认、接收窗口自动调优、竞争流量、负载下排队时延推高实际 RTT，以及 CUBIC 对丢包的不同反应，都会让真实行为偏离模型。

请用这些数字判断"哪个限制在起作用"以及"调优还能换来多少余量"，而不是用它预测某次具体传输要多久。带宽计算器处理的是更基础的问题：给定速率下传一个文件要多久；而 MTU / MSS 计算器处理的是会降低这些公式所依赖的 MSS 的封装开销。