基準測試：HTTP/3 有多快？ - requestmetrics

為了瞭解 HTTP/3 產生什麼樣的效能差異，需要一個基準測試設定。

為了更接近實際使用情況，測試設定由三個場景組成 - 一個小站點、一個內容豐富的站點（大量影像和一些 JS）和一個單頁面應用程式（在 JS 上很重）。我檢視了幾個真實世界的站點，並對每個站點的影像和 JS 檔案的數量求平均值，然後編寫了一些與這些資源數量（和大小）匹配的演示站點。

HTML

• 小型站點
  • 10 個2kb 到 100kb 的 JS 檔案
  • 從 1kb 到 50kb 的10張影像
  • 總有效載荷大小600kb，總共 20 個阻塞資源
• 內容站點
  • 50 個2kb 到 1mb 的 JS 檔案
  • 55張大小從 1kb 到 1mb 的影像。
  • 總有效負載大小10MB，總共 105 個資源（有時在開發工具中檢視 cnn.com，您會明白為什麼它如此之大）
• 單頁應用程式
  • 從 2kb 到 1mb 的85 個JS 檔案
  • 30張大小從 1kb 到 50kb 的影像。
  • 總有效負載大小15MB，總共 115 個資源（有時在開發工具中檢視 JIRA）

伺服器

Caddy用於提供所有資產和 HTML。

• 提供所有響應Cache-Control: "no-store"以確保瀏覽器每次都會重新下載。
• TLS 1.2 用於 HTTP/1.1 和 HTTP/2
• TLS 1.3用於 HTTP/3。
• 為所有 HTTP/3 連線啟用了0-RTT

客戶端

讓瀏覽器自動連續請求同一頁面 20 次，在頁面載入後等待 3 秒開始下一個請求。網際網路連線的額定速度為 200mbps。資料捕獲時，計算機上沒有執行其他應用程式。

測試地點

測試是從我在明尼蘇達州的計算機到由 Digital Ocean 託管的三個獨立資料中心進行的：

• 美國紐約，相比Http2：

  小型站點快200 毫秒

  內容站點快325 毫秒

  單頁應用程式快300 毫秒

• 倫敦，英國，相比http2:

  小型站點快600 毫秒（與紐約相比，速度提高了3 倍）

  1200ms（以上為內容網站更快的3.5倍與紐約相比的加速）

  單頁應用程式快1000 毫秒（與紐約相比，速度提高了3 倍以上）

• 印度班加羅爾：當涉及更大的地域和更多的網路躍點時，HTTP/3 繼續領先。也許更引人注目的是 HTTP/3 的響應時間分組的緊密程度。當資料包傳輸數千英里時，QUIC 會產生很大的影響。

結論

在任何情況下，HTTP/3 都比HTTP/2更快！

為什麼 HTTP/3 這麼快？

• 真正的多路複用

HTTP/3 真正的多路複用特性意味著堆疊中的任何地方都不會發生行頭阻塞。當從更遠的地方請求資源時，在地理上，資料包丟失的可能性要高得多，並且 TCP 需要重新傳輸這些資料包。

• 0-RTT 是遊戲規則的改變者

此外，HTTP/3 支援O-RTT QUIC 連線，這降低了與伺服器建立安全 TLS 連線所需的往返次數。