Linux内核针对CUBIC拥塞控制算法的优化修复了TCP问题，但在移植到QUIC协议时却导致了一个严重缺陷：拥塞窗口被永久固定在最小值而无法恢复。Cloudflare团队最终解决了这个意外引发的QUIC"死亡螺旋"问题。

标题：当"空闲"并非空闲：Linux内核优化如何引发QUIC故障

来源：Cloudflare技术博客 发布时间：2026年5月12日

主要内容概述：

1. 问题背景

• CUBIC作为Linux默认拥塞控制算法（RFC 9438），管理着大多数TCP和QUIC连接的带宽探测行为
• Cloudflare开源QUIC实现quiche使用CUBIC作为默认拥塞控制器
• 发现一个严重bug：CUBIC的拥塞窗口(cwnd)在达到最小值后会永久停滞

2. 故障现象

• 在模拟30%丢包率的测试环境中，61%的测试用例无法在10秒内完成10MB文件下载
• 虽然2秒后丢包停止，但cwnd始终维持在最小值（2700字节/2个数据包）
• 每14ms（接近RTT时间）就会在拥塞避免和恢复状态间振荡切换

3. 根本原因

• 源自2017年Linux内核针对CUBIC空闲期的优化补丁
• QUIC实现移植该优化时存在缺陷：错误地将RTT时间误判为空闲时间
• 当cwnd达到最小值时形成"死亡螺旋"： a) 每个ACK周期触发虚假空闲检测 b) 错误计算的时间差导致恢复时间不断被推后 c) 拥塞控制器持续认为处于恢复期，拒绝增大cwnd

4. 解决方案

• 关键修复：准确测量真实空闲时间（从最后一个ACK到达开始计算）
• 仅需修改3行核心逻辑代码
• 修复后测试通过率恢复100%，下载时间降至4-5秒

5. 经验总结

• "空闲"状态的定义在极小cwnd情况下需要特殊处理
• 该bug只在严重丢包后的极端情况下显现
• 体现了拥塞控制算法在边界条件下的脆弱性

技术价值： - 揭示了QUIC与TCP在拥塞控制实现上的微妙差异 - 展示了开源实现如何通过持续测试发现并修复复杂问题 - 为CC算法在极端条件下的行为分析提供了典型案例

（注：原文中的图片链接、代码片段和详细时间线等技术细节在此摘要中已作简化处理，保留了核心问题描述和解决方案的要点）

总结评论内容：

1. 代码抄袭与理解不足的批评（评论1）

• 主要观点：认为文章标题应更准确地反映"抄袭Linux内核代码但未完全理解，导致错过后续修复"的事实
• 关键引用： "The more precise title should be: How we copied code from Linux kernel without fully understand it and missed its follow-up fixes" "现在它反噬我们了(now it bites us)"

2. 自主实现的优缺点讨论（评论2）

• 主要观点：理解改用Rust重写QUIC的动机，但指出自主实现需要密切关注内核更新
• 关键引用： "这些自主实现通常比内核获得更少的关注(These in-house implementations tend to have less eyeballs)" "对Cloudflare尚未采用BBR作为默认感到有趣(found it interesting that Cloudflare is not yet using BBR)"

3. 文章结构质疑（评论3）

• 主要观点：怀疑文章结构可能由AI生成
• 关键引用： "文章结构和副标题感觉很像AI(the article structure and subtitles feel very AI)"

4. 技术参数优化建议（评论4）

• 主要观点：建议根据连续退避情况动态调整退避参数
• 关键引用： "如果退避快速连续发生，降低退避幅度和增长速度是否更合理？(Wouldn't it make sense to reduce the backoff...)" "我们需要最大化曲线下面积(transmitted packages)"

5. 术语定义缺失批评（评论5）

• 主要观点：指出文章未明确定义关键术语"CCA"
• 关键引用： "文章使用'CCA'术语却从未定义(The article uses the term 'CCAs' without ever defining it)" "在这个上下文中CCA是什么？(What is a CCA in this context)"