直接回答：CUBIC 是丢包驱动：把丢包当拥塞信号，窗口 additive 增、丢包 multiplicative 减（AIMD）。BBR 是测量驱动：持续测量瓶颈带宽（BtlBw）与往返时延（RTprop），按“带宽×时延”的 BDP 直接设定发送速率与窗口，把队列长度主动压在近零——不等丢包发生就调节。丢包≠拥塞（弱网随机丢包多）是 CUBIC 的根本误判，也是 BBR 的主场。
展开解析：机制拆解：CUBIC 在 buffer 深的链路（bufferbloat）会把队列塞满才丢包减速，延迟居高不下；在随机丢包链路（无线、跨境）则过度反应——1% 随机丢包就让窗口起不来，吞吐崩。BBR 四状态机：Startup（指数爬坡测带宽）、Drain（排掉爬坡期积压队列）、ProbeBW（周期小幅过冲探测带宽是否上涨，八个相位循环）、ProbeRTT（每 10 秒抽 200ms 几乎排空测真实 RTT——这也是多 BBR 流同步排空的争议点）。速率控制：pacing（均匀间隔发包）而非突发窗口，这本身就减少微突发丢包。现实争议与版本：BBRv1 对 CUBIC 流侵略性强（抢带宽）、在 deep buffer 下自成新队头阻塞、ProbeRTT 同步问题；BBRv2/v3 引入丢包与 ECN 响应做兼容层，侵略性收敛。部署考量：Linux 内核 4.9+ 自带，服务端开启即可（客户端无关，拥塞控制是发送方单边行为）——这也是它流行的原因；跨境加速、CDN 回源是典型场景；对延迟敏感的小流量收益有限。面试收束：一句话对比——CUBIC 问“丢包了吗”，BBR 问“这条路到底多宽多快”。
追问方向：pacing 为什么需要 fq 队列配合？BBR 的带宽测量被 ACK 压缩干扰怎么办？
（约 490 字）