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 公里。
三個版本
- https://sfh1.lixiaoshuai.com/ HTTP/1.1
- https://sfh2.lixiaoshuai.com/ HTTP/2
- https://sfh3.lixiaoshuai.com/ HTTP/3
每個站點使用 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
