深入探討HTTP3原理及應(yīng)用

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

本文將深入探討HTTP/3，介紹HTTP協(xié)議的演變歷程，重點介紹HTTP/3的特點，并對HTTP/3將會帶來的互聯(lián)網(wǎng)變化提供新的視角。

背景

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

多年來，HTTP從HTTP/1.0發(fā)展到HTTP/1.1，再到HTTP/2。在每一次迭代中，協(xié)議都增加了新的功能，以處理大量的需求，如應(yīng)用層需求、安全考慮、會話處理和媒體類型等。要深入了解HTTP/2及其從HTTP/1.0演變而來的HTTP/2，請看我們的HTTP/2概念文章。

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

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上運行HTTP的局限性，并深入了解一下基于QUIC協(xié)議的HTTP/3的設(shè)計思想。

什么是HTTP/3

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

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

HTTP/3 是如何工作的?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為什么HTTP/3很重要?

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

現(xiàn)在，隨著智能手機和便攜式設(shè)備的數(shù)量超過臺式機和筆記本電腦的數(shù)量，超過50%的互聯(lián)網(wǎng)流量已經(jīng)通過無線傳輸。這種趨勢給整體的網(wǎng)絡(luò)瀏覽體驗帶來了問題，其中最重要的是在無線覆蓋率不足的情況下，TCP中的行頭阻塞。

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

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

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

HTTP/3的最佳用例

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

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

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

大數(shù)據(jù)

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

Web VR

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

采用HTTP/3：考慮和限制

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

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

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

針對受限的IoT設(shè)備，HTTP/3由于過于繁瑣從而無法采用。許多IoT應(yīng)用部署的設(shè)備的外形尺寸非常小。因此，它們的RAM和CPU功率都是有限的。為了使設(shè)備在電池功率、低比特率和有損連接等限制條件下高效運行，必須執(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。

開始使用HTTP/3

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

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

Quiche (https://github.com/cloudflare/quiche)

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

Aioquic (https://github.com/aiortc/aioquic)

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

Neqo (https:/github.com/mozilla/neqo)

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