去年的這個時候，國內的 web 網路環境開始普及和部署 HTTP/2. 時隔一年，HTTP/2 的普及程度有了顯著提升，而各大CDN廠商普及的廣度和速度一直走在行業前列。甚至有不少CDN廠商在直播以及部分HTTP場景還引入了 QUIC.

在拙文《當我們在談論HTTP隊頭阻塞時，我們在談論什麼？》中，我們提到，HTTP/2 over QUIC 是當前唯一應用落地解決了傳輸層隊頭阻塞問題的HTTP實現。那個時候，無論是 HTTP/2 over TCP 還是 HTTP/2 over QUIC(UDP) 都被我們認為是 HTTP/2，只是傳輸層使用的協議不一樣。這種略帶曖昧的模糊叫法在2018年11月成為了歷史：

在2018年10月28日的郵件列表討論中，互聯網工程任務組（IETF） HTTP和QUIC工作組主席Mark Nottingham提出了將HTTP-over-QUIC更名為HTTP/3的正式請求，以「明確地將其標識為HTTP語義的另一個綁定……使人們理解它與QUIC的不同」，並在最終確定並發布草案後，將QUIC工作組繼承到HTTP工作組。在隨後的幾天討論中，Mark Nottingham的提議得到了IETF成員的接受，他們在2018年11月給出了官方批准，認可HTTP-over-QUIC成為HTTP/3。

雖然看起來像是之前的 HTTP/2 over QUIC 換了一個名稱（從我個人角度理解，取名為 HTTP/2.1也許更合適），但是其背後卻體現了 IETF 對 HTTP 未來標準的態度和方向，也許幾年以後來看這次名稱的確立會更加明白其重要意義。

HTTP/3 與 HTTP/2 over QUIC 的區別

QUIC 將成為一個通用安全傳輸層協議

當前階段，Google 實現的 QUIC 與 IETF 實現的 QUIC 是不兼容的。Google 版 QUIC 只能用於 HTTP/2，且在協議層面與 HTTP/2 有一些強綁定。如 QUIC 幀映射 HTTP/2 frame. 這就導致很多大廠都沒有跟進 QUIC，使得 HTTP/2 over QUIC 基本只能在 Google 自家的 Chrome, Gmail 等軟體中普及使用，一度給行業造成「只有Google在弄」的錯覺。

納入 IETF 以後，顯然 Google 就不能這麼玩了。QUIC 定位為一個通用安全傳輸層協議：

可以近似的認為 QUIC over UDP 將成為下一代（或替代）TLS over TCP. 也就是說， QUIC 將能應用於任何應用層協議中，只是當前階段將優先在 HTTP 中進行應用和驗證。

統一使用 TLS 1.3 作為安全協議

2018年，有幾個重要的WEB標準終於塵埃落定，其中一個便是 RFC 8446 TLS 1.3. 這個標準對於降低延遲，改善用戶體驗，尤其是移動端的體驗有非常重要的意義。在拙文《TLS1.3/QUIC 是怎樣做到 0-RTT 的》中，我們提到 雖然 TLS 1.3和 QUIC 都能做到 0-RTT，從而降低延遲，但是 QUIC 卻自顧自地實現了一套安全協議。主要是因為當時 TLS 1.3 標準還沒有發布，而 QUIC 又需要一套安全協議：

The QUIC crypto protocol is the part of QUIC that provides transport security to a connection. The QUIC crypto protocol is destined to die. It will be replaced by TLS 1.3 in the future, but QUIC needed a crypto protocol before TLS 1.3 was even started.

如今，TLS 1.3 標準已經發布，而 HTTP/3 也納入 IETF，因此 QUIC 也就順理成章的使用 TLS 1.3 作為其安全協議。Google 在這些方面倒是從來都不雞賊和墨跡，點贊。

使用 QHPACK 頭部壓縮代替 HPACK

其實，QPACK與HPACK的設計非常類似，單獨提出QPACK主要是更好的適配QUIC，同時也是 Google 將 QUIC 從與 HTTP/2 的耦合中抽離出來，與 IETF 標準完成統一的必要一步。

HTTP/3 問題與挑戰

UDP 連通性問題

幾乎所有的電信運營商都會「歧視」 UDP 數據包，原因也很容易理解，畢竟歷史上幾次臭名昭著的 DDoS 攻擊都是基於 UDP 的。國內某城寬頻在某些區域更是直接禁止了非53埠的UDP數據包，而其他運營商及IDC即使沒有封禁UDP，也是對UDP進行嚴格限流的。這點上不太樂觀，但是我們相信隨著標準的普及和推廣落地，運營商會逐步改變對UDP流量的歧視策略。國外的情況會稍好一些，根據Google的數據，他們部署的QUIC降級的比例不到10%。

QUIC 不支持明文傳輸

對於用戶來說，這是一個優勢，並不是問題。對於國內內容審查環境來說是個不可忽視的坎。但QUIC以後畢竟也是基於TLS協議的，國內HTTPS都能普及下來，QUIC的普及也許會更樂觀一些。

UDP 消耗資源多

當前階段，UDP消耗的CPU資源多，且處理速度慢。這是不爭的事實，但是我相信隨著UDP應用的增多，內核和硬體的優化一定會跟上，直至達到或超過TCP的性能。而 QUIC 因為實在應用層實現，因此迭代速度更快，部署和更新難度和代價更小，能夠一定程度緩解如TCP那樣的協議僵化問題。

進一步瞭解 HTTP/3

如果希望全面的瞭解 HTTP/3，推薦 Daniel Stenberg （CURL 作者）的 HTTP/3 explained, 如果不想看英文，可以翻閱 Yi Bai 同學翻譯了中文版本HTTP/3詳解。


推薦閱讀：
相關文章