首页科技快讯都推进到95%了，为什么curl还是放弃基于Rust开发了四年的HTTP后端替代

都推进到95%了，为什么curl还是放弃基于Rust开发了四年的HTTP后端替代

来源：晰数塔互联网快讯时间：2024年12月25日 18:00

整理 | 燕珊

curl 放弃对 Hyper Rust HTTP 后端的支持。

“实验结束了。我们努力了，但还是失败了。”

近日，知名开源项目 curl 的创始人 Daniel Stenberg 正式发文宣布，将放弃对基于 Rust 编写的 Hyper HTTP 后端的支持，并彻底移除相关代码。

“四年前，我们开始在 curl 中添加对另一种 HTTP 后端的支持。它将使用一个基于 Rust 编写的库，名为 Hyper。我们的想法是引入一种替代的 HTTP 内部实现，让 curl/libcurl 使用它来代替本地实现。”Stenberg 在博客中写道。然而，这场实验在历经四年的努力后，以失败告终。

完成 95% 的工作只是开始？

这一尝试始于 2020 年，由 ISRG（Let’s Encrypt 背后组织）资助。当时的目标是通过 Rust 的内存安全特性，为 curl 用户提供一个更安全的 HTTP 后端实现。Stenberg 在早期的博客中写道。“通过 Hyper，我们能够让更多代码运行在内存安全语言中，而非完全依赖 C。”

尽管实验已经推进了一大半，甚至让 Hyper 后端通过了几乎所有测试用例，但如同 Stenberg 在最新的博文中所述，“我们完成了 95% 的开发工作，然而，最后那‘百分之几’的挑战，还是让我们不得不认输，放弃这个实验。”

目前来看，实验失败的两大关键原因如下：

几乎没人有这需求：curl 的用户对 Hyper 没有兴趣；Hyper 的用户也不太关心让它兼容 curl。

缺乏同时精通 C 和 Rust 的开发者来推进：Hyper 是用 Rust 写的，而 libcurl 库（curl 背后的“引擎”）是用 C 写的，需要一个“胶水层”来把它们连接起来。这需要开发者不仅对两种语言精通，还要深入理解它们的架构和协议，但目前没有合适的人去做这件事。

此外，早在 2020 年开始这个实验时，Stenberg 就提到过“Hyper 没有 C API”是一个棘手的挑战。

停滞与反思：Hyper 成为“负担”

在今年 4 月的另一篇推文中，Stenberg 就预示过这次实验的结局，他提出了发人深省的问题：“Hyper 支持是否值得继续？”——当时，Hyper 后端的开发工作已陷入停滞，过去半年内几乎没有人主动对其进行功能改进或优化。与此同时，用户对 Hyper 的需求仍然冷淡。

技术上，Hyper 后端的开发过程中还出现了多次反向调整。例如，例如，由于对 Hyper API 集成方式的理解偏差，而不得不移除对 HTTP/2 的支持，这直接导致无法正确实现 HTTP/2 的功能。

更大的问题在于，社区用户的需求和兴趣严重失衡：当下 Rust 用户更愿意直接使用 Hyper，而不是帮助让它支持 C 项目；而 curl 的现有用户对 Hyper 几乎没有兴趣。

社区中这两类用户的交集太小，已经无法为 Hyper 后端的持续开发提供足够的支撑。

面对多重困难，Stenberg 开始反思：“Hyper 的支持是否已经从一种探索创新的尝试，变成了拖累改进的负担？”显然，继续维护这一功能的成本已经超过了它的实际价值。

既然在短、中期内都看不到完成的希望，与其继续耗费资源，不如果断放弃——移除这部分代码，不仅可以大幅简化项目结构，还能提高整体的灵活性，为 curl 的未来发展留出更多空间。

用其他语言重写 curl？也几乎不可能

或许会有人提问，当初为什么不直接用 Rust 重写 curl 呢？Stenberg 早就明确表示，这从来不在他们的计划之中。

一方面，curl 是一个老牌开源软件，已经运行了 25 年。对于 libcurl 用户来说，稳定的接口（API）、应用二进制接口（ABI）、一致的行为，以及文档中定义的所有功能选项，都是不可动摇的基础。重写代码不仅意味着要重新开发所有功能，还需要确保新版本完全兼容旧版，这对任何项目来说都是一项巨大而复杂的挑战。即使是那些考虑过这样做的大型企业，最终也都放弃了这个想法。

与此同时，Stenberg 等人也深知，curl 必须不断引入新功能，才能跟上技术的发展步伐。于是，Hyper 后端支持方案成为他们探索的方向。

虽然 Hyper 实验以失败告终，但它对 curl 和 Hyper 项目都带来了积极影响。Stenberg 表示，curl 在与 Hyper 集成的过程中，改进了自身对 HTTP 的严格性，并优化了代码结构，而 Hyper 则通过与 curl 的合作获得了宝贵的反馈，进一步提升了自身的稳定性和性能。

他强调：“虽然 Hyper 已被移除，但我们依然对未来引入 Rust 或其他语言的安全后端持开放态度。与 2020 年那会相比，我们现在已经拥有了更好的内部架构可供借鉴。只要用户需求足够明确，并且有足够的资源支持，我们还可能会重新尝试类似的整合。”

尽管 Hyper 被放弃，curl 仍然在推进对两个 Rust 编写的后端的支持：：rustls（用于 TLS）和 quiche（用于 QUIC 和 HTTP/3），它们被认为比 Hyper 更易于维护。

据悉，Hyper 的相关代码已于 2024 年 12 月 21 日从 curl 的代码库中删除，并将在 2025 年 2 月发布的 curl 8.12.0 版本中完全失效。

发布于：辽宁