HTTP 2還沒上手,HTTP 3已經(jīng)箭在弦上
去年的這個時候,國內(nèi)的 web 網(wǎng)絡環(huán)境開始普及和部署 HTTP/2. 時隔一年,HTTP/2 的普及程度有了顯著提升,而各大CDN廠商普及的廣度和速度一直走在行業(yè)前列。甚至有不少CDN廠商在直播以及部分HTTP場景還引入了 QUIC.
HTTP/2 over QUIC 是當前應用落地解決了傳輸層隊頭阻塞問題的HTTP實現(xiàn)。那個時候,無論是 HTTP/2 over TCP 還是 HTTP/2 over QUIC(UDP) 都被我們認為是 HTTP/2,只是傳輸層使用的協(xié)議不一樣。這種略帶曖昧的模糊叫法在2018年11月成為了歷史:
在2018年10月28日的郵件列表討論中,互聯(lián)網(wǎng)工程任務組(IETF) HTTP和QUIC工作組主席Mark Nottingham提出了將HTTP-over-QUIC更名為HTTP/3的正式請求,以“明確地將其標識為HTTP語義的另一個綁定……使人們理解它與QUIC的不同”,并在最終確定并發(fā)布草案后,將QUIC工作組繼承到HTTP工作組。在隨后的幾天討論中,Mark Nottingham的提議得到了IETF成員的接受,他們在2018年11月給出了官方批準,認可HTTP-over-QUIC成為HTTP/3。
雖然看起來像是之前的 HTTP/2 over QUIC 換了一個名稱(從我個人角度理解,取名為 HTTP/2.1也許更合適),但是其背后卻體現(xiàn)了 IETF 對 HTTP 未來標準的態(tài)度和方向,也許幾年以后來看這次名稱的確立會更加明白其重要意義。
HTTP/3 與 HTTP/2 over QUIC 的區(qū)別
QUIC 將成為一個通用安全傳輸層協(xié)議
當前階段,Google 實現(xiàn)的 QUIC 與 IETF 實現(xiàn)的 QUIC 是不兼容的。Google 版 QUIC 只能用于 HTTP/2,且在協(xié)議層面與 HTTP/2 有一些強綁定。如 QUIC 幀映射 HTTP/2 frame. 這就導致很多大廠都沒有跟進 QUIC,使得 HTTP/2 over QUIC 基本只能在 Google 自家的 Chrome, Gmail 等軟件中普及使用,一度給行業(yè)造成“只有Google在弄”的錯覺。
納入 IETF 以后,顯然 Google 就不能這么玩了。QUIC 定位為一個通用安全傳輸層協(xié)議:
可以近似的認為 QUIC over UDP 將成為下一代(或替代)TLS over TCP. 也就是說, QUIC 將能應用于任何應用層協(xié)議中,只是當前階段將優(yōu)先在 HTTP 中進行應用和驗證。
統(tǒng)一使用 TLS 1.3 作為安全協(xié)議
2018年,有幾個重要的WEB標準終于塵埃落定,其中一個便是 RFC 8446 TLS 1.3. 這個標準對于降低延遲,改善用戶體驗,尤其是移動端的體驗有非常重要的意義。在雖然 TLS 1.3和 QUIC 都能做到 0-RTT,從而降低延遲,但是 QUIC 卻自顧自地實現(xiàn)了一套安全協(xié)議。主要是因為當時 TLS 1.3 標準還沒有發(fā)布,而 QUIC 又需要一套安全協(xié)議:
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 標準已經(jīng)發(fā)布,而 HTTP/3 也納入 IETF,因此 QUIC 也就順理成章的使用 TLS 1.3 作為其安全協(xié)議。Google 在這些方面倒是從來都不雞賊和墨跡,點贊。
使用 QHPACK 頭部壓縮代替 HPACK
其實,QPACK與HPACK的設計非常類似,單獨提出QPACK主要是更好的適配QUIC,同時也是 Google 將 QUIC 從與 HTTP/2 的耦合中抽離出來,與 IETF 標準完成統(tǒng)一的必要一步。
HTTP/3 問題與挑戰(zhàn)
UDP 連通性問題
幾乎所有的電信運營商都會“歧視” UDP 數(shù)據(jù)包,原因也很容易理解,畢竟歷史上幾次臭名昭著的 DDoS 攻擊都是基于 UDP 的。國內(nèi)某城寬帶在某些區(qū)域更是直接禁止了非53端口的UDP數(shù)據(jù)包,而其他運營商及IDC即使沒有封禁UDP,也是對UDP進行嚴格限流的。這點上不太樂觀,但是我們相信隨著標準的普及和推廣落地,運營商會逐步改變對UDP流量的歧視策略。國外的情況會稍好一些,根據(jù)Google的數(shù)據(jù),他們部署的QUIC降級的比例不到10%。
QUIC 不支持明文傳輸
對于用戶來說,這是一個優(yōu)勢,并不是問題。對于國內(nèi)內(nèi)容審查環(huán)境來說是個不可忽視的坎。但QUIC以后畢竟也是基于TLS協(xié)議的,國內(nèi)HTTPS都能普及下來,QUIC的普及也許會更樂觀一些。
UDP 消耗資源多
當前階段,UDP消耗的CPU資源多,且處理速度慢。這是不爭的事實,但是我相信隨著UDP應用的增多,內(nèi)核和硬件的優(yōu)化一定會跟上,直至達到或超過TCP的性能。而 QUIC 因為實在應用層實現(xiàn),因此迭代速度更快,部署和更新難度和代價更小,能夠一定程度緩解如TCP那樣的協(xié)議僵化問題。