cURL开始重视 HTTP/3

在 curl 项目中，作者Daniel Stenberg一直以来都为特定协议提供多个可选后端。秉承这一传统，他逐步添加了对多种 HTTP/3 + QUIC 后端的实验性支持。不久前，他又放弃了其中一个实验性支持，即msh3后端。

这两天，Daniel Stenberg进一步清理代码，移除了对另一个后端——OpenSSL-QUIC协议栈的支持。现在curl只支持两种不同的HTTP/3方案：ngtcp2 + nghttp3组合或quiche。后者quiche后端仍处于实验阶段。

第一个包含此更改的版本将是 curl 8.19.0。

关于 OpenSSL-QUIC 协议

这是 OpenSSL 实现并提供的 QUIC 协议栈。需要注意的是，它与 OpenSSL 提供的QUIC API是两个不同的概念。前者是完整的 QUIC 实现，后者则是一个功能强大的 API，允许独立的 QUIC 实现使用 OpenSSL 来满足其加密和 TLS 需求。

2019 年，BoringSSL 为 QUIC 引入了 API。QUIC 的各种实现都采用了该 API，并且运行良好。随后，有人向 OpenSSL 提交了 pull request，请求他们提供相同的 API，以便所有 QUIC 协议栈都能使用 OpenSSL。

2021 年——OpenSSL 最终拒绝合并该拉取请求，并宣布他们将改为实现自己的 QUIC 堆栈——而此前没有人要求过。

2023年——OpenSSL 3.2发布，支持其自身的QUIC协议栈。但它存在诸多问题。

2025年：OpenSSL 3.4.1版本发布，QUIC协议栈运行良好。OpenSSL 3.5.0版本发布了QUIC API，最终允许独立的QUIC协议栈使用OpenSSL。

有代码贡献者为 curl 添加了对 OpenSSL-QUIC 的支持，主要是为了允许使用 OpenSSL 的用户仍然能够使用 HTTP/3。

OpenSSL 自己的 QUIC 实现目前仅在 curl 中为实验阶段，这明确强烈不建议用户在生产环境中使用它，并且保留在版本之间更改功能等内容的权利。

它未能从实验阶段毕业的原因有三点：

API 功能不足。早在 API 发布之前，我们就与 OpenSSL-QUIC 团队沟通过，但它仍然没有提供我们希望拥有的选项和控制功能，使其无法成为具有竞争力的 QUIC 替代方案。
性能很差。Daniel Stenberg说的差是指真的非常差。领先的 QUIC 实现方案 ngtcp2 在所有基准测试和对比中数据传输速度都快得多。有时甚至快三倍。
内存占用情况极其糟糕。与ngtcp2相比，使用OpenSSL-QUIC进行传输所需的内存量可能高达20倍。