目前的狀況
Last updated
Was this helpful?
Last updated
Was this helpful?
QUIC 工作組自 2016 年末以來一直在努力製定協定，在撰寫本文時（ 2020 年 6 月 ）已接近最後階段。
在 2019 年和 2020 年間，使用 HTTP/3 進行互操作性測試的數量不斷增加 [] CDN 和瀏覽器已經開始提供初始的支持 - 儘管它們通常會進度落後。
QUIC 工作組的 Wiki 頁面上有更多的資訊。
實現 QUIC 並不容易，到目前為止，協定本身還在不斷演變中。
NGINX 對 QUIC 和 HTTP/3 的支援正在開發中，並且 .
至於 Apache 對 QUIC 的支援則是還沒有公開的聲明。
尚未有任何主流瀏覽器供應商在任何狀態下提供可以運行 IETF 版本的 QUIC 或 HTTP/3 協定。
多年來，Google 瀏覽器一直在提供 Google 自己的 QUIC 版本，並且最近已經開始支持 IETF 版本。 Firefox 同樣之後會開始支援。
curl 在 2019 年 9 月 11 日發布了 7.66.0 版本中的第一個實驗性的 HTTP/3 支援（draft-22）。 curl 使用 Cloudflare 的 Quiche 或 ngtcp2 來完成工作。
QUIC 決定使用 TLS 1.3 作為加密和安全層的基礎來避免發明新的東西，且依靠可信賴的現有協定。 不過工作組決定大幅精簡 QUIC 中 TLS 的使用，只使用 "TLS訊息"（ TLS Messages ）而不是協定中的 "TLS記錄"（ TLS Records ）。
這聽起來像是一個無害的更改，但實際上已對許多 QUIC 堆疊的實作者造成了重大障礙。 現存的支持 TLS 1.3 的 TLS libraries 都沒有提供此功能的 API 並允許 QUIC 訪問它。 有一些 QUIC 的實作由大型機構完成，這些機構可能有自己的 TLS 堆疊，但並不是所有人都能做到這種地步。
由於 QUIC 堆疊將需要基於其他 TLS libraries，使用單獨的修補 OpenSSL 構建或需要更新到將來的 OpenSSL 版本，這些最終也將導致部署障礙。
Google 和 Facebook 都提到，他們的 QUIC 大規模部署所需的 CPU 數量大約是通過 TLS 提供 HTTP/2 時相同流量負載的兩倍。
進一步的解釋
主要是 Linux 中的 UDP 部分根本沒有像 TCP 堆疊那樣優化，因為傳統上它沒有像這樣被用於高速傳輸。
TCP 和 TLS 有硬體加速（負載卸載到硬體，offload），而這對於 UDP 很罕見，對於 QUIC 則基本上不存在。
就上述理由，我們可以相信 QUIC 的 CPU 使用量能隨著時間得到改善。
例如，占主導地位的開源重量級 OpenSSL 對此沒有任何 API。 解決此問題的計劃可能以在他們的 中，它們計畫一種與 BoringSSL 非常相似的 API。