HTTP3是HTTP協議的最新版本。從誕生之初，HTTP就是交換超文本文檔的首選應用層協議。多年來，為了跟上互聯網的發展，以及WWW上交換的內容種類增加，HTTP進行了幾次重大升級。

本文將深入探討HTTP/3，介紹HTTP協議的演變歷程，重點介紹HTTP/3的特點，并對HTTP/3將會帶來的互聯網變化提供新的視角。

背景

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

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

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

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

讓我們來看看在TCP上運行HTTP的局限性，并深入了解一下基于QUIC協議的HTTP/3的設計思想。

什么是HTTP/3

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

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

HTTP/3 是如何工作的?

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

TCP可能會間歇性地掛起數據傳輸

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

TCP不支持流級復用

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

TCP會產生冗余通信

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

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

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

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

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

更好的錯誤處理能力。QUIC使用增強的丟失恢復機制和轉發糾錯功能，以更好地處理錯誤數據包。該功能對于那些只能通過緩慢的無線網絡訪問互聯網的用戶來說是一個福音，因為這些網絡用戶在傳輸過程中經常出現高錯誤率。

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

通過在QUIC之上構建基于HTTP/3的應用層，您可以獲得增強型傳輸機制的所有優勢，同時保留HTTP/2的語法和語義。但是，你也必須注意到，HTTP/2不能直接與QUIC集成，因為從應用到傳輸的底層幀映射是不兼容的。因此，IETF的HTTP工作組建議將HTTP/3作為新的HTTP版本，并根據QUIC協議的幀格式要求修改了幀映射。

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

為什么HTTP/3很重要?

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

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

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

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

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

HTTP/3的最佳用例

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

物聯網(IoT)

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

大數據

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

Web VR

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

采用HTTP/3：考慮和限制

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

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

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

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

開始使用HTTP/3

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

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

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

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

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

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

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

Neqo 是 Mozilla 使用 Rust 實現 QUIC 和 HTTP/3。