Categories
程式開發

HTTP/3的現狀:全世界使用服務接近30萬


HTTP/3是下一代跨Web的網絡通信協議,這意味著它會部分取代HTTP/1和HTTP/2。離2月在蘇黎世召開的下一屆QUIC工作組會議還有一個月的時間,回顧一下HTTP/3的承諾和當前客戶端/服務器的支持情況可能會非常有助益。

HTTP/3承諾讓互聯網連接更快、更穩定和更安全。它的前身為“HTTP over QUIC”,其目標是讓HTTP在谷歌自己的傳輸層協議QUIC上運行,隨後,它被提議為IETF,目前它是Internet草案。在2018年10月,IETF HTTP & QUIC工作組聯席主席Mark Nottingham提議將HTTP over QUIC重命名為HTTP/3,以澄清其本質特點以及與QUIC的獨立性。

QUIC是HTTP/3的關鍵元素,因為它是主要特性的基礎。 QUIC構建在UDP之上,致力於解決使用TCP協議的主要問題,比如,連接建立的延遲以及在包丟失的情況下多個流的處理。 TCP延遲問題源於其擁塞控制算法的需求,該算法要求在擁塞發生之前會緩慢地開始(slow start)評估可以發送多少流量。在HTTP/1.0中,每個TCP請求/響應交換都會被分配一個新的連接,因此會導致啟動緩慢的問題。

從此之後,規避TCP啟動慢的嘗試一直是HTTP協議改善的核心。

HTTP/1.1引入了“keep-alive”連接,允許在同一個TCP連接上對多個請求-響應交換進行序列化,因此不需要為每個請求都設置新的連接建立階段。然而,HTTP/1.1的keep-alive連接不支持同時發送多個請求,隨著Web頁面日益複雜,這導致了新的瓶頸。

HTTP/2源自現在已被棄用的SPDY協議,它引入了在同一連接中嵌入第一等流的概念。這使得在保證多路復用的同時實現請求-響應交換成為可能,但是它有一個主要的缺陷:當包丟失增加時,HTTP/2的性能會由於TCP處理包重傳的方式(HOL阻塞)而下降。這種影響可能非常嚴重,因為所有流都共享相同的連接。當數據包丟失超過一個給定的閾值時,HTTP/1的多連接甚至會比HTTP/2運行地更高效。

如前文所述,QUIC提供了對流的第一等支持,這解決了HTTP/2中連接初始化緩慢的問題。另外,它可以對它們進行單獨處理,從而解決了由於包丟失而導致的性能問題。採用QUIC作為傳輸層協議是HTTP/3與HTTP/2最大的區別。由於QUIC原生實現了大量與流管理相關的特性,這些特性是HTTP/2規範的組成部分,因此可以從HTTP/3中刪除它們。此外,由於HTTP/2 HPACK報頭壓縮嚴重依賴TCP向端點傳遞包的順序,所以需要採用QUIC來創建新的HTTP報頭壓縮方案,即QPACK

最近幾年來,谷歌一直在使用QUIC提供自己的服務,包括搜索、YouTube等,而且在Chrome中也支持它。曾經有一段時間,在與支持QUIC的谷歌服務通信時,Chrome是唯一的手段。最近,Mozilla在Firefox 72中也增加了對HTTP/3的支持,儘管仍處於試驗階段。命令行工具curl在7.66.0版本中也增加了對HTTP/3的支持以及許多其他特性。在服務器端,LightSpeedNginx支持HTTP/3。

在雲方面,除了谷歌之外,Cloudflare幾個月前宣布已經為部分客戶啟用了對HTTP/3的初步支持。 Cloudflare也是Quiche背後的公司,Quiche是一個支持HTTP/3客戶端和服務器實現的開源Rust庫

如前所述,HTTP/3仍然正在由IETF進行定義,還沒有確定正式的發布日期。與此同時,在世界範圍內,HTTP/3的使用正在增長,全世界使用它的服務接近300,000個。谷歌仍然是部署HTTP/3的最重要組織,但是其他幾個組織也佔據了重要的份額。 InfoQ將繼續及時報導HTTP/3,讓我們的讀者了解互聯網的最新變革。

原文鏈接:

The Status of HTTP/3