小米科技|用于 OpenSSL 的 QUIC API 将不会提供手机行业

出品|开源中国

作者|局长
curl 作者 Daniel Stenberg 发布博客称，随着 HTTP/3（基于 QUIC 实现）逐渐普及， QUIC 的 API 缺失问题是一个关键问题。他提到，多年前就实现了许多现有的 QUIC 库，而且它们正在慢慢成熟。 QUIC 协议也成为了 RFC 9000 ，但最流行的 TLS 库仍然没有提供必要的 API 让 QUIC 库可以使用它们。
据介绍，很长时间以来， QUIC 社区的许多成员和项目都在热切地关注 OpenSSL 的 Pull Request 8797 ，该 PR 将必要的 QUIC API 引入了 OpenSSL 。此变更给 OpenSSL 带来了与 BoringSSL 已经提供的相同的 API ，该 API 已经被多个独立实现使用和测试。
不过基于 BoringSSL 的实现有一个问题，因为它是一个没有版本和真正发行版的 TLS 库，所以对大多数人来说它不是一个好的选择。毕竟 OpenSSL 已经是最广泛使用的 TLS 库，并且已经有许多应用程序在使用它。
2020 年 2 月， OpenSSL PR8797 被宣布推迟实现，当时 OpenSSL 管理委员会 (OMC) 表示他们在 3.0.0 版本发布之前不会处理该 PR 。 2021 年 3 月，微软和 Akamai 宣布了 quictls ，这是一个 OpenSSL 分支，其明确的想法是提供 OpenSSL + QUIC API 。他们不想等待 OpenSSL 来完成这件事。
部分 QUIC 库现在已经可以使用 quictls 。 quictls 可以让他们的分支保持最新状态，现在提供了等同于 OpenSSL 3.0.0 + QUIC API 的实现。
与此同时，许多人仍在一直在等待 OpenSSL 采用 API 。
10 月 13 日， OpenSSL OMC 宣布：

下一个版本的重点是 QUIC ，目标是在一系列版本 (2-3) 上提供功能齐全的 QUIC 实现。

由此可见， OpenSSL 已经决定自己实现一个完整的 QUIC 堆栈，并且按照给定的时间线，听起来他们需要几年 (?) 才能发布。并且没有提供许多实现者已经等待这么久的 API：

MVP 将不包含用于 HTTP/3 实现的库 API 。

Daniel 表示，他没有编写自己的 QUIC 实现，但非常密切地跟踪了几个实现的工作，这些开发者为自己制定了相当复杂的安排——原因不清楚。他认为现在已经存在多个高质量的 QUIC 库，为什么 OpenSSL 认为他们还需要自己制作另一个？
2021 年 10 月 20 日，于 2019 年 4 月创建的OpenSSL Pull Request 8797 最终被标记为\"wont fix\" ，并被关闭。

【小米科技|用于 OpenSSL 的 QUIC API 将不会提供】Daniel 表示，他对此感到失望。 OpenSSL 缺少 QUIC API 将会造成阻碍，而QUIC 堆栈将不得不坚持使用或切换到其他库。