BBR：网络拥塞为什么不能只看丢包？

很多人把网络拥塞和丢包画上等号：丢包变多，就降低发送速度。BBR（Bottleneck Bandwidth and Round-trip propagation time）提出的观察角度不同，它试图直接估计链路的瓶颈带宽和往返传播时间，再据此决定发送速率和在途数据量。

把网络想成一条水管。丢包像水从接缝漏出来，但漏水也可能来自拥塞、无线干扰或队列溢出。只盯着漏水来调节，可能在链路已经拥塞之前反应太晚，也可能在没有真正拥塞时过度降速。BBR 更像是在测量水管最窄处能通过多少水，以及水从一端到另一端要多久。

瓶颈带宽描述稳定传输时的上限，RTprop 则近似表示没有排队时的传播延迟。两者结合，可以让发送器既保持较高吞吐，也尽量不把队列填得过深。BBR 会在不同阶段探测带宽和延迟，观察确认反馈，再调整 pacing rate 和拥塞窗口，而不是把单个丢包当作唯一信号。

这并不表示 BBR 永远优于基于丢包的算法。不同版本和实现对公平性、队列、短流和竞争流的表现可能不同，网络设备和对端行为也会影响结果。发送器仍需处理确认延迟、应用受限、无线波动和测量误差；一个不准确的带宽估计同样会造成拥塞。

BBR 的启发在于：控制系统不该只盯着“坏结果”，还应该测量系统内部的容量和延迟。对网络来说，吞吐、RTT、在途数据和丢包都只是观测信号；用更多信号建立模型，才能在高带宽、长距离和复杂无线环境中作出更平滑的调节。

从控制理论看，BBR 代表了从“对丢包作反应”转向“主动测量系统状态”。发送器观察确认反馈形成估计，估计再影响下一轮发送；测量窗口太短会受噪声影响，太长又会跟不上链路变化。因此实际算法需要探测、稳定和回退，不能只用一个静态带宽数字。

资料来源：Google Research：BBR: Congestion-Based Congestion Control