别盲目切 BBR：用 tc 压测与内核 trace 数据说话，深度扒一扒它和 Cubic 的适用边界

别再无脑吹 BBR 了，大家生产环境公网和跨机房互联到底选哪个？

最近测一波跨地域同步链路（RTT 约 38 ms，随机丢包率约 0.8%），对比了一下默认的 Cubic 和 BBRv1，顺便抓了下连接状态：

# Cubic 节点：ss -ti 抓出来的表现，频繁触发减窗
cubic wscale:7,7 rto:240 rtt:38.2/1.4 cwnd:18 ssthresh:14

# BBR 节点：吞吐是上去了，但排队延迟直接起飞
bbr wscale:7,7 rto:268 rtt:62.5/8.1 rttvar:8.1 cwnd:84 pacing_rate 124.6Mbps minrtt:38.1

用 perf record -e tcp:tcp_probe 采样看得很明显：BBR 确实能顶着轻微丢包跑满带宽，但由于 BBRv1 对浅队列（shallow buffer）极不友好，直接把交换机 buffer 占满，同链路的 Cubic 流量被挤压得几乎断流，自身还带来了严重的 bufferbloat（RTT 从 38 ms 飙到 60+ ms）。

虽然内核 6.x 里 BBRv3 修复了不少 fairness 问题，但毕竟还没正式进主线。

想请教各位：

1. 你们对外暴露的大带宽服务，是全量切 BBR，还是老老实实调大 Cubic 的初始窗口配合 fq？
2. 在内网或专线场景，有人真敢上 BBR 吗？有没有被周期性 PROBE_RTT 引起的延迟抖动坑过？