海外服务器从CUBIC切换BBR前，内核参数与回滚方案怎么设计？

把海外服务器从 CUBIC 切换到 BBR，不应设计成一次性修改全机参数并立即重启的操作。生产变更的目标应是：在确认内核支持、出口网卡和业务流量范围后，仅让新建 TCP 连接逐步使用 BBR，同时保留原始 CUBIC、队列规则和持久化配置的可恢复副本。

这类变更的主要风险不在于命令本身，而在于影响面容易被低估。BBR可能改变出口带宽占用、队列长度、重传行为和不同业务之间的带宽公平性；net.core.default_qdisc只决定默认队列，当前网卡上的实际 qdisc 还可能需要单独处理。生产方案应按照“现状核对—备份准备—小流量实施—分阶段观察—满足条件才扩容”的顺序执行。

变更目标与影响边界

先明确目标状态

本次变更通常包含两个目标：

1. 新建 TCP 连接默认使用 BBR。
2. 出口网卡使用适合 BBR pacing 的 fq 队列，或者确认现有队列已经满足业务和内核要求。

目标配置一般如下：

net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

但这两个参数的作用范围并不完全相同：

因此，修改 net.core.default_qdisc=fq 不等于当前网卡已经切换为 fq。如果当前接口仍然使用 fq_codel、pfifo_fast、noqueue 或复杂的 classful qdisc，需要单独核对是否要修改。

服务器端能影响哪些流量

BBR控制的是本机 TCP 发送方向的拥塞控制，不能改变通信对端的算法。

对于跨地区业务，不能只看主机整体平均值。至少应按业务方向、目标地区、运营商或上游网络分别观察。某一条海外线路改善，不代表其他线路也会同步改善。

不把“长肥管道”简单等同于“把缓存调大”

长肥管道通常意味着带宽高、RTT较大，带宽时延积较高。例如：

• 带宽为 1 Gbit/s；
• RTT约为 180 ms；
• 带宽使用十进制 bit/s 计算。

带宽时延积为：

1,000,000,000 bit/s × 0.18 s ÷ 8 = 22,500,000 bytes

也就是约 22.5 MB。

这个数值用于判断链路理论上可能需要多少在途数据，并不意味着应直接把 tcp_rmem、tcp_wmem 或 net.core.wmem_max 设置成 22.5 MB。Linux TCP接收窗口、应用读取速度、发送缓冲区、网卡队列和中间设备都会影响实际结果。没有基线数据时，盲目放大缓存可能增加内存占用和排队延迟，甚至掩盖应用处理能力不足。

现状核对：先确认到底能不能切

核对发行版、内核与内核算法

先记录操作系统、内核版本和当前拥塞控制算法。不要根据“某个发行版通常支持 BBR”直接进入实施。

uname -a
cat /etc/os-release

sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.ipv4.tcp_available_congestion_control
sysctl -n net.ipv4.tcp_allowed_congestion_control 2>/dev/null || true

正常情况下，tcp_available_congestion_control 可能包含类似以下内容：

reno cubic bbr

如果列表中没有 bbr，可以尝试加载发行版已经提供的内核模块：

sudo modprobe tcp_bbr
sysctl -n net.ipv4.tcp_available_congestion_control

如果 modprobe tcp_bbr 失败，或者加载后仍然没有 bbr，本次变更应停止。不要在生产窗口内临时安装来源不明的内核脚本或替换内核。需要升级内核时，应把“内核升级、重启、启动后验证”作为独立变更，不能和拥塞控制切换混在同一个回滚单元中。

BBR v1 与 BBR v2 也不能仅凭名称判断。不同发行版可能对内核做了回移植，tcp_bbr 模块名称相同并不代表实现版本相同。生产记录中应至少保存以下信息：

• uname -r 的内核版本；
• tcp_available_congestion_control 输出；
• modinfo tcp_bbr 是否可用；
• 云厂商或发行版对当前内核的支持说明；
• 是否计划使用发行版默认的 BBR 实现，而不是自行替换算法模块。

如果本次目标只是从 CUBIC 切到 BBR，应优先使用当前发行版已经验证过的 bbr，不要同时引入 BBR v2、第三方补丁或自定义内核。

核对出口网卡和当前 qdisc

先找到真实承载业务流量的接口。不要默认使用 eth0，云主机可能使用 ens3、enp1s0 或其他命名。

DEST_IP=198.51.100.10
ip route get "$DEST_IP"

示例输出可能类似：

198.51.100.10 via 192.0.2.1 dev ens3 src 192.0.2.20

记录其中的 dev 网卡名，再查看当前队列：

IFACE=ens3

ip -details link show dev "$IFACE"
tc qdisc show dev "$IFACE"

重点记录：

• root qdisc 类型；
• 是否存在 handle、class、filter 或多层队列；
• 是否由 NetworkManager、systemd-networkd、云初始化工具或云厂商代理动态下发；
• 是否存在多张业务网卡、策略路由或容器虚拟网卡。

如果输出显示当前接口是复杂的 classful qdisc，或者由云平台网络代理管理，不应直接执行 tc qdisc replace ... root fq。这会覆盖当前 root qdisc，可能使流量分类、限速、优先级或容器网络行为发生变化。

核对 TCP 缓冲区和相关参数

先查看现有值，避免把与本次目标无关的 TCP 参数一起改掉：

sysctl \
  net.ipv4.tcp_congestion_control \
  net.core.default_qdisc \
  net.ipv4.tcp_moderate_rcvbuf \
  net.ipv4.tcp_rmem \
  net.ipv4.tcp_wmem \
  net.core.rmem_max \
  net.core.wmem_max

建议按照以下原则处理：

如果业务当前存在 PMTU异常、应用发送缓慢、接收端窗口不足或明显的内存压力，应先单独处理这些问题。一次变更同时修改拥塞控制、MTU、Socket缓冲区和连接回收参数，出现问题后很难定位根因。

建立变更前基线

至少保存一个完整业务周期内的基线。跨地区业务建议覆盖低峰和一个高峰时段，避免只用几分钟的平均值做判断。

需要记录的指标包括：

• 按地区或目标网络拆分的吞吐量；
• TCP连接建立成功率、连接超时和重置数量；
• 应用请求成功率、4xx、5xx和超时；
• p50、p95、p99响应延迟；
• TCP重传、超时和重复确认；
• 网卡丢包、错误、软中断和 CPU 使用率；
• 连接数、发送队列、应用线程池和连接池占用；
• 发生切换时正在使用 CUBIC 的连接规模。

可以使用以下命令辅助采集主机层数据。不同发行版的计数器名称可能略有差异，命令输出应以实际系统为准。

ss -s
ss -tin state established | sed -n '1,120p'

nstat -az 2>/dev/null | egrep \
  'TcpRetransSegs|TcpTimeout|TCPTimeout|TCPSynRetrans|TCPBacklogDrop' || true

sar -n DEV 1 5 2>/dev/null || true
ip -s link show dev "$IFACE"

主机指标只能作为辅助。最终放行标准应优先使用业务指标，例如“海外下载成功率不下降、指定地区 p95 不恶化、吞吐达到预期区间”。

变更准备：让回滚路径先于实施路径成立

备份 sysctl、网卡队列和持久化文件

建议使用独立的变更编号目录保存现场数据，不直接覆盖原有配置文件。

TS=$(date +%Y%m%d-%H%M%S)
BACKUP="/var/backups/bbr-change-${TS}"

sudo install -d -m 0700 "$BACKUP"

sudo sysctl -a > "$BACKUP/sysctl-all.txt"
sudo sysctl \
  net.ipv4.tcp_congestion_control \
  net.core.default_qdisc \
  net.ipv4.tcp_rmem \
  net.ipv4.tcp_wmem \
  net.core.rmem_max \
  net.core.wmem_max \
  > "$BACKUP/tcp-selected.txt"

sudo tc qdisc show > "$BACKUP/qdisc-all.txt"
sudo ip -details link show > "$BACKUP/link-details.txt"

sudo cp -a /etc/sysctl.d "$BACKUP/sysctl.d"
sudo cp -a /etc/modules-load.d "$BACKUP/modules-load.d"

同时单独记录本次变更使用的接口和原始值：

echo "interface=$IFACE" | sudo tee "$BACKUP/change-state.txt"
echo "old_cc=$(sysctl -n net.ipv4.tcp_congestion_control)" | \
  sudo tee -a "$BACKUP/change-state.txt"
echo "old_default_qdisc=$(sysctl -n net.core.default_qdisc)" | \
  sudo tee -a "$BACKUP/change-state.txt"
sudo tc qdisc show dev "$IFACE" | sudo tee "$BACKUP/qdisc-${IFACE}.txt"

tc qdisc show 的输出是恢复依据，但不一定能直接作为回滚命令。简单的 fq_codel 或 pfifo_fast 可以按原类型恢复；复杂的层级队列必须按照网络配置管理工具或原始编排文件恢复。

确认管理通道与故障逃生方式

变更前必须确认至少有一种不依赖当前业务连接的管理路径：

• 云平台串口、VNC或控制台；
• 独立的带外管理网络；
• 另一张不受本次 qdisc 变更影响的管理网卡；
• 已验证的自动回滚脚本或远程执行平台。

不能只依赖一条正在经过海外线路的 SSH连接。BBR切换本身通常不会中断 SSH，但覆盖 root qdisc、网络服务重载或错误的持久化配置可能导致连接质量恶化。执行 qdisc变更时，应保留当前管理会话，并从独立终端验证新的登录路径。

确认分批方式

net.ipv4.tcp_congestion_control 是主机级默认值，不适合在同一台承载大量不同业务的服务器上直接当成精细化灰度开关。优先级从高到低如下：

1. 单独准备一台同规格、同地域、同出口类型的 canary 服务器；
2. 通过负载均衡只分配 5%至10%的业务流量；
3. 对无状态业务先灰度，再扩展到更多节点；
4. 如果应用能够可靠地为指定 Socket 设置拥塞控制，可只对目标服务启用，但必须先在测试环境验证；
5. 不建议通过临时网络命名空间或未经验证的脚本模拟生产灰度。

如果只有一台服务器，至少要安排低峰窗口、准备管理控制台，并把变更限制在较短的观察阶段。单机无法同时保留 CUBIC 与 BBR 的对照组，结论可信度会下降。

预先冻结放行和回滚阈值

阈值应在实施前确定，不能等出现争议时临时修改。下面是一组可作为起点的示例，实际数值应结合业务基线调整：

“单个短时尖峰”不一定需要回滚，但业务错误、连接大量失败、管理通道不稳定属于硬门槛，不应等待完整观察窗口。

分步实施：先加载能力，再改变默认值

第一步：加载并确认 BBR 模块

在 canary 主机或灰度节点执行：

sudo modprobe tcp_bbr

sysctl -n net.ipv4.tcp_available_congestion_control
sysctl -n net.ipv4.tcp_congestion_control

确认输出中包含 bbr 后，才进入下一步。如果模块加载成功但列表中没有 BBR，应停止变更并检查内核配置，不要继续写入持久化配置。

如果 tcp_bbr 是模块而不是内核内置组件，重启后是否自动加载需要单独处理。只有在确认 modinfo tcp_bbr 可用、且发行版使用标准 modules-load 机制时，才考虑写入：

modinfo tcp_bbr >/dev/null 2>&1
echo $?

返回 0 后，可以创建独立文件：

printf '%s\n' tcp_bbr | sudo tee /etc/modules-load.d/tcp-bbr.conf
sudo chmod 0644 /etc/modules-load.d/tcp-bbr.conf

如果 BBR 已经编译进内核，不需要为了持久化强行创建该文件。无论哪种情况，都应在测试重启或下一次计划重启后重新验证。

第二步：确认是否需要切换当前 qdisc

如果当前网卡已经是 fq，通常不需要再次替换：

tc qdisc show dev "$IFACE"

如果当前是 fq_codel，BBR仍可能正常工作，是否切换到 fq应由测试数据和队列策略决定。不要把“推荐 fq”理解为“所有现有 qdisc 都必须立即替换”。

只有在以下条件同时满足时，才考虑替换当前 root qdisc：

• 已保存原始 qdisc完整输出；
• 确认该接口没有复杂流量分类；
• 确认云平台、容器网络和网络管理工具不会覆盖手工设置；
• 已获得变更授权；
• 有可以恢复原始 qdisc 的明确命令。

示例命令如下，但不能脱离现状直接复制执行：

IFACE=ens3
sudo tc qdisc show dev "$IFACE"

# 仅在已确认要使用 fq，且当前 root qdisc 可被安全替换时执行
sudo tc qdisc replace dev "$IFACE" root fq

sudo tc qdisc show dev "$IFACE"

tc qdisc replace 会影响该网卡上的排队行为。它不是只对 BBR连接生效，UDP、其他 TCP业务以及共享该接口的服务都可能受到影响。对于复杂 qdisc，不建议在本文这类 BBR变更中顺带重构队列。

第三步：先临时切换，再写入持久化配置

在确认模块和队列状态后，先通过运行时参数验证：

sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq

sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.core.default_qdisc

需要注意，net.core.default_qdisc=fq不一定会立刻改变当前接口的 qdisc。当前接口是否使用 fq，仍应通过以下命令确认：

tc qdisc show dev "$IFACE"

如果运行时验证通过，再使用单独的配置文件持久化，避免直接编辑 /etc/sysctl.conf 或覆盖发行版已有文件：

sudo tee /etc/sysctl.d/99-bbr-change.conf >/dev/null <<'EOF'
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
EOF

sudo chmod 0644 /etc/sysctl.d/99-bbr-change.conf
sudo sysctl -p /etc/sysctl.d/99-bbr-change.conf

重新加载后再次检查：

sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.core.default_qdisc
sysctl -n net.ipv4.tcp_available_congestion_control

不建议在同一时间执行 sysctl --system，因为它可能重新加载多个目录中的全部参数，把与本次变更无关的配置错误一并带入生产环境。

第四步：只观察新建连接

修改默认算法不会把已经建立的 CUBIC连接强制迁移为 BBR。变更后的一段时间内，同一台服务器上可能同时存在两类连接：

• 变更前建立的连接继续使用 CUBIC；
• 变更后建立的连接使用 BBR。

可以通过 ss 查看部分连接信息：

sudo ss -tin state established | sed -n '1,160p'

不同版本的 ss 对 TCP_INFO 的展示格式不同，可能显示 bbr、cubic 或不显示算法名称。因此，不能只用 grep bbr 作为唯一验证方式。更可靠的方式包括：

• 使用应用或代理层读取 TCP_INFO；
• 在连接建立后记录 Socket 的拥塞控制算法；
• 对 canary 节点的新建连接做固定请求测试；
• 将连接建立时间与切换时间对应起来，区分旧连接和新连接。

不要为了“看到 BBR”而强制关闭全部旧连接。大规模断连会把连接重建、TLS握手、应用冷缓存和上游连接池压力混入本次变更，反而降低判断准确性。

验证与观察：按业务方向看结果

立即验证项

运行时修改完成后，先确认四个层面的状态：

sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.core.default_qdisc
sysctl -n net.ipv4.tcp_available_congestion_control
tc qdisc show dev "$IFACE"

然后确认服务本身没有出现异常：

ss -s
ss -tan state established | wc -l
ip -s link show dev "$IFACE"

如果接口上的丢包、错误或发送队列立即异常增长，应先停止扩容。不要因为应用暂时还能访问，就继续扩大流量比例。

验证目标方向，而不是只看总吞吐

海外业务需要把观测维度拆开。例如：

• 欧洲用户下载接口的响应延迟；
• 亚洲用户访问静态文件的吞吐；
• 服务器向海外对象存储上传的完成时间；
• 服务器向上游 API 发起请求的连接超时；
• 国内或本地业务是否因共享出口队列受到影响。

同一台服务器的总带宽可能上升，但某个关键地区的 p99 延迟也可能恶化。BBR的成功标准不是“总流量越大越好”，而是在目标方向上改善或保持吞吐，同时不引入可接受范围之外的排队、重传和业务错误。

按阶段观察

可按照以下节奏推进：

如果业务流量很小，15分钟内没有足够的新建连接，不能据此判定成功。此时应延长观察时间，或者通过受控的固定测试流量验证，但不要在生产出口上运行未经审批的大流量压测。

识别“BBR没有改善”的情况

以下现象不一定表示切换失败：

• 业务主要是短连接、小响应，连接尚未进入稳定发送阶段；
• 瓶颈在远端限速、应用线程、磁盘或对象存储，而不在 TCP拥塞控制；
• 目标方向的实际出口带宽已经被服务商或中间设备限制；
• 用户侧上传方向由客户端 CUBIC控制；
• 业务使用 UDP或其他独立拥塞控制机制；
• 现有 TCP自动调优或发送缓冲区限制了可用窗口。

如果 BBR连接的 RTT和重传表现正常，但业务吞吐没有提升，不应直接继续放大 tcp_wmem。应先确认应用写入速度、Socket发送缓冲区、接收端窗口、远端限速和链路容量。

回滚条件与执行路径

需要立即停止扩容的条件

出现以下任一情况，就应暂停下一批节点，并根据影响程度执行回滚：

1. BBR模块无法加载，或 tcp_available_congestion_control中不存在 bbr。
2. 当前接口的 qdisc被意外替换，原有流量分类、限速或容器网络受到影响。
3. 目标地区的应用 p95延迟持续高于基线约20%。
4. TCP重传、超时、RST或连接池耗尽持续增加，并伴随吞吐下降。
5. 业务成功率或关键接口可用性超过预设错误阈值。
6. 服务器软中断、网卡丢包、发送队列或系统负载达到风险水位。
7. 非目标业务出现能够关联到共享出口队列的延迟和丢包。
8. 失去带外管理通道，无法确认当前主机状态。

不要等到所有指标都异常才回滚。对于连接大量失败、业务错误持续上升或管理通道不稳定的情况，应优先恢复可预测的 CUBIC状态。

回滚顺序

1. 停止扩容并保护现场

先停止负载均衡向更多节点分配流量，记录当前指标和命令输出。不要先删除配置再收集现场，否则可能丢失定位信息。

date
hostname
sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.core.default_qdisc
tc qdisc show dev "$IFACE"
ss -s
ip -s link show dev "$IFACE"

2. 先把新建连接恢复为 CUBIC

使用变更前记录的实际算法。如果原值是 CUBIC，可以执行：

sudo sysctl -w net.ipv4.tcp_congestion_control=cubic

如果变更前不是 CUBIC，应使用备份中的原始值，而不是直接假设为 cubic。

恢复后验证：

sysctl -n net.ipv4.tcp_congestion_control

这一步只影响之后建立的连接。已经建立的 BBR连接通常不会因为修改默认值而自动切回 CUBIC。

3. 恢复当前网卡的原始 qdisc

只有本次确实执行过 tc qdisc replace，并且原始 qdisc已明确记录时，才执行恢复。

例如，变更前明确记录为 fq_codel，且没有额外参数，可以使用：

sudo tc qdisc replace dev "$IFACE" root fq_codel

如果原始值是 pfifo_fast，则使用：

sudo tc qdisc replace dev "$IFACE" root pfifo_fast

如果原始是 noqueue，则使用：

sudo tc qdisc replace dev "$IFACE" root noqueue

以上命令只能选择与变更前实际输出相符的一条。对于带有 class、filter、handle 或多个子队列的配置，不要用上述简单命令覆盖恢复，应按照备份的完整网络配置或编排工具恢复。

如果本次只修改了 net.core.default_qdisc，没有修改当前接口 root qdisc，则不需要为了回滚而额外执行 tc qdisc replace。错误地替换 qdisc可能比原变更造成更大影响。

4. 恢复持久化参数

可以先恢复运行时的默认队列值，再删除本次新增文件：

sudo sysctl -w net.core.default_qdisc="<变更前记录的值>"
sudo rm -f /etc/sysctl.d/99-bbr-change.conf

上面的 <变更前记录的值>不能直接作为命令输入，应替换为备份中的实际值，例如 fq_codel。如果需要让配置立即重新计算，可以再次读取原有配置文件，但不要无审查地执行整个系统的 sysctl --system。

如果本次新增了模块自动加载文件，也应删除：

sudo rm -f /etc/modules-load.d/tcp-bbr.conf

不建议为了回滚而执行 rmmod tcp_bbr。已有连接可能仍在使用该算法，且 BBR可能是内核内置功能，模块卸载并不成立。恢复新建连接的默认算法即可。

5. 处理仍在使用 BBR 的连接

回滚默认值后，旧的 BBR连接仍可能继续存在。应优先采用应用层优雅方式回收：

• 让负载均衡暂时摘除节点；
• 等待连接自然排空；
• 优雅重启应用或滚动重建连接池；
• 对长连接服务设置合理的连接轮换时间。

不要直接对全部 TCP连接执行强制终止，也不要使用 kill -9 代替连接排空。强制断连会造成重连风暴，并可能让刚刚回滚的节点再次出现瞬时拥塞。

6. 回滚后验证

回滚完成后，至少持续观察一个完整的短窗口：

sysctl -n net.ipv4.tcp_congestion_control
sysctl -n net.core.default_qdisc
tc qdisc show dev "$IFACE"

ss -s
ip -s link show dev "$IFACE"

同时对比：

• 新连接是否恢复到原有 CUBIC；
• 关键接口错误率是否回落；
• 目标地区 p95/p99是否恢复；
• TCP重传、连接超时和网卡丢包是否停止增长；
• 其他共享该接口的业务是否恢复正常。

如果回滚后新连接恢复，但旧连接仍有异常，应继续通过连接池轮换和优雅排空处理，而不是重复修改内核参数。

变更关闭标准

只有在以下条件同时满足时，才应关闭本次变更：

• canary和后续批次均完成观察；
• BBR模块、默认算法和实际 qdisc状态与目标一致；
• 目标地区的吞吐、延迟和成功率达到预先设定的放行标准；
• TCP重传、网卡丢包、软中断和系统负载没有持续恶化；
• 至少覆盖一个完整业务高峰，长连接业务还应观察连接轮换后的结果；
• 变更文件、原始参数、执行人、时间点和回滚命令已经归档；
• 已明确下一次重启后如何验证 BBR仍然可用。

如果任一关键指标在观察窗口内持续超过回滚阈值，应保持 CUBIC并结束本次尝试，而不是通过继续放大 TCP缓存、修改 MTU或叠加其他参数来掩盖结果。对于海外长 RTT链路，推荐把“分批切换、至少一个高峰观察、明确回滚阈值”作为固定流程；只有在新建连接表现稳定、旧连接完成自然轮换且业务指标持续满足标准后，才将 BBR保留为生产默认值。