rustls的十年历程

# rustls：十年探索之路 来源：https://rustls.dev/blog/2026-09-08-a-decade-of-rustls/ **2026-09-08** —— Joe Birr-Pixton 今年标志着 rustls 项目十周年。在本文中，我们将回顾这十年历程：项目的起点、发展历程以及未来方向。本文内容基于我们在 RustConf 2026 上的演讲整理而成。 ## 早期岁月 rustls 的第一个提交记录 (https://github.com/rustls/rustls/commit/4460bbe15b4df1f6e6efea4f9f06fbd0fb278077) 提交于 2016 年 5 月 2 日。项目进展迅速：一个月后的 6 月 5 日，它已能与网络上大多数网站互通。首个版本 0.1.0 于 2016 年 8 月 27 日发布——距离首次提交仅不到四个月。 早期项目获得了来自 @briansmith (https://github.com/briansmith) 和 @djc (http://github.com/djc) 的重要外部贡献。2018 年，@djc (http://github.com/djc) 与 @Ralith (https://github.com/ralith) 在开发 Quinn (https://github.com/quinn-rs/quinn) 期间为 rustls 贡献了 QUIC 支持，这是首次由外部贡献的重要功能。2021 年，@djc (http://github.com/djc) 成为首位联合维护者，@cpu (http://github/cpu) 于 2023 年加入维护团队。 2018 至 2020 年间，@djc 致力于推动第三方审计 (https://jbp.io/2020/06/14/rustls-audit/)，该项目由 CNCF 根据 Buoyant.io (https://buoyant.io/) 的请求资助，并由 Cure53 完成审计。2021 年，项目迎来了首次有偿贡献：@djc 通过 ISRG 的 Prossimo (https://www.memorysafety.org/initiative/rustls/) 倡议签订合同，专注于提升代码健壮性。此后，Prossimo 资助了包括 @cpu、@djc 及本人在内的多位开发者，大幅提升开发节奏与深度。该资助支持我们交付了重要功能——可插拔加密提供者、`no_std` 支持、FIPS 认证、后量子密钥交换与 Encrypted ClientHello，同时也催生了 rustls-platform-verifier (https://github.com/rustls/rustls-platform-verifier) 和 OpenSSL 兼容层 (https://github.com/rustls/rustls-openssl-compat) 等关联项目。 ## 迈向 0.23 的发布历程 从 0.1.0 版本开始，项目在随后八年间经历了一系列版本迭代，持续完善功能、加固安全并优化 API 设计。这一系列发布最终汇聚于 2024 年 2 月 29 日发布的 0.23 版本。 rustls 主要版本及 0.23 次要版本演进时间线示意图 ## 0.23 系列：稳定与功能演进 0.23 系列是稳定版本线：自发布以来，已完成 43 次非破坏性更新。这种稳定并未伴随停滞——0.23 系列推出了众多重要功能，包括 FIPS 认证加密选项、证书压缩、Encrypted ClientHello、后量子密码学以及性能优化。 ## 现状：0.24 版本 下一个破坏性更新版本将是 0.24。它带来了多项改进，包括： - 外部缓冲机制，提升批量数据处理性能 - 初步支持异步友好用法 - "分离模式" - 全新的 `CryptoProvider` 选择机制 ### 外部缓冲与批量数据性能 在早期版本中，所有数据通过 `std::io` 特性传输，存在额外拷贝、错误处理繁琐、不支持 `no_std`、缺乏半关闭控制及缓冲区尺寸管控不足等问题。在 0.24 版本中，缓冲机制移出 rustls 核心：所有 TLS 输入通过新特性 `TlsInputBuffer` 传入，所有 TLS 输出追加至用户提供的 `&mut Vec`。传入的明文将就地解密，并以输入缓冲区的借用形式返回，避免数据拷贝。 提供了两种 `TlsInputBuffer` 实现：`SliceInput` 与 `VecInput`。其中 `VecInput` 可从 `io::Read` 读取数据，延续了原有用法路径，便于迁移。 ### 异步友好用法 过去我们一直等待 Rust 语言发展（异步动态特性与 "async 关键字泛型"）成熟后再直接支持异步场景。0.24 版本不再等待：引入会话类型系统对握手过程进行建模。 - 服务端流程：`NeedsInput` → `Accepted` → `VerifyClientIdentity` → `Complete` - 客户端流程：`NeedsInput` → `VerifyServerIdentity` → `Complete` 每个步骤均可通过异步、阻塞或完成式风格驱动，未来可通过非破坏性更新扩展更多步骤。这取代并完善了 0.23 版本中的 `Acceptor` API。 ### 分离模式 此前单个 `Connection` 对象同时负责数据发送与接收。在 0.24 中，握手后的收发操作由独立对象处理：`SendTraffic` 与 `ReceiveTraffic`。二者均实现 `Send` 特性，可跨线程使用，使全双工工作负载吞吐量可提升一倍。两个对象通过低竞争的内部反向通道通信。 分离模式组件框图：左侧展示接收端状态机，右侧展示发送端状态。 这是 2019 年首次提出的功能，我们相信这是 TLS 库中的独特设计。期待应用开发者利用此特性将 TLS 性能推向新高度。 ### CryptoProvider 选择机制 rustls 使用的所有密码学功能均通过 `CryptoProvider` 提供。在 0.23 中，两种内置提供者通过 crate 特性选择。在 0.24 中，提供者分离为独立 crate（如 `rustls-aws-lc-rs` 和 `rustls-ring`），主 `rustls` crate 不再包含选择提供者的特性标记。全局提供者的配置现在需在 `main()` 顶部的其他位置完成，由此消除了特性统一化导致的 panic 问题。 ## 未来展望 0.24 发布后将经历一段时间的稳定化周期，以排查潜在问题并为生态系统提供适配时间。此后将推进至 1.0 版本，我们希望构建可长期维护的稳定 API。