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

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

背景

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

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

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

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

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

什么是HTTP/3

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

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

HTTP/3 是如何工作的?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為什么HTTP/3很重要?

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

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

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

網(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的改頭換面，朝著這個(gè)方向合理地邁出了一步。

HTTP/3的最佳用例

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

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

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

大數(shù)據(jù)

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

Web VR

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

采用HTTP/3：考慮和限制

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

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

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

針對(duì)受限的IoT設(shè)備，HTTP/3由于過于繁瑣從而無法采用。許多IoT應(yīng)用部署的設(shè)備的外形尺寸非常小。因此，它們的RAM和CPU功率都是有限的。為了使設(shè)備在電池功率、低比特率和有損連接等限制條件下高效運(yùn)行，必須執(zhí)行此要求。HTTP/3在現(xiàn)有的UDP之上，以QUIC的形式在傳輸層處理，增加了HTTP/3在整個(gè)協(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ù)器正式支持。不過，有幾個(gè)lib可以用來實(shí)驗(yàn)這個(gè)新協(xié)議，也提供了非官方的補(bǔ)丁。

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

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

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

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

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

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

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

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

原文地址：https://www.ably.io/concepts/http3?utm_medium=referral&utm_source=reddit&utm_campaign=evergreen#limitations

本文轉(zhuǎn)載自微信公眾號(hào)「 高可用架構(gòu)」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 高可用架構(gòu)公眾號(hào)。