出品|開源中國

作者|局長

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”，並被關閉。

Daniel 表示，他對此感到失望。OpenSSL 缺少 QUIC API 將會造成阻礙，而 QUIC 堆疊將不得不堅持使用或切換到其他庫。