运维123 - 网络算法
type: channel
link: https://www.sddts.cn/index.php/tag/%E7%BD%91%E7%BB%9C%E7%AE%97%E6%B3%95/
items: BBR 与 CUBIC 拥塞控制算法深度分析

BBR 与 CUBIC 拥塞控制算法深度分析
type: item
date: 2026-01-18T00:30:42+00:00
description: BBR 与 CUBIC 拥塞控制算法深度分析一、概述1. 背景介绍自 2017 年底 BBR（Bottleneck Bandwidth and Round-trip propagation time）发布以来，随着媒体的宣讲，各大站点陆续部署 BBR。很多网友不禁问，BBR 这么好，为什么不替代 CUBIC 成为 Linux 的缺省算法。仅仅因为它尚未标准化，这么好的算法又为什么没被标准化？2. 核心问题本文将从技术原理、系统稳定性、公平性、适用场景等多个维度，深入分析 BBR 为什么没有替代 CUBIC 成为 Linux 内核缺省算法。二、算法对比分析1. 性能度量的误区A. 错误的测试方法包括作者在内的几乎所有人都用过一种错误方法度量 BBR 的"好"：搭建一跳转发的模拟环境，用 tc 配置丢包、时延，用 iperf 对比 BBR 和 CUBIC，得到结论：BBR 的吞吐比 CUBIC 大好多倍，所以 BBR 好。B. 测试的局限性这种测试方法存在严重问题：测试环境过于理想化未考虑真实网络环境的复杂性忽略了统计复用网络的基本特性C. 正确的评价标准根据 Dropbox 的实际部署经验，一个拥塞控制算法在部署之前，至少要自证两件事：不会引发拥塞崩溃网络流量公平收敛2. 算法设计哲学差异A. CUBIC 的设计理念graph LR A[CUBIC 算法] --> B[基于丢包反馈] B --> C[线性系统] C --> D[可叠加性] D --> E[稳定收敛] style A fill:#e1f5ff style E fill:#c8e6c9CUBIC 的核心特点：最小依赖：仅依赖丢包事件丢包不会撒谎：任何行为都无法做到 buffer 溢出而不丢包宁可错杀，但绝不遗漏：对拥塞的反应属反向激励线性系统：具备可叠加性，系统问题可控B. BBR 的设计理念graph LR A[BBR 算法] --> B[主动测量带宽] B --> C[测量 RTT] C --> D[模型估算] D --> E[调整发送速率] A --> F[非线性系统] F --> G[复杂行为] G --> H[不可预测性] style A fill:#fff3e0 style H fill:#ffcdd2BBR 的核心特点：主动探测带宽和 RTT依赖高精度的准确测量非线性系统，行为复杂对测量误差敏感三、深入分析1. 测量精度的陷阱A. 统计律的本质统计复用网络本身不可精确测量。这不仅仅是网络异构性的问题，更深层的原因来自于统计律本身。正如你无法把握某个空气分子的动量，但却能测量一坨空气的温度一样。B. 测量的滞后性统计方法都有滞后性，对反馈响应之前的这段时间可能就是灾难酝酿的时间。而随后的响应并不覆盖灾难，系统可能滑向不稳定状态，包括拥塞崩溃。C. BBR 的依赖性BBR 的正确性依赖高精度的准确的对 bandwidth 和 rtt 的测量，而：高精度取决于实现准确性则依赖网络本身2. 系统稳定性分析A. 线性 vs 非线性graph TB subgraph 线性系统_CUBIC A1[流 1] --> C[共享瓶颈] A2[流 2] --> C A3[流 N] --> C C --> D[稳定收敛] D --> E[公平分配] end subgraph 非线性系统_BBR B1[流 1] --> F[复杂交互] B2[流 2] --> F B3[流 N] --> F F --> G{不确定状态} G --> H[可能发散] G --> I[可能收敛] end style D fill:#c8e6c9 style G fill:#ffcdd2CUBIC 源自 Reno，是线性的，线性可叠加性让系统问题变得和单体问题一样可控。不管是同步流还是异步流，系统行为可预测。BBR 本身是个非线性系统，不能用线性的思维去简单表达。换句话说，这件事本身就凌乱复杂，没有简单到能让人快速画线获得直感的方法。B. 双流相图分析文章中的 BBR 双流相图显示，系统状态空间的边界难以确定。某个状态的可达性取决于你对系统的测量结果，而误估导致的行为不可控。3. 公平性问题A. CUBIC 的公平性与自身共存：公平收敛与异构流量共存：表现可预期收敛速度：可预期B. BBR 的公平性挑战BBR 一个也证明不了：无法自证不会引发拥塞崩溃无法自证网络流量公平收敛在某些场景下可能过度抢占带宽在某些场景下可能被 CUBIC 压制四、缺省算法的选择标准1. 设计原则大道至简，最小依赖，少即是多，这是 CUBIC 作为缺省算法的理由。A. 普适性缺省算法不一定甚至一定不是性能最高的，但一定是普适不挑环境的。B. 公平性缺省算法的公平性一定是可自证的，无论与自身还是与异构流量共存。C. 可预期性缺省…