借助 NGINX 实现 QUIC+HTTP/3 对 OpenSSL 的支持

问题：OpenSSL 与 QUIC+HTTP/3 不兼容

即便得到广泛使用，OpenSSL 也没有提供 QUIC 支持所需的 TLS API，于是 OpenSSL 管理委员会决定自行实现完整的 QUIC 堆栈。这项工作是 OpenSSL v3.4 计划中的一项重要工作，但根据 OpenSSL 路线图，不太可能在 2024 年底之前完成。此外，OpenSSL 实现的初始最小可行产物不包含 QUIC API 实现，因此目前尚不明确用户可如何在 OpenSSL 上获得对 HTTP/3 的支持。

QUIC TLS 支持选项

在这种情况下，对于寻求 QUIC TLS 支持以满足 HTTP/3 需求的用户而言，现有两种选择：

OpenSSL QUIC 实现 – 如上所述，OpenSSL 目前正自行实现完整的 QUIC 堆栈。这项开发将所有 QUIC 功能封装到 OpenSSL 实现中，以便 HTTP/3 用户更轻松使用 OpenSSL TLS API，而不必担心无法利用 QUIC 特定功能。

支持 BoringSSL QUIC API 的库 – BoringSSL、quicTLS 及 LibreSSL 等各种 SSL 库（最初都是 OpenSSL 的分支）现在通过实现 BoringSSL QUIC API 提供 QUIC TLS 功能。不过，这些库并未像 OpenSSL 那样得以广泛采用。该选项还需从源代码构建 SSL 库，并将其安装到每台需要 QUIC+HTTP/3 支持的服务器上，这可能不是一个适合每个人的可行方案。也就是说，由于 OpenSSL QUIC TLS 实现尚未准备就绪，因此对于希望使用 HTTP/3 的用户来说，这是目前唯一的选择。

全新解决方案：OpenSSL 兼容层

NGINX 从这些挑战中受到启发，创建了 OpenSSL 兼容层，以简化使用 OpenSSL 的 QUIC+HTTP/3 部署，并帮助避免在生产环境中维护单独的 SSL 库所带来的复杂性。

OpenSSL 兼容层可搭配使用 NGINX 开源版的主线版（从版本 1.25.0 开始） 和 NGINX Plus R30，允许 NGINX 在 OpenSSL 之上运行 QUIC+HTTP/3，而无需对其进行修复或重建。这消除了对编译和部署第三方 TLS 库以获得 QUIC 支持的依赖。由于用户无需使用第三方库，因此也不必依赖这些库的进度表和路线图，这让 OpenSSL 兼容层成为了相对更容易部署到生产环境中的解决方案。

OpenSSL 兼容层的工作原理

OpenSSL 兼容层执行以下步骤：

将 QUIC 握手转换为 OpenSSL 支持的 TLS 1.3 握手。

将 TLS 握手消息传入和传出 OpenSSL。

从 OpenSSL 中获取握手和应用加密级别的加密密钥。

将 QUIC 传输参数传入和传出 OpenSSL。

根据目前 OpenSSL 的采用率及其官方 QUIC+HTTP/3 支持状态，我们相信一个简单、可扩展的 QUIC 启用选项不仅是一大进步，而且还将促进 HTTP/3 的采用，并提供有价值的反馈。最重要的是，我们相信 OpenSSL 兼容层将帮助我们为企业用户和整个 NGINX 社区提供更强大、更具可扩展性的解决方案。

注: 虽然我们通过 OpenSSL 兼容层的可用性确保为 NGINX 用户提供一个简单、可扩展的选项，但用户仍可选择在 NGINX 中使用第三方库，例如 BoringSSL、quicTLS 或 LibreSSL。如需确定最适合自己的方法，请考虑哪种方法最能满足您的需求，以及您对将库作为依赖项进行编译和管理的适应能力。

关于 0-RTT 的说明

0-RTT 是 QUIC 的一项功能，允许客户端在 TLS 握手完成之前发送应用数据。0-RTT 功能通过复用先前连接中的协商参数来实现，具体方法是客户端记住关键参数，并向服务器提供 TLS 会话票据，以便服务器恢复相同信息。

虽然该功能是 QUIC 的重要组成部分，但在 OpenSSL 兼容层中尚不受支持。如有需要使用 0-RTT 的特定用例，欢迎您积极反馈，以便我们制定路线图。

推荐搜索