本文中文譯文由作者“ably.io”發(fā)布于公眾號“高可用架構(gòu)”，譯文原題：《深入解讀HTTP3的原理及應(yīng)用》、英文原題：《HTTP/3 deep dive》（文末有譯文和原文鏈接），即時通訊網(wǎng)收錄時有少許改動，感謝原作者和譯者的分享。

1、引言

HTTP3是HTTP協(xié)議的最新版本。從誕生之初，HTTP就是交換超文本文檔的首選應(yīng)用層協(xié)議。多年來，為了跟上互聯(lián)網(wǎng)的發(fā)展，以及WWW上交換的內(nèi)容種類增加，HTTP進(jìn)行了幾次重大升級，而HTTP/3就是目前的最新版本。

本文將從HTTP/3的基本概念、技術(shù)原理、應(yīng)用場景和如何使用它等方面進(jìn)行介紹，確保在有限的篇幅內(nèi)，能讓你通俗地理解它。

 

本文是系列文章中的第12篇，本系列文章的大綱如下：

《網(wǎng)絡(luò)編程懶人入門(一)：快速理解網(wǎng)絡(luò)通信協(xié)議（上篇）》

《網(wǎng)絡(luò)編程懶人入門(二)：快速理解網(wǎng)絡(luò)通信協(xié)議（下篇）》

《網(wǎng)絡(luò)編程懶人入門(三)：快速理解TCP協(xié)議一篇就夠》

《網(wǎng)絡(luò)編程懶人入門(四)：快速理解TCP和UDP的差異》

《網(wǎng)絡(luò)編程懶人入門(五)：快速理解為什么說UDP有時比TCP更有優(yōu)勢》

《網(wǎng)絡(luò)編程懶人入門(六)：史上最通俗的集線器、交換機(jī)、路由器功能原理入門》

《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》

《網(wǎng)絡(luò)編程懶人入門(八)：手把手教你寫基于TCP的Socket長連接》

《網(wǎng)絡(luò)編程懶人入門(九)：通俗講解，有了IP地址，為何還要用MAC地址？》

《網(wǎng)絡(luò)編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議》

《網(wǎng)絡(luò)編程懶人入門(十一)：一文讀懂什么是IPv6》

《網(wǎng)絡(luò)編程懶人入門(十二)：快速讀懂Http/3協(xié)議，一篇就夠！》（本文）

學(xué)習(xí)交流：

- 即時通訊/推送技術(shù)開發(fā)交流5群：215477170 [推薦]

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

歡迎關(guān)注“即時通訊技術(shù)圈”，更多好文會同步發(fā)布在公眾號：

（本文同步發(fā)布于：http://www.52im.net/thread-3020-1-1.html）

2、相關(guān)文章

《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》

《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》

《腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會的一些知識》

《網(wǎng)絡(luò)編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議》（推薦）

《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》（推薦）

3、HTTP協(xié)議的演進(jìn)史

在萬維網(wǎng)誕生之時，萬維網(wǎng)僅僅是一群交換超文本文件的計算機(jī)。在計算機(jī)之間交換文件是一個簡單的程序，包括請求和響應(yīng)。在此基礎(chǔ)上設(shè)計了一個簡單的基于文本的協(xié)議。HTTP（超文本傳輸協(xié)議）應(yīng)運(yùn)而生。后來，它被起草成了一個標(biāo)準(zhǔn)化的IETF協(xié)議，定義在RFC 1945中，也被稱為HTTP/1.0。

多年來，HTTP從HTTP/1.0發(fā)展到HTTP/1.1，再到HTTP/2。在每一次迭代中，協(xié)議都增加了新的功能，以處理大量的需求，如應(yīng)用層需求、安全考慮、會話處理和媒體類型等。要深入了解HTTP/2及其演進(jìn)史，可詳讀《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》。

盡管經(jīng)歷了幾次修訂，但HTTP的底層傳輸機(jī)制基本沒有變化。但是，隨著互聯(lián)網(wǎng)流量的激增，在移動電話的推動下，HTTP的傳輸機(jī)制在保證網(wǎng)頁瀏覽體驗(yàn)的流暢性方面變得問題重重。

HTTP/3是為了處理HTTP/2.0的傳輸相關(guān)問題而生的，可以在各種設(shè)備上更快地訪問Web。它基于一個新的傳輸層協(xié)議，稱為QUIC（Quick UDP Internet Protocol），在UDP之上工作。這一選擇與之前版本的HTTP截然不同，之前版本都是基于TCP。TCP是一個比UDP更可靠的協(xié)議，那么為什么要在UDP之上重新設(shè)計HTTP的傳輸層呢？

 

讓我們來看看在TCP上運(yùn)行HTTP的局限性，并深入了解一下基于QUIC協(xié)議的HTTP/3的設(shè)計思想。

4、什么是HTTP/3

當(dāng)IETF正式標(biāo)準(zhǔn)化HTTP/2時，Google正在獨(dú)立構(gòu)建一個新的傳輸協(xié)議，名為gQUIC。它后來成為新互聯(lián)網(wǎng)草案，并被命名為QUIC。gQUIC最初的實(shí)驗(yàn)證明，在網(wǎng)絡(luò)條件較差的情況下，gQUIC在增強(qiáng)網(wǎng)頁瀏覽體驗(yàn)方面的效果非常好。因此，gQUIC的發(fā)展勢頭越來越好，IETF的大多數(shù)成員贊成建立一個在QUIC上運(yùn)行的HTTP新規(guī)范。這個新的倡議被稱為HTTP/3，以區(qū)別于當(dāng)前的HTTP/2標(biāo)準(zhǔn)。

 

從語法和語義上看，HTTP/3與HTTP/2相似。HTTP/3遵循相同的請求和響應(yīng)消息交換順序，其數(shù)據(jù)格式包含方法、標(biāo)題、狀態(tài)碼和body。然而，HTTP/3的顯著的偏差在于協(xié)議層在UDP之上的堆疊順序。

 

有關(guān)QUIC的更多資料，可以看看《網(wǎng)絡(luò)編程懶人入門(十)：一泡尿的時間，快速讀懂QUIC協(xié)議》、《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》。

5、HTTP/3 是如何工作的？

HTTP/3功能的核心是圍繞著底層的QUIC協(xié)議來實(shí)現(xiàn)的。在討論QUIC和UDP之前，我們有必要先列出TCP的某些限制，這也是導(dǎo)致QUIC發(fā)展的原因。

5.1 TCP可能會間歇性地掛起數(shù)據(jù)傳輸

如果一個序列號較低的數(shù)據(jù)段還沒有接收到，即使其他序列號較高的段已經(jīng)接收到，TCP的接收機(jī)滑動窗口也不會繼續(xù)處理。這將導(dǎo)致TCP流瞬間掛起，在更糟糕的情況下，即使所有的段中有一個沒有收到，也會導(dǎo)致關(guān)閉連接。這個問題被稱為TCP流的行頭阻塞（HoL）。

 

5.2 TCP不支持流級復(fù)用

雖然TCP確實(shí)允許在應(yīng)用層之間建立多個邏輯連接，但它不允許在一個TCP流中復(fù)用數(shù)據(jù)包。使用HTTP/2時，瀏覽器只能與服務(wù)器打開一個TCP連接，并使用同一個連接來請求多個對象，如CSS、JavaScript等文件。在接收這些對象的同時，TCP會將所有對象序列化在同一個流中。因此，它不知道TCP段的對象級分區(qū)。

5.3 TCP會產(chǎn)生冗余通信

TCP連接握手會有冗余的消息交換序列，即使是與已知主機(jī)建立的連接也是如此。

 

QUIC協(xié)議在以下設(shè)計選擇的基礎(chǔ)上，通過引入一些底層傳輸機(jī)制的改變，解決了這些問題。

1）選擇UDP作為底層傳輸層協(xié)議：在TCP之上建立新的傳輸機(jī)制，將繼承TCP的上述所有缺點(diǎn)。因此，UDP是一個明智的選擇。此外，QUIC是在用戶層構(gòu)建的，所以不需要每次協(xié)議升級時進(jìn)行內(nèi)核修改。

2）流復(fù)用和流控：QUIC引入了連接上的多路流復(fù)用的概念。QUIC通過設(shè)計實(shí)現(xiàn)了單獨(dú)的、針對每個流的流控，解決了整個連接的行頭阻塞問題。

 

3）靈活的擁塞控制機(jī)制：TCP的擁塞控制機(jī)制是剛性的。該協(xié)議每次檢測到擁塞時，都會將擁塞窗口大小減少一半。相比之下，QUIC的擁塞控制設(shè)計得更加靈活，可以更有效地利用可用的網(wǎng)絡(luò)帶寬，從而獲得更好的吞吐量。

4）更好的錯誤處理能力：QUIC使用增強(qiáng)的丟失恢復(fù)機(jī)制和轉(zhuǎn)發(fā)糾錯功能，以更好地處理錯誤數(shù)據(jù)包。該功能對于那些只能通過緩慢的無線網(wǎng)絡(luò)訪問互聯(lián)網(wǎng)的用戶來說是一個福音，因?yàn)檫@些網(wǎng)絡(luò)用戶在傳輸過程中經(jīng)常出現(xiàn)高錯誤率。

5）更快的握手：QUIC使用相同的TLS模塊進(jìn)行安全連接。然而，與TCP不同的是，QUIC的握手機(jī)制經(jīng)過優(yōu)化，避免了每次兩個已知的對等者之間建立通信時的冗余協(xié)議交換。

 

通過在QUIC之上構(gòu)建基于HTTP/3的應(yīng)用層，您可以獲得增強(qiáng)型傳輸機(jī)制的所有優(yōu)勢，同時保留HTTP/2的語法和語義。但是，你也必須注意到，HTTP/2不能直接與QUIC集成，因?yàn)閺膽?yīng)用到傳輸?shù)牡讓訋成涫遣患嫒莸摹Ｒ虼耍琁ETF的HTTP工作組建議將HTTP/3作為新的HTTP版本，并根據(jù)QUIC協(xié)議的幀格式要求修改了幀映射。

除此之外，HTTP/3還使用了一種新的HTTP頭壓縮機(jī)制，稱為QPACK，是對HTTP/2中使用的HPACK的增強(qiáng)。在QPACK下，HTTP頭可以在不同的QUIC流中不按順序到達(dá)。與HTTP/2中的TCP確保數(shù)據(jù)包的按順序傳遞不同，QUIC流是不按順序傳遞的，在不同的流中可能包含不同的HTTP頭。因此，QPACK使用查找表機(jī)制對報頭進(jìn)行編碼和解碼。

6、為什么HTTP/3很重要？

TCP已經(jīng)有40多年的歷史了。它在1981年通過RFC 793從而標(biāo)準(zhǔn)化。多年來，它經(jīng)歷了多次更新，是一個非常強(qiáng)大的傳輸協(xié)議，可以支持互聯(lián)網(wǎng)流量的增長。然而，由于設(shè)計上的原因，TCP從來就不適合處理有損無線環(huán)境中的數(shù)據(jù)傳輸。在互聯(lián)網(wǎng)的早期，有線網(wǎng)絡(luò)將網(wǎng)絡(luò)中的每一臺計算機(jī)連接起來。

現(xiàn)在，隨著智能手機(jī)和便攜式設(shè)備的數(shù)量超過臺式機(jī)和筆記本電腦的數(shù)量，超過50%的互聯(lián)網(wǎng)流量已經(jīng)通過無線傳輸。這種趨勢給整體的網(wǎng)絡(luò)瀏覽體驗(yàn)帶來了問題，其中最重要的是在無線覆蓋率不足的情況下，TCP中的行頭阻塞（關(guān)于TCP在移動網(wǎng)絡(luò)下的不足，請閱讀《5G時代已經(jīng)到來，TCP/IP老矣，尚能飯否？》）。

Google的一些初步實(shí)驗(yàn)證明，QUIC作為Google部分熱門服務(wù)的底層傳輸協(xié)議，極大地提高了速度和用戶體驗(yàn)。部署QUIC作為YouTube視頻的底層傳輸協(xié)議，導(dǎo)致YouTube視頻流的緩沖率下降了30%，這直接影響了用戶的視頻觀看體驗(yàn)。在顯示谷歌搜索結(jié)果時，也有類似的改善。

網(wǎng)絡(luò)條件較差的情況下提升非常明顯，這促使谷歌更加積極地完善該協(xié)議，并最終向IETF提出標(biāo)準(zhǔn)化。

由于這些早期的試驗(yàn)所帶來的所有改進(jìn)，QUIC已經(jīng)成為帶領(lǐng)萬維網(wǎng)走向未來的重要因素。在QUIC的支持下，HTTP從HTTP/2到HTTP/3的改頭換面，朝著這個方向合理地邁出了一步。

 

7、HTTP/3的最佳用例

HTTP/3將改善我們上網(wǎng)的體驗(yàn)，特別是在仍無法使用高速無線網(wǎng)絡(luò)的地區(qū)。盡管HTTP/2已經(jīng)解決了一部分問題，然而HTTP/3更進(jìn)一步。

7.1 物聯(lián)網(wǎng)(IoT)

HTTP可能不是物聯(lián)網(wǎng)的首選協(xié)議，但在某些情況下，基于HTTP的通信非常適合特定的應(yīng)用。HTTP/3可以解決從傳感器收集數(shù)據(jù)的移動電話的無線連接損耗問題。這個問題同樣適用于安裝在車輛或可移動資產(chǎn)上的獨(dú)立IoT設(shè)備。通過HTTP來訪問這些設(shè)備，可以更加可靠。

7.2 大數(shù)據(jù)

全球各地的企業(yè)都在覺醒，意識到從多個部門收集數(shù)據(jù)的潛力，并將其整合成更大的信息共享API，供內(nèi)部和外部受眾共享。這些API也為數(shù)據(jù)的貨幣化鋪平了道路，通過托管這些數(shù)據(jù)作為流API服務(wù)可以實(shí)現(xiàn)數(shù)據(jù)的貨幣化。隨著時間的推移，這些服務(wù)會吐出海量的數(shù)據(jù)。通過HTTP/3托管的流API將使它們比HTTP/2更健壯、更有彈性。

7.3 Web VR

隨著瀏覽器能力的提升，內(nèi)容格局正在快速變化。其中一個領(lǐng)域就是基于網(wǎng)絡(luò)的VR。雖然還處于起步階段，但有很多的用例可以讓VR在加強(qiáng)協(xié)作方面發(fā)揮關(guān)鍵作用。網(wǎng)絡(luò)在促進(jìn)VR互動方面占據(jù)了核心位置。VR應(yīng)用需要更多的帶寬來渲染虛擬場景中的復(fù)雜細(xì)節(jié)，因此遷移到HTTP/3會大有收獲。

8、HTTP/3的局限性

過渡到HTTP/3不僅涉及到應(yīng)用層的變化，還涉及到底層傳輸層的變化。因此，與它的前身HTTP/2相比，HTTP/3的采用更具挑戰(zhàn)性，因?yàn)楹笳咧恍枰淖儜?yīng)用層。傳輸層承受著網(wǎng)絡(luò)中的大量中間層審查。這些中間層，如防火墻、代理、NAT設(shè)備等會進(jìn)行大量的深度數(shù)據(jù)包檢查，以滿足其功能需求。因此，新的傳輸機(jī)制的引入對IT基礎(chǔ)設(shè)施和運(yùn)維團(tuán)隊(duì)來說有一些影響。

然而，HTTP/3被廣泛采用的另一個問題是，它是基于QUIC的，在UDP上運(yùn)行。大多數(shù)的Web流量，以及IETF定義的知名服務(wù)都是在TCP之上運(yùn)行的。這也是為什么長時間運(yùn)行HTTP/3的UDP會話會被防火墻的默認(rèn)數(shù)據(jù)包過濾策略所影響的原因。

隨著IETF正在進(jìn)行的標(biāo)準(zhǔn)化工作，這些問題最終都會得到解決。此外，考慮到Google在早期QUIC實(shí)驗(yàn)所顯示的積極結(jié)果，人們對HTTP/3的支持是壓倒性的，這將最終迫使中間層廠商標(biāo)準(zhǔn)化。

針對受限的IoT設(shè)備，HTTP/3由于過于繁瑣從而無法采用。許多IoT應(yīng)用部署的設(shè)備的外形尺寸非常小。因此，它們的RAM和CPU功率都是有限的。為了使設(shè)備在電池功率、低比特率和有損連接等限制條件下高效運(yùn)行，必須執(zhí)行此要求。HTTP/3在現(xiàn)有的UDP之上，以QUIC的形式在傳輸層處理，增加了HTTP/3在整個協(xié)議棧中的占用空間。這使得HTTP/3較為笨重，不適合那些IoT設(shè)備。但這種情況很少出現(xiàn)，而且存在專門的協(xié)議，這就避免了直接在此類設(shè)備上支持HTTP的需要。此外，還有以物聯(lián)網(wǎng)為核心的協(xié)議，如MQTT。

9、開始使用HTTP/3

IETF的HTTP工作組正致力于在2020年后期發(fā)布HTTP/3。因此它還沒有被NGINX和Apache等主流web服務(wù)器正式支持。不過，有幾個lib可以用來實(shí)驗(yàn)這個新協(xié)議，也提供了非官方的補(bǔ)丁。

以下是支持HTTP/3和QUIC傳輸lib的列表。請注意，這些實(shí)現(xiàn)都是基于互聯(lián)網(wǎng)標(biāo)準(zhǔn)草案某一個版本，而這個版本很可能會被更高的版本所取代，最終的標(biāo)準(zhǔn)會在RFC中發(fā)布。

1）Quiche ：

Quiche提供了通過QUIC協(xié)議發(fā)送和接收數(shù)據(jù)包的底層編程接口。它還支持HTTP/3模塊，通過其QUIC協(xié)議實(shí)現(xiàn)發(fā)送HTTP數(shù)據(jù)包。除此之外，它還為NGINX服務(wù)器提供了一個非官方的補(bǔ)丁，可以安裝和托管一個能夠運(yùn)行HTTP/3的Web服務(wù)器。除此以外，還提供了額外的程序來支持Android和iOS移動應(yīng)用上使用HTTP/3。

2）Aioquic：

Aioquic是QUIC的python實(shí)現(xiàn)。它還內(nèi)置HTTP/3的測試服務(wù)器和客戶端庫。Aioquic建立在asyncio模塊之上，asyncio模塊是Python的標(biāo)準(zhǔn)異步I/O框架。

3）Neqo：

Neqo 是 Mozilla 使用 Rust 實(shí)現(xiàn) QUIC 和 HTTP/3。

如果你想嘗試QUIC，請查看這個由QUIC工作組維護(hù)的QUIC協(xié)議的開源實(shí)現(xiàn)鏈接：https://github.com/quicwg/base-drafts/wiki/Implementations

（本文英文原文鏈接：點(diǎn)此進(jìn)入、中文譯文鏈接：點(diǎn)此進(jìn)入）

附錄：更多有關(guān)HTTP協(xié)議的文章

《網(wǎng)絡(luò)編程懶人入門(七)：深入淺出，全面理解HTTP協(xié)議》

《技術(shù)掃盲：新一代基于UDP的低延時網(wǎng)絡(luò)傳輸層協(xié)議——QUIC詳解》

《讓互聯(lián)網(wǎng)更快：新一代QUIC協(xié)議在騰訊的技術(shù)實(shí)踐分享》

《從HTTP/0.9到HTTP/2：一文讀懂HTTP協(xié)議的歷史演變和設(shè)計思路》

《腦殘式網(wǎng)絡(luò)編程入門(三)：HTTP協(xié)議必知必會的一些知識》

《腦殘式網(wǎng)絡(luò)編程入門(四)：快速理解HTTP/2的服務(wù)器推送(Server Push)》

《Comet技術(shù)詳解：基于HTTP長連接的Web端實(shí)時通信技術(shù)》

《WebSocket詳解（四）：刨根問底HTTP與WebSocket的關(guān)系(上篇)》

《WebSocket詳解（五）：刨根問底HTTP與WebSocket的關(guān)系(下篇)》

《快速理解高性能HTTP服務(wù)端的負(fù)載均衡技術(shù)原理》

《一分鐘理解 HTTPS 到底解決了什么問題》

《一篇讀懂HTTPS：加密原理、安全邏輯、數(shù)字證書等》

《即時通訊安全篇（八）：你知道，HTTPS用的是對稱加密還是非對稱加密？》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課(四)：正確理解HTTP短連接中的Cookie、Session和Token》

《即時通訊安全篇（七）：如果這樣來理解HTTPS原理，一篇就夠了》

《一分鐘理解 HTTPS 到底解決了什么問題》

《一篇讀懂HTTPS：加密原理、安全邏輯、數(shù)字證書等》

《小白必讀：閑話HTTP短連接中的Session和Token》

《IM開發(fā)基礎(chǔ)知識補(bǔ)課：正確理解前置HTTP SSO單點(diǎn)登錄接口的原理》

《基于APNs最新HTTP/2接口實(shí)現(xiàn)iOS的高性能消息推送(服務(wù)端篇)》

《全面了解移動端DNS域名劫持等雜癥：原理、根源、HttpDNS解決方案等》

《美圖App的移動端DNS優(yōu)化實(shí)踐：HTTPS請求耗時減小近半》

《HTTPS時代已來，打算更新你的HTTP服務(wù)了嗎？》

《移動端網(wǎng)絡(luò)優(yōu)化之HTTP請求的DNS優(yōu)化》

（本文同步發(fā)布于：http://www.52im.net/thread-3020-1-1.html）