在去年 Cloudflare生日周，我們宣布了初步支持HTTP/2 的下一代新協議– HTTP/3 。我們的目標是為建立一個更好的互聯網而努力。在標準制定上進行協作非常重要，我們很榮幸可以參與到制定標準的工作中來。
雖然 HTTP/3 仍處于草案狀態，但是有大量用戶對此表現出濃厚興趣。截至目前，已經有超過 113000 個網絡區域激活了 HTTP/3，如果你正在使用實驗性的瀏覽器，則可以使用新協議對這些站點進行訪問！有這么多用戶啟用 HTTP/3，這非常令人欣慰。
在與 google 的合作下，我們啟動了對HTTP/3 的支持，與此同時，Google 也在Google Chrome 中啟動了對HTTP/3 的實驗性支持。從那時起，我們看到越來越多的瀏覽器增加對HTTP/3 的實驗性支持：比如Firefox 的 Nightly 版本，其他基于 Chromium 的瀏覽器比如 Opera、Edge 以及 Safari 的技術預覽版本。
HTTP/3 發展現狀
IETF 標準化過程將協議開發為一系列文檔草案版本，其目的是確定最終版本，并根據該版本發布 RFC。QUIC 工作組的成員在分析、實施和互操作規范方面進行協作，目的是及時發現問題并優化協議。
我們目前支持了 HTTP/3 的 Draft-23 版本，此后會持續跟進和適配未來新草案版本，在撰寫本文時，最新草案版本號為 27 。針對每次草案版本更新，QUIC 協議的內容質量都會有所提升，以保證協議內容與其表現保持“基本共識”。為避免協議迭代發展過程中因為升級分析處于停滯狀態，異或是因為變更而出現無休止的調整，隨著每個新草案的提出，對已有規范提出修改的門檻一直在提高。這意味著版本之間的更改較小，并且最終的 RFC 應該與我們當前在生產環境中運行的協議緊密聯系，差異更小。
HTTP/3 的優點
HTTP/3 的主要優點之一是性能提升，特別是在同時獲取多個對象時的性能。使用 HTTP/2，TCP 連接中的任何中斷（packet loss）會阻塞所有數據流（Head of line blocking）。因為 HTTP/3 基于 UDP 協議，所以如果數據包丟失，只會中斷一個數據流，而不會中斷所有流。
此外，HTTP/3 提供了 0-RTT 支持，這意味著在建立連接時通過消除與服務器的 TLS 確認，可以使后續連接的啟動速度更快。比起使用完全 TLS 協商的方式，客戶端可以更快地開始請求數據，網站可以更早開始加載。
下圖說明了 HTTP/2 多路復用兩個請求時數據包丟失情況及其影響。客戶端通過 HTTP/2 向服務器發送請求，請求兩個資源（我們將請求及其關聯的響應涂成綠色和黃色）。響應被分解為多個數據包，可惜的是，如果一個數據包丟失，兩個請求都會響應失敗。
上面顯示了使用 HTTP/3 協議多路復用 2 個請求的情況。當丟失一個黃色的響應數據包時，只對黃色數據包的響應造成影響，并不會對綠色數據包代表的響應造成影響。
會話啟動方式的改進意味著與服務器的“連接”啟動速度更快，這意味著瀏覽器可以更快地獲取數據。我們很想知道改進有多大，所以我們進行了一些測試。為衡量由 0-RTT 支持帶來的改進，我們運行了一些基準測試來測量獲取第一個字節的用時（TTFB）。平均而言，使用 HTTP/3，我們獲取到第一個字節出現在 176ms 之后。使用 HTTP/2，這個時間是 201ms，這意味著 HTTP/3 的性能已經提高了 12.4％！
有趣的是，協議的每個方面并不都受到草案或 RFC 的約束。協議實現方式的選擇，例如有效的數據包傳輸和擁塞控制算法的選擇，會影響其性能。擁塞控制是用戶計算機和服務器用來適應過載網絡的一種技術：通過丟棄數據包，隨后的數據傳輸就會受到限制。由于 QUIC 是一種新協議，因此正確地進行擁塞控制設計和實現需要進行實驗和調整。
從簡潔性和安全性角度出發，丟失檢測和擁塞控制規范建議使用 Reno 算法，但允許用戶根據自身情況選擇任何算法。我們的實現從 New Reno 算法開始，基于以往經驗，我們知道可以通過其他方式獲得更好的性能。我們最近已遷移到 CUBIC 算法，在數據傳輸量大且數據包丟失頻繁的網絡情況下，CUBIC 算法性能與 New Reno 算法相比有很大提升。
對于現有的 HTTP/2 技術棧，我們目前支持 BBR V1 （TCP）。這意味著在我們的測試中，我們無法進行精確的比較，因為這些擁塞控制算法在較小數據傳輸和較大數據傳輸之間的行為會有所不同。雖然如此，與 HTTP/2 相比，我們已經看到使用 HTTP/3 在較小內容傳輸下的速度更快。對于較大區域，改進后的 HTTP/2 的擁塞控制在性能上大放異彩。
對于 15KB 的小型測試網頁，HTTP/3 平均需要 443ms 加載，而 HTTP/2 則為 458ms。但是，一旦我們將頁面大小增加到 1MB，優勢就會消失：HTTP/3 僅比當今網絡上的 HTTP/2 慢一點，HTTP/3 加載花費 2.33 秒，而 HTTP/2 加載花費 2.30 秒。
基準測試很有意思，然而我們更想知道 HTTP/3 在現實世界中的表現。
為進行衡量，我們希望有一個第三方可以像瀏覽器一樣在我們的網絡上加載網站。WebPageTest 是一個通用框架，通過漂亮的瀑布圖來展示頁面加載時間。為了分析后端，我們使用了自家的 Browser Insights 來捕獲白屏時間。然后，我們將這兩部分數據通過自動化的方式結合在一起。
作為測試用例，我們決定對公司博客進行性能監控。我們在全球范圍配置了 WebPageTest 實例，以同時通過 HTTP/2 和 HTTP/3 加載站點。我們還啟用了 HTTP/3 和 Browser Insight。因此，每當我們的測試腳本檢測到使用支持 HTTP/3 的瀏覽器訪問該站點加載網頁時，瀏覽器就會將報告數據返回。清洗數據并與 HTTP/2 的報告數據進行比較。
下圖顯示了真實頁面（ blog.cloudflare.com ）的頁面加載時間，以比較 HTTP/3 和 HTTP/2 的性能。同時我們還從不同的地理位置進行了這些性能評估。
如上圖所見，在北美，HTTP/3 性能仍落后于 HTTP/2 性能，性能差距平均水平約為 1-4％，在歐洲，亞洲和南美也得到類似結論。我們懷疑這可能是由于擁塞算法不同所致：BBR v1 上的 HTTP/2 與 CUBIC 上的 HTTP/3 不同。將來，我們將努力在兩者上支持相同的擁塞算法，以實現更準確的性能對比。
結論
總體而言，我們很高興一起參與推動這一標準的發展。我們的實現效果很好，在某些情況下提供了更好的性能，并且在最壞的情況下性能也和 HTTP/2 相近。隨著標準的定稿，我們期待瀏覽器在主流版本中增加對 HTTP/3 的支持。對我們來說，我們將繼續支持最新的草案，同時尋找更多的方法，比如擁塞調整、優先級劃分或者系統容量（CPU 和原始網絡吞吐量），利用 HTTP/3 獲得更好的性能。
