TCP BBR 拥塞控制算法深度实战：从带宽感知模型到 BBRv2 多流公平竞争的工程演进

TCP 拥塞控制是互联网数据传输的核心引擎，决定了数据包如何在复杂多变的网络路径上平稳流动。长期以来，以 CUBIC 为代表的 loss-based 算法主导了 Linux 内核网络栈——它们将丢包视为拥塞信号，一旦检测到丢包就大幅缩减发送窗口

然而在实际广域网、无线网络和存储网络中，丢包不一定意味着拥塞——可能是信号干扰、缓存过小或 burst 导致。Google 团队在 2016 年提出的 BBR（Bottleneck Bandwidth and Round-trip propagation time）算法革命性地颠覆了这一假设：不再以丢包为拥塞信号，而是通过主动测量路径的瓶颈带宽和最小RTT来建立显式的传输模型。

BBR 已被纳入 Linux 4.9+ 内核，成为 Google Cloud、YouTube、Google.com 等大规模系统的默认拥塞控制算法。本文将从数学模型、状态机演进、内核实现到生产调优，全方位拆解 BBR 的设计哲学与工程实践。

一、为什么我们还需要新的拥塞控制算法

1.1 Loss-based 算法的根本缺陷

以 CUBIC（Linux 默认）为代表的传统算法遵循 丢包 = 拥塞 的假设。其工作逻辑是：

// CUBIC 窗口变化简化模型
on_ack():
    if window < W_max:          # 慢启动/凸增长区
        window += 1             # 线性增长
    else:                        # 凹增长区
        window += C * (t - K)^3  # 三次函数逼近 W_max

on_loss():
    W_max = window
    window *= 0.7              # 乘性减（MD）

这在缓冲区较大的传统有线网络中表现尚可——填满缓冲区恰好意味着利用了全部带宽，且最后一次溢出的丢包被作为减速信号。但这种方法的根本局限在于：它是"事后响应"而非"事前预测"。

1.2 Bufferbloat 问题

当网络路径上的缓冲区（buffer）比 Bandwidth-Delay Product 大得多时，传统拥塞算法会把缓冲区完全填满，导致 RTT 从真实的 propagation delay 膨胀到 propagation + queuing delay。这就是 Van Jacobson 在 2012 年提出的 Bufferbloat 问题。

CUBIC 的行为：持续填充直到溢出（丢包），RTT 可能被拉到 5-10 倍的真实传播时延。典型表现：你的 ping 时延从 20ms 飙到 200ms，但网络"看起来很正常"，因为吞吐量仍然很高。

1.3 无线网络与浅缓冲区的困境

在 Wi-Fi / LTE 等无线网络中，丢包可能由信号干扰、多径衰落导致，而非链路拥塞。CUBIC 对这类非拥塞丢包也会触发窗口缩减，导致带宽利用率严重不足。同样，在交换机芯片中，为了降低成本，缓冲区通常很小（几十 KB），CUBIC 在这些场景下表现极差。

1.4 BBR 的设计目标

Google 团队总结了理想拥塞控制算法需要满足的条件：

• 高吞吐：长期运行下达到瓶颈带宽（BtlBw）
• 低时延：保持排队延迟最小化（buffer occupancy ≈ 0）
• 快速收敛：新流启动后尽快探测到可用带宽
• 公平性：多个 BBR 流/与其他算法流共享链路时带宽分配合理
• 抗丢包容忍：非拥塞丢包不对吞吐造成显著影响
• 收敛稳定：不会持续震荡

二、BBR 核心模型：RTprop 与 BtlBw

2.1 两个基本测量量

BBR 将网络路径抽象为管道模型：有一条瓶颈链路决定了最大传输速率（BtlBw），信号在管道中传播有固有延迟（RTprop）。所有行为都围绕这两个量的实时估计展开。

BtlBw (Bottleneck Bandwidth)：路径上瓶颈链路的物理带宽，单位 bytes/sec。BBR 通过测量最大投递率（delivery rate）来估计——delivery_rate = acked_bytes / ack_interval。这是所有到达接收方且被确认的数据除以时间间隔得到的速率采样。

RTprop (Round-Trip Propagation Time)：数据包从发送到收到 ACK 的最小往返时间。BBR 维护一个滑动窗口（默认 10 秒）内的最小 RTT 测量值作为 RTprop 的估计。取其最小值而非平均值，是因为最小值最接近真正的传播时延，任何 RTT 增大的部分都是排队延迟。

2.2 BDP——理想运行点

Bandwidth-Delay Product = BtlBw × RTprop，表示在网络管道中"在途数据量"的理论最优值。如果发送方恰好维持 BDP 字节在途，则：

• 瓶颈链路 100% 被利用（因为发送速率恰好等于瓶颈带宽）
• 无排队（因为不需要超出管道容量的数据在缓存中等待）

这就是 BBR 的黄金目标点：inflight = BDP = BtlBw × RTprop

2.3 pacing——精确速率控制

BBR 的另一个关键改进是引入了 pacing（节奏控制）机制。传统 TCP 以 burst 方式发送数据（比如收到一个 ACK 就发送一整段数据窗口的数据），这导致突发流量填满网络缓冲区。

BBR 配置 pacing_rate = pacing_gain × BtlBw，由内核的高精度定时器（hrtimer）均匀地将数据包注入网络。例如 BtlBw=10Gbps，pacing_gain=1.0 时，内核每微秒发送约 1250 字节的数据，而不是突发 64KB 的数据包。

// 内核源码 net/ipv4/tcp_bbr.c: pacing 计算
static void_bbr_set_pacing_rate(struct sock *sk, u32 bw, int gain)
{
    unsigned long rate = bw;

    rate = min(sk > sk_pacing_rate);
    rate = min(READ_ONCE(sk > sk_max_pacing_rate);

    bbr > pacing_rate = bbr_pacing_rate(sk, bw, gain);
tcp_sk(sk) > sk_pacing_rate = pace;
}

三、BBR 四状态状态机

BBR 设计了四个状态来实现对 BtlBw 和 RTprop 的持续探测与稳定维持。每个状态有不同的 gain（增益）参数控制发送速率。

3.1 Startup（启动/慢启动）

新连接进入 Startup 状态。pacing_gain = 2.27（即 2/ln2 ≈ 2.89 的近似值），每个 RTT 将发送速率提高约 27% 以实现指数级带宽探测。

// Startup 中的带宽探测
// gain = 2/ln2 ≈ 2.89 (BBRv1 实际使用 2.27)
pacing_rate_ = pacing_gain × BtlBw  // 每个RTT提高 27%
cwnd_gain = 2                    // 维持 cwnd 为 2 倍的 BDP 以允许突发

Startup 的退出条件：连续 3 个 RTT 内 BtlBw 测量值没有增长超过 25%，说明已经接近瓶颈带宽，转入 Drain 状态。这个过程类似于传统慢启动的阈值退出，但是基于带宽而非丢包。

数学上，Startup 阶段完成了对 pipe 的"填充"过程。如果 BtlBw 每个 RTT 都增长 27%，经过 n 个 RTT 后，速率 = (1.27)^n × 初始速率，呈指数增长。3 轮不增长意味着管道的充放已经趋于饱和。

3.2 Drain（排空）

进入 Drain 状态后，pacing_gain = 0.5（即 1/2.27），发送速率骤降。目标是排空 Startup 阶段超额注入的队列（数据积压在瓶颈路由器缓冲区中），使 inflight 降到 BDP。

Drain 退出条件：inflight ≤ BDP（即管道中的数据量已经减少到理想值）或持续 10 秒以上。然后转入 ProbeBW 稳态循环。

3.3 ProbeBW（稳态探测）——核心循环

连接 99% 以上的时间都在 ProbeBW 状态中。BBR 在这里使用一个 8 阶段的 cycle，每个阶段持续一个 RTT，循环使用以下 gain 值序列：

ProbeBW gain 循环（8 RTT 一个周期）:
  RTT 1: gain = 1.25   # 向上探测 25% 是否有额外带宽
  RTT 2: gain = 0.75   # 向下排空，将队列控制为 0
  RTT 3: gain = 1.0    # 稳态运行
  RTT 4: gain = 1.0    # 稳态运行
  RTT 5: gain = 1.0    # 稳态运行
  RTT 6: gain = 1.0    # 稳态运行
  RRT 7: gain = 1.0    # 稳态运行
  RTT 8: gain = 1.0    # 稳态运行

这个精巧设计的含义是：每个 cycle 中有 1/8 的时间在做向上探测（pacing_rate 为 BtlBw 的 1.25 倍），目的是测试瓶颈带宽是否增长了。如果测试失败（多余的 0.25×BtlBw 无法被确认），inflight 会短暂超过 BDP，产生排队，然后在 gain=0.75 阶段被排空。稳态的 6/8 时间运行在精确瓶颈速率上，保持零排队。

3.4 ProbeRTT（RTT 探测）

每隔 10 秒 BBR 会进入 ProbeRTT 状态，持续至多 200ms。进入时将 inflight 降到 4 个数据包（极小的值），强制排空排队，以测量真正的 RTprop。

为什么需要专用的 RTT 探测？因为在 ProbeBW 的稳态阶段，inflight ≈ BDP，TCP 不会对 RTT 做新的采样。如果路径中的物理传播时延发生了改变（比如路由切换），RTprop 必须被重新测量。

退出 ProbeRTT 的条件：已经获得一个新的 min_rtt 采样（inflight=4 意味着 RTT ≈ minRTT，此时测得的 RTT 就是Propagation Time），或者持续时间超过 200ms 则切回 Startup。

四、BBRv1 的问题与 BBRv2 的演进

4.1 BBRv1 的多流公平性问题

BBRv1 最大的生产问题之一是和其他算法共存时的带宽抢占。当 BBRv1 和 CUBIC 共享瓶颈链路时：

• CUBIC 填满缓冲区直到丢包，然后乘性减
• BBRv1 维持 inflight = BDP，但 pacing_rate = 1.25×BtlBw 时会主动制造 25% 的过载
• 结果：当缓冲区较小时，BBRv1 的向上探测导致 CUBIC 流的丢包率剧增，CUBIC 几乎被"挤死"

实测数据表明，1 个 BBRv1 流 + 1 个 CUBIC 流在浅缓冲链路中，BBRv1 可能占据 80%-90%+ 的带宽。

BBRv1 对非拥塞丢包的响应也不够迅速——因为它将带宽估计与 RTT 解耦，random loss 不会触发带宽缩减。这在有丢包的网络上导致 inflight 持续高于可用 capacity。

4.2 BBRv2 的核心改进

BBRv2 沿用相同的带宽/RTprop 测量模型，但进行了以下关键改进：

1. 引入 loss 信号的统一响应：当 loss rate > 当前 target loss rate（或 2% 默认阈值），BBRv2 会将 inflight 限制为 BDP × (1 - loss_rate/2)，主动将多余数据排出。这使得 BBRv2 能够及时向 CUBIC 等 loss-based 流让出空间。

2. ECN 信号支持：BBRv2 支持 ECN-CE (Explicit Congestion Notification - Congestion Experienced) 标记作为提前的拥塞信号，类似 DCTCP 的思路。当收到 CE 标记时立即缩减窗口，而不必等到实际丢包。这使其在现代数据中心网络中能更公平地分享带宽。

3. 改进的 Startup 退出条件：BBRv2 在 Startup 中使用 delivery rate 增长率和 loss 信号共同判断是否退出慢启动，避免过度填充。

4. 更短的 ProbeBW cycle：BBRv2 将 gain cycle 从 8 RTT 缩短为更短的探测窗口，减少在不必要时的带宽振荡。

5. 模式切换：BBRv2 支持在 ProbeBW 中根据当前是在做 bandwidth probing 还是 model consistency check 切换不同的 gain 序列，避免在确认阶段的不必要过载。

4.3 BBRv2 状态机改进示意

BBRv2 状态机简化示意:

               ┌──────────────────────────┐
               │        STARTUP           │
               │  refill pipe, gain=2.37  │
               └────────────┬─────────────┘
                            │ BtlBw stable OR loss detected
                            ▼
               ┌──────────────────────────┐
               │         DRAIN            │
               │  drain queue, gain=0.54  │
               └────────────┬─────────────┘
                            │ inflight <= BDP
                            ▼
         ┌──────────────────────────────────────────┐
         │              PROBE_BW 循环               │
         │                                          │
         │  if loss_rate > target:                  │
         │      mode = LOSS (inflight cap = BDP×k)  │
         │  elif ecn_marked:                        │
         │      mode = ECN (reduce window)          │
         │  else:                                   │
         │      mode = REFILL/PROBE gain cycle      │
         └────────────────────┬─────────────────────┘
                              │ every 10s
                              ▼
               ┌──────────────────────────┐
               │       PROBE_RTT          │
               │  measure min RTT         │
               └──────────────────────────┘

五、Linux 内核 BBR 源码剖析

5.1 关键数据结构

// include/net/tcp.h 中的 tcp_sock 扩展部分
struct bbr {
    u32     bbr_min_rtt_us;          // 最小RTT（微秒级）
    u32     bbr_min_rtt_stamp;       // min_rtt 上次更新的 jiffies
    u32     bbr_init_cwnd;           // 初始拥塞窗口

    /* Delivery rate estimation state */
    u64     bbr_bw;                  // BtlBw 最大滤波后的估计
    u32     bbr_bw_hi;              // bw 的上界
    u32     bbr_bw_lo;              // bw 的下界
    u32     bbr_bw_stamp;           // bw 估计的时间戳

    /* 状态机 */
    u32     bbr_mode;              // STARTUP/DRAIN/PROBE_BW/PROBE_RTT
    u32     bbr_cycle_idx;         // ProbeBW 的 8 阶段索引
    u8      bbr_probe_rtt_done_stamp;
    u32     bbr_probe_rtt_rounds;
    u32     bbr_bw_probe_up_cnt;
    u32     bbr_bw_probe_up_acks;

    /* Pacing */
    u32     bbr_pacing_rate;       // pacing 发送速率

    /* RTT filtering */
    u32     bbr_round_count;       // RTT 轮次计数
    
    /* 各种flag */
    u32     bbr_recovery:1,        // 是否在恢复期 
            bbr_retrans_skb1:1,    // 重传标记
            bbr_tlp_in_progress:1,
            bbr_cycle_mstamp,       // cycle 内 mstamp
            bbr_ack_phase;          // ACK 处理阶段
    
    u32     bbr_extra_ack[2];      // ACK 统计数组
    u32     bbr_offload_budget;
    u32     bbr_ack_epoch_acked;
    u32     bbr_ack_epoch_mstamp;  // ACK epoch 时间戳
};

5.2 BBR 带宽估计核心流程

BBR 在每一个 ACK 到达时更新带宽估计：

// net/ipv4/tcp_bbr.c: bbr_update_bw()
static void bbr_update_bw(struct sock *sk)
{
    struct tcp_sk tcp_sk(sk);
    struct bbr *bbr = inet_csk_ca(sk);
    u64 bw;

    bbr > bbr_round_stamp = tcp_jiffies32;
    
    // 调用 delivery_rate 估计
    tcp_rate_skb_delivered(sk, skb, bbr > bbr_ack_epoch_mstamp);
    
    // 采样当前 delivery rate
    bw = tcp_rate_skb_bw(sk, skb, is_app_limited);
    
    if (is_app_limited)
        return;  // 忽略应用层限制下的采样
    
    // max filter: 取近10秒内的最大带宽
    if (!bbr > bbr_bw || bw >= bbr > bbr_bw) {
        // 新的最大带宽
        bbr > bbr_bw = bw;
        bbr > bbr_bw_stamp = tcp_jiffies32;
    }
    
    // 检查是否超时需要更新
    else if (after(tcp_jiffies32, bbr > bbr_bw_stamp + HZ/4)) {
        // 4个RTT无新采样，衰减带宽
        bbr > bbr_bw = 0;
    }
}

BBR 使用 max filter而非 average filter 来估计带宽，这是因为它要估计的是可达的峰值带宽（一旦管道被填满就能达到的速率），而不是实际的时均速率。max filter 取近10 秒窗口内的最大 delivery rate 采样。

5.3 BBR 的 pacing rate 决策逻辑

// bbr_set_pacing_rate() 核心伪代码
pacing_rate = bbr_bw;                  // 基础是当前带宽估计
if (mode == STARTUP)
    pacing_rate *= 2.27;               // Startup 向上探测
else if (mode == DRAIN)
    pacing_rate *= 0.5;                // Drain 排空队列
else if (mode == PROBE_BW) {
    if (cycle_idx == 0)                // 第1个RTT向上探测
        pacing_rate *= 1.25;
    else if (cycle_idx == 1)           // 第2个RTT排空
        pacing_rate *= 0.75;
    else                               // 稳态6个RTT
        pacing_rate *= 1.0;
}
else if (mode == PROBE_RTT) {
    pacing_rate = 4 * MSS / RTT;      // 极低速率测量RTprop
}

// 应用 pacing rate 到 TCP 内核
sk->sk_pacing_rate = pacing_rate;

5.4 BBR 与 TCP congestion avoidance 的集成

BBR 作为 pluggable congestion control module 被纳入 Linux 内核，通过注册 tcp_congestion_ops 接口与 TCP 主栈交互：

// net/ipv4/tcp_bbr.c: 模块注册
static struct tcp_congestion_ops tcp_bbr_cong_ops __read_mostly = {
    .name           = "bbr",
    .owner          = THIS_MODULE,
    .init           = bbr_init,
    .cong_avoid     = bbr_main,           // ACK 处理入口
    .set_state      = bbr_set_state,       // 进入 loss recovery 等
    .cwnd_event     = bbr_cwnd_event,      // 窗口事件（TLP/RTO等）
    .ssthresh       = bbr_ssthresh,         // slow start threshold
    .cong_control   = bbr_main,            // 替代 cong_avoid 的内联路径
    .undo_cwnd      = bbr_undo_cwnd,       // 恢复原始窗口
    .get_info       = bbr_get_info,        // /proc/net/tcp_info 暴露数据
    .min_tso_segs   = bbr_min_tso_segs,    // 最小 TSO 分段
    .release_cb     = bbr_release_cb,      // 连接释放回调
};

用户通过 sysctl 切换拥塞控制算法：sysctl -w net.ipv4.tcp_congestion_control=bbr

六、BBR vs CUBIC 实测对比

6.1 高 BDP 网络（10Gbps, 100ms RTT）

• CUBIC：需要缓冲区 ≥ BDP = 125MB 才能达线速。若缓冲区不足，吞吐严重下降
• BBR：无需依赖缓冲区大小即可稳定在 BtlBw，通过 pacing 精确控制发送速率
• 实测对比：BBR 吞吐 9.5-9.8Gbps（95-98%利用率），CUBIC 在256MB缓冲区下达9.2Gbps，64MB时仅7-8Gbps

6.2 浅缓冲区瓶颈（WiFi 网络，缓冲区 32KB）

• CUBIC：频繁丢包导致窗口震荡，带宽利用率仅 30-50%
• BBR：通过精确的 pacing 控制 inflight ≈ BDP，绕过了对缓冲区容量的依赖，利用率 80-90%
• RTT 对比：CUBIC 下 RTT 从 30ms（传播时延）膨胀到 150-300ms（排队时延），BBR 保持稳定在 35-45ms

6.3 10 条流竞争场景

• 10 个 BBRv1 流：每个流最终收敛到 BtlBw/10，分配较为公平（竞争系数约 1.05-1.10）
• 10 个 CUBIC 流：经典 AIMD 保证公平分配，但整体缓冲区膨胀严重
• 混合 5 BBRv1 + 5 CUBIC：BBRv1 平均占用 70-80% 带宽，CUBIC 被严重挤压
• 混合 5 BBRv2 + 5 CUBIC：BBRv2 loss fallback 使分配回归公平（各约 50%）

七、生产环境调优实践

7.1 启用 BBR

# 检查内核版本（需要 ≥ 4.9）
uname -r
# 5.15.0-56-generic

# 检查 BBR 模块是否可用
modprobe tcp_bbr
ls /lib/modules/$(uname -r)/kernel/net/ipv4/tcp_br

# 启用 BBR
sysctl -w net.core.default_qdisc=fq          # 必须配合 fq qdisc
sysctl -w net.ipv4.tcp_congestion_control=bbr

# 永久保存
echo "net.core.default_qdisc = fqq" >> /etc/sysctl.conf
echo "net.ipv4.tcp_congestion_control = bbr" >> /etc/sysctl.conf
sysctl -p

7.2 fq qdisc 与 pacing 的配合

BBR 需要 fq (Fair Queue) 作为队列规则。fq 实现 flow-isolation：将不同 TCP 连接的数据分到独立的队列，每个队列有独立的 pacing timeline。这保证了 BBR 的 per-connection pacing 能被正确执行——不使用 fq 时 BBR 仍然工作，但无法实现真正的 pacing 控制。

为什么不是 fq_codel？fq_codel 主要用于 bufferbloat 缓解（主动丢包控制排队深度），与 BBR 的功能重叠且可能冲突。fq 是 BBR 官方推荐的 pairing。

7.3 数据中心场景调优

Google 在内部部署 BBR 的推荐配置：

# 数据中心（低 RTT 内部链路）优化
# 1. 初始窗口保持默认 10*MSS
sysctl -w net.ipv4.tcp_slow_start_after_idle=0
# 2. 禁用 slow start after idle，避免空闲后重新慢启动

# 3. 扩大 socket buffer
sysctl -w net.core.rmem_max=16777216      # 16MB 接收缓冲
sysctl -w net.core.wmem_max=16777216      # 16MB 发送缓冲
sysctl -w net.ipv4.tcp_rmem="4096 87380 16777216"
sysctl -w net.ipv4.tcp_wmem="4096 65536 16777216"

7.4 视频推流场景优化

YouTube 部署 BBR 的关键优化领域：

• 头阻塞问题：BBR 在 ProbeBW 的 gain=0.75 阶段会短暂降速，可能引起视频码率切换。Google 通过自适应码率逻辑配合 BBR 的带宽预测（bbr_bw 估计暴露给应用层）提前调整编码码率
• 浅缓存链路：用户家庭路由器缓冲通常极小（16-64KB），BBR 在此场景下相比 CUBIC 有显著吞吐提升
• 启动加速：视频首帧（first frame）的加载时间在 Startup 阶段被显著缩短——Startup 的指数增长能快速填满管道

7.5 广域网加速

在跨国广域网（典型 BDP = 1Gbps × 200ms = 25MB）中：

• BBR 通过 pacing 在200ms 的RTT周期内均匀发送 25MB 数据，避免突发丢包
• 短期内带宽波动（比如拥塞时段带宽下降 50%），BBR 会在下一个 ProbeBW cycle 中快速检测到新的 BtlBw 并适配
• CUBIC 对带宽下降的响应极慢——需要填满新 pipe 再判定丢包，可能浪费几十个 RTT

7.6 监控与可观测性

BBR 在内核暴露了丰富的状态信息：

# ss 命令查看 BBR 连接详情
ss -ti dst 10.0.0.1:443

# 输出示例（关键字段）
 cubic wscale:7,7 rto:216 rtt:14.562/7.281 ato:40 cwnd:10 send 5.6Mbps 
 rcve RTT:14.562
 # BBR 特有字段：
 bbr:(bw:853Mbps,mrtt:14.562,pacing_gain:1.000,cwnd_gain:2.000)

# 关键字段含义：
# bw = 853Mbps     → BtlBw 当前估计
# mrtt = 14.562    → min RTT (ms)
# pacing_gain       → 当前 probe 相位的 pacing 增益
# cwnd_gain = 2.0   → cwnd = 2 × BDP 允许适度突发

八、BBR 在 Linux 内核中的新进展

8.1 BBRv3（2024-2026研发方向）

BBRv3 ongoing 的开发聚焦在以下方向：

• 更低的 ProbeRTT 侵入：缩短 ProbeRTT 的持续时间，减少对应用层的吞吐影响
• Loss 信号优先：在较高丢包网络（>5%）中以 loss 信号为主而非 max-rate 探测，减少无谓的带宽浪费
• RTT 公平性：不同 RTT 的流共享带宽时，长 RTT 流不被短 RTT 流过度挤压（当前 BBR 的 `cwnd_gain` 对此有一定补偿）
• 与 L4S (Low Latency Low Loss Scalable throughput) 的整合：BBRv3 正在探索与 L4S 生态系统兼容，使用 Scalable CE 标记替代传统的 loss 信号

8.2 与 QUIC 协议的融合

QUIC（HTTP/3 的传输层）将拥塞控制从内核态移到了用户态实现。Google 在 QUIC 代码库中实现了 BBR as user-space congestion controller，不依赖内核模块。这带来一些优势：

• 拥塞算法升级无需更新内核
• 不同应用可以使用不同的拥塞控制策略
• 更精细的应用层数据收集（比如可以将 BBR 带宽估计直接暴露给 HTTP/3 层的自适应逻辑）

QUIC BBR 的实现思路与内核 BBR 一致，但 pacing 在用户态需要用 timerfd + sendmmsg 精确控制发送时序。

九、总结

BBR 的设计哲学可以归结为两点：测量优于假设、控制优于响应。

传统 loss-based 算法假设丢包 = 拥塞，这是一个在 1988 年 Jeremi 提出 Tahoe 的拥塞避免时正确的假设——当时网络缓冲小，丢包确实主要由拥塞导致。但在现代互联网（大量 Wi-Fi/移动网络、数据中心浅缓存、卫星链路）下，这个假设不再成立。

BBR 的革命性在于它回到了第一性原理：带宽 = 瓶颈速率，时延 = 传播时延。通过持续测量这两个量，BUILDING 一个网络管道模型，然后在这个模型指导下精确控制发送节奏。不是等出了问题再被动反应，而是在问题发生之前就保持在安全区内。

从 BBRv1 到 BBRv2 再到正在研发的 BBRv3，我们可以看到工程算法不断在网络效率、公平性和鲁棒性之间寻找平衡。BBR 的故事还远未结束——在 5G、卫星物联网、多云互联等新的网络场景下，拥塞控制算法的演进将继续推动数据传输效率的边界。

参考资料

• Cardwell, N. et al. "BBR: Congestion-Based Congestion Control". ACM Queue, 2016
• Cardwell, N. et al. "BBRv2: A Model-based Congestion Control". IETF TCPM Working Group, 2019-2024
• Linux Kernel Source: net/ipv4/tcp_bbr.c — BBR 实现源码
• Linux man page: tcp(7) — BBR 相关 sysctl 参数文档
• Google Blog: "BBR: Congestion Control Makes YouTube 4% Faster"
• QUIC Transport: IETF QUIC Working Group — 用户态 BBR 实现参考