Edgecast 发现 BBR 并非全场景优于 CUBIC，小文件、低 RTT 回源链路反而劣化，遂构建 xTCP 采集全量 socket 指标，配合 Kafka+ClickHouse 实时判断何时启用 BBR，实现多租户 CDN 的动态拥塞控制切换。
**BBR 适用边界的实测结论：**
早期评估显示，BBR 对小文件（<100KB）吞吐量几乎无提升；在低 RTT 且重传极少的流上，BBR 表现反而不如 CUBIC。收益仅出现在面向客户端的流量，而内部回源连接（低 RTT、可忽略重传）继续沿用 CUBIC 更优。由于多租户环境下为某客户开启 BBR 可能损害其他客户性能，全网统一开启风险不可控，因此必须按流特征动态决策。
**xTCP 大规模采集与实时判断链路：**
机制建立在 xTCP 之上，从所有边缘缓存节点的 Linux 内核 tcp_info 结构通过 netlink 抽取 socket 级性能数据，经 Kafka 以 protobuf 格式流入 ClickHouse 集群。相比 Google M-Lab 的 tcp-info 工具，xTCP 针对边缘节点海量并发 socket 做了采集优化，并支持 protobuf 导出。该管道已用于 IPv6 初始拥塞窗口调优的效果监控，计划近期开源。
**多租户场景下的动态开关策略：**
ClickHouse 提供秒级聚合查询能力，系统据此实时评估每条连接的 RTT、重传率、文件大小等特征，仅在判定 BBR 有增益时为该租户/流动态启用，其余保持 CUBIC。原文未给出具体判定阈值与切换延迟数据，但架构已在生产环境跑通，避免了“全网一刀切”导致的回源性能倒退。
对运维而言，xTCP 把内核 tcp_info 变成可查询的时序数据，配合 ClickHouse 秒级聚合，让拥塞控制从“全网统一”变成“按流特征按租户动态下发”，避免了盲目开启 BBR 导致的回源性能倒退，也为后续 IPv6 初始窗口等内核参数调优提供了同一套观测基座。
原文: APNIC Blog（2022-01-24）｜编译自 APNIC Blog，事实以原文为准。
来源：APNIC Blog