您现在的位置是：首页 > 文章详情

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

日期：2024-06-12点击：124收藏

原文作者：Prabhat Dixit of F5

原文链接：借助 NGINX 实现 QUIC+HTTP/3 对 OpenSSL 的支持

转载来源：NGINX 中文官网

NGINX 唯一中文官方社区，尽在 nginx.org.cn

开发人员通常希望使用已发布的官方支持库来构建应用和基础架构。即使有了 HTTP/3，他们也非常需要一个既能支持 QUIC 而又不会增加生产基础架构维护成本或操作复杂性的便捷库。

对于许多 QUIC+HTTP/3 用户而言，默认的加密库是 OpenSSL。OpenSSL 默认安装在大多数基于 Linux 的操作系统上，堪称首屈一指的传输层安全（TLS）库，已被大多数网络应用广泛使用。

问题：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。如需确定最适合自己的方法，请考虑哪种方法最能满足您的需求，以及您对将库作为依赖项进行编译和管理的适应能力。