網絡編程懶人入門(十二):快速讀懂Http/3協議,一篇就夠!

本文中文譯文由做者「ably.io」發佈於公衆號「高可用架構」,譯文原題:《深刻解讀HTTP3的原理及應用》、英文原題:《HTTP/3 deep dive》(文末有譯文和原文連接),即時通信網收錄時有少量改動,感謝原做者和譯者的分享。html

一、引言

HTTP3是HTTP協議的最新版本。從誕生之初,HTTP就是交換超文本文檔的首選應用層協議。多年來,爲了跟上互聯網的發展,以及WWW上交換的內容種類增長,HTTP進行了幾回重大升級,而HTTP/3就是目前的最新版本。python

本文將從HTTP/3的基本概念、技術原理、應用場景和如何使用它等方面進行介紹,確保在有限的篇幅內,能讓你通俗地理解它。git


 

本文是系列文章中的第12篇,本系列文章的大綱以下:github

網絡編程懶人入門(一):快速理解網絡通訊協議(上篇)web

網絡編程懶人入門(二):快速理解網絡通訊協議(下篇)編程

網絡編程懶人入門(三):快速理解TCP協議一篇就夠瀏覽器

網絡編程懶人入門(四):快速理解TCP和UDP的差別安全

網絡編程懶人入門(五):快速理解爲何說UDP有時比TCP更有優點服務器

網絡編程懶人入門(六):史上最通俗的集線器、交換機、路由器功能原理入門網絡

網絡編程懶人入門(七):深刻淺出,全面理解HTTP協議

網絡編程懶人入門(八):手把手教你寫基於TCP的Socket長鏈接

網絡編程懶人入門(九):通俗講解,有了IP地址,爲什麼還要用MAC地址?

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議

網絡編程懶人入門(十一):一文讀懂什麼是IPv6

網絡編程懶人入門(十二):快速讀懂Http/3協議,一篇就夠!》(本文)

學習交流:

- 即時通信/推送技術開發交流5羣:215477170 [推薦]

- 移動端IM開發入門文章:《新手入門一篇就夠:從零開發移動端IM

歡迎關注「即時通信技術圈」,更多好文會同步發佈在公衆號:

(本文同步發佈於:http://www.52im.net/thread-3020-1-1.html

二、相關文章

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

網絡編程懶人入門(七):深刻淺出,全面理解HTTP協議

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議》(推薦)

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》(推薦)

三、HTTP協議的演進史

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

多年來,HTTP從HTTP/1.0發展到HTTP/1.1,再到HTTP/2。在每一次迭代中,協議都增長了新的功能,以處理大量的需求,如應用層需求、安全考慮、會話處理和媒體類型等。要深刻了解HTTP/2及其演進史,可詳讀《從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路》。

儘管經歷了幾回修訂,但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之上的堆疊順序。


 

有關QUIC的更多資料,能夠看看《網絡編程懶人入門(十):一泡尿的時間,快速讀懂QUIC協議》、《技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解》。

五、HTTP/3 是如何工做的?

HTTP/3功能的核心是圍繞着底層的QUIC協議來實現的。在討論QUIC和UDP以前,咱們有必要先列出TCP的某些限制,這也是致使QUIC發展的緣由。

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

若是一個序列號較低的數據段尚未接收到,即便其餘序列號較高的段已經接收到,TCP的接收機滑動窗口也不會繼續處理。這將致使TCP流瞬間掛起,在更糟糕的狀況下,即便全部的段中有一個沒有收到,也會致使關閉鏈接。這個問題被稱爲TCP流的行頭阻塞(HoL)。


 

5.2 TCP不支持流級複用

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

5.3 TCP會產生冗餘通訊

TCP鏈接握手會有冗餘的消息交換序列,即便是與已知主機創建的鏈接也是如此。


 

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

1)選擇UDP做爲底層傳輸層協議:在TCP之上創建新的傳輸機制,將繼承TCP的上述全部缺點。所以,UDP是一個明智的選擇。此外,QUIC是在用戶層構建的,因此不須要每次協議升級時進行內核修改。

2)流複用和流控:QUIC引入了鏈接上的多路流複用的概念。QUIC經過設計實現了單獨的、針對每一個流的流控,解決了整個鏈接的行頭阻塞問題。


 

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

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

5)更快的握手: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中的行頭阻塞(關於TCP在移動網絡下的不足,請閱讀《5G時代已經到來,TCP/IP老矣,尚能飯否?》)。

Google的一些初步實驗證實,QUIC做爲Google部分熱門服務的底層傳輸協議,極大地提升了速度和用戶體驗。部署QUIC做爲YouTube視頻的底層傳輸協議,致使YouTube視頻流的緩衝率降低了30%,這直接影響了用戶的視頻觀看體驗。在顯示谷歌搜索結果時,也有相似的改善。

網絡條件較差的狀況下提高很是明顯,這促使谷歌更加積極地完善該協議,並最終向IETF提出標準化。

因爲這些早期的試驗所帶來的全部改進,QUIC已經成爲帶領萬維網走向將來的重要因素。在QUIC的支持下,HTTP從HTTP/2到HTTP/3的改頭換面,朝着這個方向合理地邁出了一步。


 

七、HTTP/3的最佳用例

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

7.1 物聯網(IoT)

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

7.2 大數據

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

7.3 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中發佈。

1)Quiche :

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

2)Aioquic

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

3)Neqo

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

若是你想嘗試QUIC,請查看這個由QUIC工做組維護的QUIC協議的開源實現連接:https://github.com/quicwg/base-drafts/wiki/Implementations

(本文英文原文連接:點此進入、中文譯文連接:點此進入

附錄:更多有關HTTP協議的文章

網絡編程懶人入門(七):深刻淺出,全面理解HTTP協議

技術掃盲:新一代基於UDP的低延時網絡傳輸層協議——QUIC詳解

讓互聯網更快:新一代QUIC協議在騰訊的技術實踐分享

從HTTP/0.9到HTTP/2:一文讀懂HTTP協議的歷史演變和設計思路

腦殘式網絡編程入門(三):HTTP協議必知必會的一些知識

腦殘式網絡編程入門(四):快速理解HTTP/2的服務器推送(Server Push)

Comet技術詳解:基於HTTP長鏈接的Web端實時通訊技術

WebSocket詳解(四):刨根問底HTTP與WebSocket的關係(上篇)

WebSocket詳解(五):刨根問底HTTP與WebSocket的關係(下篇)

快速理解高性能HTTP服務端的負載均衡技術原理

一分鐘理解 HTTPS 到底解決了什麼問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

即時通信安全篇(八):你知道,HTTPS用的是對稱加密仍是非對稱加密?

IM開發基礎知識補課(四):正確理解HTTP短鏈接中的Cookie、Session和Token

即時通信安全篇(七):若是這樣來理解HTTPS原理,一篇就夠了

一分鐘理解 HTTPS 到底解決了什麼問題

一篇讀懂HTTPS:加密原理、安全邏輯、數字證書等

小白必讀:閒話HTTP短鏈接中的Session和Token

IM開發基礎知識補課:正確理解前置HTTP SSO單點登陸接口的原理

基於APNs最新HTTP/2接口實現iOS的高性能消息推送(服務端篇)

全面瞭解移動端DNS域名劫持等雜症:原理、根源、HttpDNS解決方案等

美圖App的移動端DNS優化實踐:HTTPS請求耗時減少近半

HTTPS時代已來,打算更新你的HTTP服務了嗎?

移動端網絡優化之HTTP請求的DNS優化

(本文同步發佈於:http://www.52im.net/thread-3020-1-1.html

相關文章
相關標籤/搜索