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

都推进到95%了,为什么curl还是放弃基于Rust开发了四年的HTTP后端替代
2024年12月25日 13:29 InfoQ

整理 | 燕珊

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 版本中完全失效。

财经自媒体联盟更多自媒体作者

新浪首页 语音播报 相关新闻 返回顶部