通用面试：如何解释 BBR 与 CUBIC 的拥塞控制取舍？
题干与适用场景
服务在高带宽、长 RTT 或共享链路上出现吞吐不足和队列延迟。团队想把 Linux TCP 拥塞控制从 CUBIC 改为 BBR，却担心与现有流竞争、突发流量和不同内核版本的行为差异。请解释机制并提出上线方案。
面试官考察点
- 能否区分拥塞控制、可靠传输和应用重试的职责。
- 能否解释基于丢包的窗口增长与基于带宽、RTT 估计的发送速率控制。
- 能否识别队列膨胀、共享链路公平性、应用受限和内核实现差异。
- 能否用真实工作负载、尾延迟和回滚闸门验证，而不是只看单次吞吐。
回答前要澄清的问题
- 流量是长连接大流、短 RPC，还是应用本身经常处于 app-limited？
- 链路瓶颈在哪里，是否有多个租户或不同拥塞算法共享队列？
- 内核、网卡卸载、队列规则和可用的 BBR 版本是什么？
- 目标是吞吐、p99 延迟、成本，还是在丢包网络中保持稳定？
- 是否能按主机、服务或连接比例灰度，并快速恢复原算法？
30 秒回答框架
CUBIC 主要根据拥塞窗口和丢包反馈调速，成熟且在共享网络中行为可预期；BBR 估计瓶颈带宽和最小 RTT，尝试在接近带宽上限的同时控制队列。BBR 可能降低排队延迟，但公平性、版本和工作负载依赖更强。我会先建立 CUBIC 基线，再按主机灰度 BBR，比较 goodput、p99 RTT、重传、队列长度、CPU、不同流的带宽份额和错误率，并准备立即回滚。
分步骤深入解答
第一步：区分 TCP 的控制面
TCP 负责有序可靠交付，拥塞控制负责根据网络反馈限制发送速率，流量控制负责接收端能力。应用层超时和重试不能替代拥塞控制；重试反而可能把拥塞放大。
第二步：说明 CUBIC 的信号与取舍
CUBIC 通过拥塞窗口和丢包等信号判断网络拥塞，窗口增长函数让高带宽长 RTT 链路更快恢复。它的优点是成熟、部署广、与既有网络设备和调度策略经验较多；缺点是通常等到丢包后才明显收缩，可能形成较深队列。
第三步：说明 BBR 的模型
BBR 用已观测的交付速率估计瓶颈带宽，用最小 RTT 估计传播时延，并以两者计算带宽时延积来控制发送。它会在探测带宽和排空队列之间切换，目标是以较少丢包维持高 goodput。模型会受测量噪声、应用受限和路径变化影响。
第四步：讨论公平性与队列风险
不同拥塞算法共享同一瓶颈时，带宽份额不一定公平；BBR 版本、参数、队列管理和流数量都会影响结果。若发送速率估计偏高，可能增加队列延迟。必须观察每条流的份额和 RTT 分布，不能用总吞吐掩盖某类流被挤压。
第五步：设计实验矩阵
覆盖短 RPC、长下载、app-limited、不同 RTT、不同丢包率、单流与多流、同算法与混合算法。使用固定内容和相同主机基线，记录 goodput、p50/p99 RTT、重传、丢包、队列深度、CPU 和完成时间。
第六步：按主机灰度和回滚
先在隔离环境启用，再按单个服务、可用区或小比例主机灰度。内核与队列配置纳入版本，发布期间监控异常并自动暂停。若 p99 RTT、错误率、带宽公平性或下游完成时间超阈值，恢复原算法并保留对比数据。
第七步：解释结果边界
BBR 的收益不能外推到所有路径、内核和应用。CUBIC 的“成熟”也不代表在每条长 RTT 链路上最优。最终选择应绑定工作负载、网络运营者、队列管理和业务目标，并定期重测。
高质量示范回答
我会先说明职责：TCP 保证交付，拥塞控制调节发送，应用重试不能代替它。CUBIC 主要用拥塞窗口和丢包反馈，部署经验成熟，但可能在丢包前积累较深队列。BBR 根据交付速率估计瓶颈带宽、用最小 RTT 估计传播时延，再以带宽时延积控制发送，可能降低排队延迟，却更依赖版本、队列和混合流公平性。上线前我会固定主机和内容建立 CUBIC 基线，覆盖长流、短 RPC、app-limited、不同 RTT、单流和混合算法；灰度期间比较 goodput、p99 RTT、重传、队列、CPU、完成时间和每流带宽份额。任何尾延迟、错误率或公平性回归触发自动回滚到 CUBIC。
常见错误
- 把 BBR 说成“完全不丢包”或把 CUBIC 说成只看带宽。
- 用一次 iperf 吞吐结果替代多工作负载实验。
- 忽略 app-limited 流、混合算法和队列管理器。
- 只监控总带宽，不监控每流公平性和 p99 RTT。
- 修改 sysctl 后没有确认内核、网卡和队列配置是否实际生效。
- 没有小比例灰度和可验证的回滚路径。
追问及应对
追问一：BBR 是否一定比 CUBIC 快？
不一定。收益依赖 RTT、带宽、丢包、队列、流数与应用是否受限。应先定义目标并用同条件实验比较，而不是根据算法名称下结论。
追问二：为什么要看最小 RTT？
它近似传播时延，帮助区分路径本身的延迟与排队延迟。若基线被排队污染，带宽时延积和队列判断都会偏差。
追问三：混合 BBR 与 CUBIC 会怎样？
带宽竞争可能不公平，结果取决于版本、队列管理、流数和路径。必须在共享瓶颈上测每流份额、RTT 与丢包，不能只看 BBR 自身吞吐。
追问四：短 RPC 也应该切换吗？
先确认它们是否长期 app-limited，以及连接复用和握手占比。短请求的收益可能小于配置风险，应按服务灰度而非全局切换。
追问五：如何判断是拥塞控制导致 p99 变差？
对照同一主机、路径和应用版本，关联 RTT、队列深度、重传、拥塞窗口和完成时间；同时排除 CPU、TLS、服务端排队和应用重试变化。
追问六：回滚后还要做什么？
确认新连接使用原算法、旧连接是否需要重建，清理灰度配置，保留实验数据并记录触发阈值。若问题来自队列或内核而非算法，修复根因后再安排独立实验。