BBR 与基于丢包的算法有何不同
传统算法（CUBIC 等）把丢包当成拥塞信号，一旦丢包就大幅降速；在跨境链路或无线链路上，丢包未必来自拥塞，于是吞吐被白白压掉。BBR 改为持续估计瓶颈带宽与最小 RTT，按「带宽 × 时延」控制发送节奏，因此在高丢包链路上通常能明显提升吞吐，代价是队列延迟的行为不同。
基本信息
| 适用平台 | Linux（内核 4.9 起内置 bbr v1，新内核有实验性 bbr2） |
|---|---|
| 发送队列 | 需搭配 fq 或 fq_codel 之类的排队规则做 pacing |
| 依赖条件 | 准确的时间戳；虚拟化环境下时钟源异常会影响估计 |
| 配置项 | net.ipv4.tcp_congestion_control 与 net.core.default_qdisc |
| 查看 | sysctl net.ipv4.tcp_congestion_control；ss -ti 可看单连接的拥塞算法 |
BBR 状态机
| 阶段 | 作用 | 观察点 |
|---|---|---|
| STARTUP | 快速探测带宽上限 | 类似慢启动，呈指数增长 |
| DRAIN | 排空上行造成的队列 | 吞吐短暂回落属正常 |
| PROBE_BW | 周期性微增试探带宽 | 长期稳定阶段，占绝大部分时间 |
| PROBE_RTT | 定期压低在途数据量测最小 RTT | 会造成轻微吞吐抖动 |
启用与验证
启用与验证
modprobe tcp_bbr
cat >/etc/sysctl.d/99-bbr.conf <<'EOF'
net.core.default_qdisc=fq
net.ipv4.tcp_congestion_control=bbr
EOF
sysctl --system
sysctl net.ipv4.tcp_congestion_control net.core.default_qdisc # 核对是否生效
ss -ti | head -3 # 输出的 cubic/bbr 字段显示单连接实际使用的算法BBR 与丢包型限速设备（令牌桶）交互可能产生较高队列延迟：BBR 会持续试探带宽，遇到整形链路时容易把队列填满，跨境与专线场景需要实测对比。
BBR 无法突破链路本身的瓶颈，也不能替代带宽扩容：它减少的是「因随机丢包而误降速」的损失，物理带宽与路由质量问题依然要靠链路侧解决。
切换前后要用相同条件对比：同一目标、同一时段、同样的并发与文件大小，并同时看吞吐与 P99 延迟；只对比平均值会把排队延迟带来的副作用掩盖掉。
验证是否真的生效要看单连接而非全局配置：ss -ti 输出里的拥塞算法字段反映每条连接实际使用的算法，只有那里显示 bbr 才算落地。