A decade of rustls / Rustls 十周年

A Decade of Rustls 2026-09-08 — Joe Birr-Pixton Rustls 十周年 2026年9月8日 — Joe Birr-Pixton

This year marks ten years of Rustls. In this post, we reflect on a decade of the project: where it started, how it has grown, and where it’s heading next. This post is based on our presentation at RustConf 2026. 今年是 Rustls 诞生十周年。在这篇文章中，我们将回顾该项目走过的十年历程：它从何处起步，如何成长，以及未来的发展方向。本文基于我们在 RustConf 2026 上的演讲。

The early days / 早期阶段

Rustls began with a first commit on May 2, 2016. Progress was quick: a month later, on June 5, it could interoperate with most sites on the web. The first release, 0.1.0, followed on August 27, 2016 – less than four months after the first commit. Rustls 的第一次提交始于 2016 年 5 月 2 日。进展非常迅速：一个月后的 6 月 5 日，它就已经能够与网络上的大多数站点进行互操作。第一个版本 0.1.0 于 2016 年 8 月 27 日发布，距离首次提交不到四个月。

Early on, there were significant external contributions from @briansmith and @djc. In 2018 @djc and @Ralith contributed QUIC support to rustls during the development of Quinn; this was the first outside contribution of a significant feature. In 2021 @djc became the first co-maintainer, and was joined by @cpu in 2023. 在早期，@briansmith 和 @djc 做出了重要的外部贡献。2018 年，在 Quinn 的开发过程中，@djc 和 @Ralith 为 rustls 贡献了 QUIC 支持；这是第一个重大的外部功能贡献。2021 年，@djc 成为第一位共同维护者，随后 @cpu 于 2023 年加入。

Between 2018 and 2020 @djc worked towards arranging a third-party audit which was funded by CNCF at the request of Buoyant.io and completed by Cure53. In 2021 the project had its first paid contributions, where @djc was under contract with ISRG via their Prossimo initiative to work on robustness. Later on, Prossimo funded myself, @cpu, @djc and others to dramatically improve the pace and depth of development. That funding helped us deliver significant features — pluggable cryptography providers, no_std support, FIPS certification, post-quantum key exchange and Encrypted ClientHello — as well as sibling projects like rustls-platform-verifier and the OpenSSL compatibility layer. 在 2018 年至 2020 年间，@djc 致力于安排第三方审计，该审计由 CNCF 应 Buoyant.io 的请求资助，并由 Cure53 完成。2021 年，该项目迎来了首次付费贡献，当时 @djc 通过 ISRG 的 Prossimo 计划签约，致力于提升项目的健壮性。后来，Prossimo 资助了我和 @cpu、@djc 等人，极大地提高了开发的进度和深度。这些资金帮助我们交付了重要的功能——可插拔的加密提供程序、no_std 支持、FIPS 认证、后量子密钥交换和加密客户端问候（Encrypted ClientHello）——以及诸如 rustls-platform-verifier 和 OpenSSL 兼容层等姊妹项目。

Releases up to 0.23 / 0.23 之前的版本

From the 0.1.0 release, the project moved through a long series of releases over the following eight years, building out functionality, hardening and refining the API. That sequence of release lines culminated in 0.23, released on February 29, 2024. 从 0.1.0 版本开始，该项目在随后的八年里经历了一系列漫长的版本迭代，不断构建功能、加固并完善 API。这一系列发布线最终在 2024 年 2 月 29 日发布的 0.23 版本达到了顶峰。

The 0.23 line: stability and features / 0.23 版本线：稳定与功能

The 0.23 release line has been a stable one: in the time since, it has seen 43 non-breaking releases. That stability didn’t come with stagnation. The 0.23 line delivered a wide range of important features, including a FIPS-certified cryptography option, certificate compression, Encrypted ClientHello, post-quantum cryptography, and performance improvements. 0.23 版本线非常稳定：自发布以来，它已经经历了 43 次非破坏性更新。这种稳定性并没有带来停滞。0.23 版本线交付了广泛的重要功能，包括 FIPS 认证的加密选项、证书压缩、加密客户端问候、后量子密码学以及性能改进。

The present: 0.24 / 当前：0.24 版本

The next breaking release is 0.24. It brings many improvements, amongst them: External buffering, improving bulk data performance; Some support for async-friendly usage; “Split mode”; New arrangements for choosing a CryptoProvider. 下一个破坏性更新版本是 0.24。它带来了许多改进，其中包括：外部缓冲以提升批量数据性能；对异步友好用法的初步支持；“拆分模式”（Split mode）；以及选择 CryptoProvider 的新机制。

External buffering and bulk data performance / 外部缓冲与批量数据性能

In earlier releases, all data passed through std::io traits. This had a number of drawbacks: extra copies, awkward error handling, no no-std support, no half-close, and poor control over buffer sizes. In 0.24, buffering moves outside Rustls. All TLS input arrives through a new trait, TlsInputBuffer, and all TLS output is appended to a user-provided &mut Vec. Incoming plaintext is decrypted in place and returned as a borrow into the input buffer, avoiding copies. Two implementations of TlsInputBuffer are provided: SliceInput and VecInput. VecInput can read from an io::Read, as before, giving a route to easy porting. 在早期版本中，所有数据都通过 std::io 特征传递。这有许多缺点：额外的拷贝、笨拙的错误处理、不支持 no-std、不支持半关闭（half-close），以及对缓冲区大小的控制较差。在 0.24 中，缓冲移到了 Rustls 之外。所有 TLS 输入都通过一个新的特征 TlsInputBuffer 到达，所有 TLS 输出都追加到用户提供的 &mut Vec 中。传入的明文在原地解密，并作为输入缓冲区的借用返回，从而避免了拷贝。提供了两种 TlsInputBuffer 的实现：SliceInput 和 VecInput。VecInput 可以像以前一样从 io::Read 读取，为轻松移植提供了途径。

Async-friendly usage / 异步友好用法

For some time, we’ve been waiting on Rust language developments — async dyn traits and “async keyword generics” — before addressing async usage directly. Rather than wait longer, 0.24 introduces a system of session types that model the steps of the handshake process. Servers move through NeedsInput → Accepted → VerifyClientIdentity → Complete; clients move through NeedsInput → VerifyServerIdentity → Complete. Each step can be driven in async, blocking, or completion-based style. More steps can be added in the future in non-breaking changes. This replaces, and builds on, the Acceptor API seen in 0.23. 有一段时间，我们一直在等待 Rust 语言的发展——异步动态特征（async dyn traits）和“异步关键字泛型”（async keyword generics）——然后再直接处理异步用法。与其继续等待，0.24 引入了一套会话类型系统，用于模拟握手过程的步骤。服务器的状态流转为：NeedsInput → Accepted → VerifyClientIdentity → Complete；客户端的状态流转为：NeedsInput → VerifyServerIdentity → Complete。每个步骤都可以以异步、阻塞或基于完成的方式驱动。未来可以通过非破坏性更改添加更多步骤。这取代并构建在 0.23 中的 Acceptor API 之上。

Split mode / 拆分模式

Previously, a single Connection object was responsible for both sending and receiving data. In 0.24, post-handshake sending and receiving are handled by separate objects: SendTraffic and ReceiveTraffic. Both are Send, so they can be used on different threads. This means full-duplex workloads can now double their throughput. The two objects communicate through an internal back-channel with very low contention. This is a feature first requested in 2019, and one we think is unique in TLS libraries. It will be exciting to see applications make use of this to take their TLS performance to the next level. 以前，单个 Connection 对象负责发送和接收数据。在 0.24 中，握手后的发送和接收由独立的对象处理：SendTraffic 和 ReceiveTraffic。两者都实现了 Send，因此可以在不同的线程上使用。这意味着全双工工作负载现在的吞吐量可以翻倍。这两个对象通过一个低竞争的内部反向通道进行通信。这是 2019 年首次提出的功能，我们认为它在 TLS 库中是独一无二的。很高兴看到应用程序利用这一点将它们的 TLS 性能提升到一个新的水平。

Choosing a CryptoProvider / 选择 CryptoProvider

All cryptography used by Rustls comes via a CryptoProvider. In 0.23, two providers were built-in and could be chosen by crate features. In 0.24, providers are separate crates, such as rustls-aws-lc-rs and rustls-ring, and the main rustls crate no longer has crate features for selecting a provider. Choosing a global provider at the top of main() now happens elsewhere. As a result, there are no more panics related to feature unification. Rustls 使用的所有加密技术都来自 CryptoProvider。在 0.23 中，内置了两个提供程序，可以通过 crate 特性进行选择。在 0.24 中，提供程序是独立的 crate，例如 rustls-aws-lc-rs 和 rustls-ring，主要的 rustls crate 不再包含用于选择提供程序的 crate 特性。在 main() 顶部选择全局提供程序的操作现在在其他地方进行。因此，不再会出现与特性统一（feature unification）相关的 panic。

The future / 未来

After 0.24 is released, it will be baked for a little while to shake out any issues and give the ecosystem time to adapt. Then 1.0 will follow, and we want this to be a stable API that we can maintain long-term. 0.24 发布后，它将经过一段时间的沉淀，以消除任何问题并给生态系统适应的时间。随后将发布 1.0 版本，我们希望它能成为一个我们可以长期维护的稳定 API。