Cloudflare Identifies Race Condition in hyper’s HTTP/1 Implementation

Cloudflare 发现 hyper HTTP/1 实现中的竞态条件 - InfoQ

InfoQ 首页 News Cloudflare 发现 hyper HTTP/1 实现中的竞态条件

开发

为高风险事件响应构建 AI Agent 评估（8月6日网络研讨会）

Cloudflare 发现 hyper HTTP/1 实现中的竞态条件

2026年7月12日 3分钟阅读

作者

• Renato Losio

#### 关注我们

Youtube

232K 粉丝

Linkedin

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 点赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

喜欢

新下拉阅读列表

• 阅读列表

Cloudflare 最近记录了其开发团队如何发现并修复了广泛使用的 Rust HTTP 库 hyper 中的一个罕见错误，该错误可能导致在返回成功的 200 OK 状态时静默截断大 HTTP 响应。该问题已存在多年，仅在特定时间条件下触发，现已在上游修复，引发了 Rust 开发者对此次事件及 Cloudflare 处理方式的讨论。

该错误在 Cloudflare Images 重新设计其 Workers Images 绑定时浮现。部署后，一些大型图像转换请求在报告 HTTP 200 成功时偶尔会返回截断的数据。

在技术分析中，团队澄清了他们如何隔离根本原因并概述了修复路径。Cloudflare 产品经理 Deanna Lam、Cloudflare 高级系统工程师 Diretnan Domnan 和 Cloudflare 高级系统工程师 Matt Lewis 总结道：

我们花了六周时间追踪一个几乎隐形的错误——一个仅在特定条件下发生的竞态条件——该错误影响了 Images 绑定向客户端返回处理后的图像数据的方式。最终，仅需四行代码即可修复它。

Rust hyper 库是一个实现 HTTP 协议的低级网络库，为许多高级 Rust 网络框架和应用程序提供核心客户端和服务器功能。它由 Sean McArthur 于 2014 年启动，采用宽松的 MIT 许可证发布。

在客户开始报告图像截断问题后，团队注意到响应返回了 HTTP 200 和预期的 Content-Length，但在一种情况下仅传输了预期 3.3 MB 中的 200 KB，使得截断的源头难以识别。

团队通过构建可靠的复现环境、跨 hyper 版本和环境进行测试、对每个服务进行仪器化，并使用分布式追踪逐步排除可能原因，系统地隔离了请求路径中的每个组件，最终将问题范围缩小到 Images 服务的 HTTP 响应路径。

应用层追踪和日志未显示错误，但低级内核系统调用追踪（strace）显示 hyper 在缓冲响应数据完全传输前过早关闭了连接，确认了这是一个依赖时间的竞态条件。

Cloudflare 将该错误追溯到 hyper 的 HTTP/1 调度循环中，该循环错误地忽略了不完整的缓冲区刷新，并在连接过早关闭时导致缓冲的响应数据在罕见的时序条件下丢失。为修复该错误，团队添加了一个能够复现竞态条件的确定性测试，并修改 Hyper 以确保在关闭连接前完全刷新缓冲数据。Lam、Domnan 和 Lewis 补充道：

我们的突破来自于使用内核级工具 strace，这是唯一能够记录套接字上实际发生情况的层级。底层错误存在于部分刷新和过早关闭之间的几毫秒时间窗口中——这个窗口只有在我们让系统变快之后才显现出来。

在 Reddit 上，Rust 编译器贡献者 Martin Nordholts 评论道：

这是异步 Rust 的一个已知设计缺陷。在同步 Rust 中，如果代码能编译，通常就能正常工作。但在异步 Rust 中，情况并非如此。导致这一问题的一个因素是静默取消。本文就是这类错误可能引发的一个例子。

Jim Fuller 在强调 Cloudflare 并未资助 hyper 和其他基础 Rust 库维护者 Sean McArthur 时写道：

另一家年收入达 20 亿美元但似乎并未直接支持关键营收路径开发者的企业撰写了这篇精彩的分析文章。

在 Hacker News 上的热门讨论中，一些实践者关注 Rust 代码：

这个问题本应被 Clippy 的 let_underscore_untyped 或 let_underscore_must_use 检查规则标记出来，可惜这些规则默认并未启用。

其他人则质疑 Cloudflare 的监控机制：

Cloudflare 直到客户投诉才注意到他们大规模发送了损坏的响应？我本以为他们可以通过抽样和检查部分响应就能发现这个问题。

修复方案及配套测试已合并到 hyper 项目中，将在未来版本中发布，从而防止响应截断错误的发生。

关于作者

作者信息

#### Renato Losio

显示更多

显示更少

#### 本内容属于开源主题

##### 相关主题：

• 开发
• DevOps
• 调试
• Rust
• 并发
• 开源
• HTTP
• Cloudflare
• 相关编辑
• 相关赞助商 警报疲劳正在影响你：生产可靠性与 AI 采用现状

• 相关赞助商 在完全配置的环境中探索 NeuBird AI 玩具，连接实时 AWS 监控数据。尝试你的第一个查询！

InfoQ 新闻letter

每周五发送 InfoQ 最新内容摘要，每周二发送。加入超过 25 万名高级开发者的社区。查看示例

我们保护您的隐私。