北京
CUBIC是Linux默认的拥塞控制算法，它决定了全球大多数TCP和QUIC连接如何探测带宽、在丢包时退避、以及事后恢复。Cloudflare的开源QUIC实现quiche也以CUBIC为默认算法，这意味着相关代码承载着其大量流量的关键路径。
本文讲述一个Bug：CUBIC的拥塞窗口（cwnd）在达到最小值后被永久锁定，再也无法从拥塞崩溃中恢复。
故事始于一项Linux内核改动。该改动旨在让CUBIC符合RFC 9438第4.2-12节描述的"应用受限排除"规则——这是TCP中一个真实问题的修复。然而当这项修复被移植到quiche时，却引发了意外行为。结局是好的：一行近乎优雅的代码打破了这一循环。
拥塞控制算法的核心旋钮是拥塞窗口（cwnd）：发送端对"在途未确认数据量"的上限。更大的cwnd允许每轮往返发送更多数据，更小的cwnd则起到节流作用。所有基于丢包的算法，包括CUBIC，本质上都是一套策略：网络健康时如何扩大cwnd，异常时如何收缩。
这些算法的目标是最大化数据传输，推断网络的"可用带宽"——毕竟没人愿意花钱买1Gbps带宽却只用其中一小部分。基于丢包的算法家族遵循一个基本前提：无丢包时提高发送速率，有丢包时则认为网络容量已满，发送端必须退避。
调查始于一份报告：入口代理集成测试管道出现意外失败。这种不稳定行为出现在特定测试中——CUBIC在连接早期遭遇严重丢包的场景。从拥塞崩溃中恢复是一种罕见状态，却正是拥塞控制算法存在的意义。
大多数测试只验证算法的稳态和增长阶段，极少探测最小cwnd状态下的行为——即连接被"打垮"之后能否重新爬升。这类状态空间的角落Bug在吞吐量仪表盘中不可见，静态审查也发现不了，唯有故意将算法驱动至该状态并观察其恢复能力时才会暴露。
该测试的失败率高达61%。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
