Google 的 BBR 拥塞控制算法与传统算法有什么区别？

传统算法（Reno、CUBIC）基于「丢包 = 拥塞」的假设：丢包就减半/回退窗口。但在有缓冲膨胀（bufferbloat）的现代网络里，丢包往往发生在缓冲区早已塞满、延迟飙升之后；反过来，无线等链路本身的随机丢包又会被误判为拥塞而过度退缩。BBR 换了个模型：持续测量链路的瓶颈带宽（BtlBw）和最小往返时延（RTprop），让发送速率 = 瓶颈带宽、在途数据量 = 带宽时延积（BDP），主动把工作点维持在「队列恰好不堆积」的最优点，而不是等丢包报警。

机制要点：1）Pacing——按测得带宽匀速发包（而非窗口突发式），Linux 需要 fq 调度器配合；2）周期性增益循环——以 1.25×/0.75× 速率交替探测带宽是否提升并消化队列；3）对随机丢包不敏感（丢包率 1~5% 的劣质链路吞吐可提升数倍）。争议与现状：BBR v1 与 CUBIC 共存时有带宽抢占的不公平问题、对小缓冲路由器不友好，BBRv2/v3 引入丢包与 ECN 信号做约束以改善公平性。追问方向：BDP 为什么是「在途数据量的正确目标」、Pacing 与 cwnd 两种发送控制的对比、QUIC 用户态实现让 BBR 部署更容易的原因。

（约 450 字）