從舊金山到上海, HTTP/3 非常快!

HTTP/3 是超文本傳輸協議 (HTTP) 的第三個版本,它對 Web 性能來說意義重大, 讓我們看看HTTP/3 如何讓網站的速度變得更快!

等等,HTTP/2 發生了什麼? 不是幾年前纔開始推廣 HTTP/2 嗎? 確實是這樣, 但是它出現了一些 問題, 包括 TCP 隊首阻塞, 加密問題, 以及協議的帶來複雜性。爲了解決這些問題, HTTP/3 應運而生。

好吧,但是 HTTP/3 真的讓事情變得更快了嗎? 接下來,我將用一個簡單的web基準測試來證明它!

HTTP 簡史

HTTP(超文本傳輸協議 1.0)的第一個正式版本在 1996 年完成。但是發現了一些問題, 根據作者的說法, HTTP/1.0 沒有充分考慮分層代理、緩存、長連接的需求和虛擬主機的影響。 所以 HTTP/1.1在一年後,也就是 1997 年發佈, 同時它也是使用最廣泛的版本。

在 HTTP/1.1 中, 瀏覽器通過 TCP 連接一次只能下載一個文件, 如果一個頁面需要 10 個 js 文件, 那麼這些文件將會按順序下載。一個文件的延遲就會阻塞後面的其他內容, 也就是我們常說的 隊首阻塞

在18年後, HTTP 協議迎來了更新, HTTP/2 (RFC 7540) 發佈。 HTTP/2 的一大特點是多路複用。引入了二進制幀和流機制,允許使用單個 TCP 連接, 通過 Stream 並行下載資源, 提高了傳輸效率。

另外還有頭部壓縮 HPACK 算法, 減少重複 header 數據的傳輸。

但是, HTTP/2 雖然解決了 http 的隊首阻塞, 但是仍然會受到 TCP 隊首阻塞的影響。

事實上,在丟包率高的環境中,HTTP/1.1 性能更好,因爲瀏覽器打開了多個並行 TCP 連接!

使用 HTTP/3 和 QUIC 實現真正的多路複用

HTTP/2 和 HTTP/3 之間的主要區別在於它們使用的傳輸協議。HTTP/3 使用了 QUIC 新協議來代替 TCP 協議,而 QUIC 基於 UDP 開發, 和 TCP 不一樣是, UDP 並不需要三次握手, 結合 TLS1.3, 也爲 0-RTT 加密傳輸帶來了可能, HTTP/3 還帶來了新的頭部壓縮算法QPACK。

測試內容

站點

一個前端靜態站點, 包含了 10 個js 文件, 19 個圖片, 一些 css 和 font, 總共 36 個資源, 總大小 6.6 M。

服務器

Azure Standard B2s, 2 核 4G, Linux (Ubuntu 20.04), Web Server 使用了 Caddy (之前嘗試了 nginx, 目前使用 HTTP/3 需要編譯 nginx-quic 的代碼, 折騰一通後仍有問題, 遂放棄), 相比之下, Caddy 開啓 HTTP/3 就簡單, 另外自動的 https 證書也很方便。

另外設置了 Cache-Control: "no-store", 禁用緩存, HTTP/3 設置了 0-RTT。

地點

客戶端位於上海, 服務端在美國舊金山, 兩地距離大概10000 公里。

三個版本

每個站點使用 Chrome 分別訪問10次,然後記錄耗時。

測試結果

最後,我們看一下測試結果, HTTP/1.1 平均在 3500 ms, HTTP/2 平均在 2500 ms, 而 HTTP/3 平均在 1300 ms, 可以看到 HTTP/3 帶來的性能提升還是很明顯的。

總結

HTTP/3 很快! 雖然目前協議還是 Draft 狀態,不過 HTTP/3 RFC 應該很快就要正式發佈了。像 Google 和 Facebook 這種大型公司已經開始使用 HTTP/3 提供服務了, web server 也積極擁抱新協議,並提供了實驗性的支持。而 QUIC 能否取代使用了幾十年的 TCP? 讓我們拭目以待!

Reference

https://requestmetrics.com/web-performance/http3-is-fast

https://kinsta.com/blog/http3/

https://en.wikipedia.org/wiki/HTTP/2#Criticisms

https://en.wikipedia.org/wiki/HTTP/3

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章