性能和效率：使用 HTTP/3

已發表: 2022-03-11

HTTP/3 即將出現，緊隨 HTTP/2 之後——可以說它本身還很年輕。 鑑於從 HTTP/1.1 到 HTTP/2 花了 16 年時間，真的有人關心 HTTP/3 嗎？

簡短的回答：是的，這很重要，你應該跟上它的速度。 這就像 HTTP/2 如何通過從 ASCII 切換到二進制來對 HTTP/1.1 做出重大改變一樣。 HTTP/3 再次做出重大改變，這次是將底層傳輸從 TCP 切換到 UDP。

儘管 HTTP/3 仍處於設計階段，官方規範仍處於草稿階段，但它已經在部署中，您很有可能會在今天的網絡上找到它的一個版本。

但是 HTTP/3 的工作方式帶來了一些新的困境。 還有，有什麼好處？ 網絡工程師、系統管理員和開發人員需要知道什麼？

TL;博士

  • 更快的網站更成功。
    • HTTP/2 帶來了很大的性能提升，因為它解決了HTTP 線頭阻塞問題 (HOL) 。 它介紹了請求/響應多路復用、二進制幀、標頭壓縮、流優先級和服務器推送。
    • HTTP/3 甚至更快，因為它包含了所有 HTTP/2 並且還解決了TCP HOL 阻塞問題。 HTTP/3 仍然只是一個草案，但已經在部署中。 它更高效，使用更少的資源（系統和網絡），需要加密（SSL 證書是強制性的），並使用 UDP 。
  • 儘管 Web 瀏覽器可能會在一段時間內繼續支持舊版本的 HTTP，但搜索引擎對 HTTP/3 精通網站的性能優勢和優先級應該會推動新協議的採用。
  • SPDY 已過時，任何使用它的人都應該用 HTTP/2 替換它。
  • 今天的網站應該已經支持 HTTP/1.1 和 HTTP/2。
  • 在不久的將來，網站所有者可能也希望支持 HTTP/3。 然而，它比 HTTP/2 更具爭議性，我們可能會看到很多大型網絡只是簡單地阻止它，而不是花時間處理它。

主要問題：性能和效率

網站和應用程序開發人員通常以實際使用他們的創作為目的進行構建。 有時受眾群是有限的，但通常的想法只是為了獲得盡可能多的用戶。 自然，網站越受歡迎，它可以賺取的收入就越多。

網站加載時間延遲 100 毫秒可能會降低 7% 的轉化率。

Akamai 在線零售績效報告：毫秒至關重要（2017 年）

換句話說，一個每天銷售額為 40,000 美元的電子商務網站會因為這種延遲而每年損失 100 萬美元。

網站的性能對於網站變得更受歡迎絕對至關重要，這也不是什麼秘密。 在線購物研究繼續發現跳出率增加與加載時間延長之間的聯繫，以及購物體驗期間購物者忠誠度與網站性能之間的聯繫。

研究還發現：

  • 47% 的消費者希望網頁在 2 秒或更短的時間內加載。
  • 40% 的人會放棄加載時間超過 3 秒的網站。

這就是十多年前在線購物者的耐心狀態。 所以性能至關重要，HTTP/2 和 HTTP/3 都意味著更好的網站性能。

HTTP/2？ …那是什麼？

對 HTTP/2 協議的良好理解對於理解 HTTP/3 至關重要。 首先，為什麼需要 HTTP/2？

HTTP/2 最初是一個名為 SPDY 的 Google 項目，一項研究報告稱，網絡上最大的性能問題是延遲。 作者得出的結論是“更多的帶寬並不重要（多）”：

如果我們將管道和互聯網進行類比，我們可以認為互聯網的帶寬就像水管的直徑。 較大的管道攜帶更多的水，因此您可以在兩點之間輸送更多的水。

同時，不管你的管子有多大，如果管子是空的，你想把水從一個點引到另一個點，水流過管子需要時間。 用互聯網的話來說，水從管道的一端到另一端並再次返回所需的時間稱為往返時間，或RTT 。

邁克·貝爾什

在這項研究中，目標是減少頁面加載時間。 它表明增加帶寬最初會有所幫助，因為從 1 Mbps 到 2 Mbps 會使頁面加載時間減半。 然而，收益很快就趨於平穩。

頁面加載時間與帶寬和延遲。對於 1 Mbps 連接，加載時間從超過 3 秒開始，對於帶寬為 4 Mbps 及以上的連接，加載時間在略低於 1,500 毫秒的穩定期。相比之下，加載時間幾乎隨延遲線性減少，從大約 3,400 毫秒（延遲 200 毫秒）到大約 1,100 毫秒（延遲 20 毫秒）。

相比之下，減少延遲有一個持續的好處，並取得了最好的結果。

HTTP HOL：行頭阻塞問題

HTTP/1 協議中延遲的主要原因是行頭阻塞問題。 網頁（幾乎總是）需要多個資源：CSS、JavaScript、字體、圖像、AJAX/XMR 等。這意味著 Web 瀏覽器需要向服務器發出多個請求。 但是，並非所有資源都需要頁面變得有用。

對於 HTTP/1.0，瀏覽器必須在開始下一個請求之前完全完成一個請求，包括完全接收響應。 一切都必須按順序進行。 每個請求都會阻塞請求行，因此得名。

為了彌補 HOL 阻塞問題，Web 瀏覽器與單個服務器同時建立多個連接。 但他們不得不任意限制這種行為：服務器、工作站和網絡可能會因連接過多而過載。

HTTP/1.1 引入了一些改進來幫助解決這個問題。 主要的一個是流水線，允許 Web 瀏覽器啟動新請求，而無需等待先前的請求完成。 這顯著改善了低延遲環境中的加載時間。

但是它仍然要求所有響應都按照它們產生的順序依次到達，所以行首仍然被阻塞。 令人驚訝的是，許多服務器仍然沒有利用此功能。

HTTP/1.1 流水線與常規 HTTP 請求的比較。常規請求具有完全串行完成的三個請求-響應往返。流水線方法總體上要快一些，因為客戶端連續發送三個請求，而無需等待它們之間的響應。但是它仍然存在線頭阻塞問題，因為必須按順序發送響應。

有趣的是，HTTP/1.1 還引入了keep-alive ，它允許瀏覽器避免為每個 HTTP 請求創建新的 TCP 連接的開銷。 這是解決 TCP 衍生的性能問題的早期嘗試。 它是如此無效，以至於大多數性能專家實際上不鼓勵它，因為它會因過多的非活動連接而使服務器陷入困境。 我們將在下面仔細研究 TCP，以及 HTTP/2 如何解決此問題。

HTTP/2 的 HTTP HOL 阻塞解決方案

HTTP/2 在單個連接上引入了請求-響應多路復用。 瀏覽器不僅可以隨時啟動新請求，而且可以按任何順序接收響應——在應用程序級別完全消除了阻塞。

HTTP/2 與 SPDY 的多路復用，與上圖中描述的普通和啟用管道的 HTTP/1.1 相比。多路復用顯示客戶端的請求發送得更快，並且它的第一個請求在其第二個和第三個請求的響應之後發送了相應的響應。總體而言，總的通信時間因此顯著縮短。

直接結果是，這意味著支持 HTTP/2 的 Web 服務器可以最大限度地提高效率——稍後會詳細介紹。

儘管請求-響應多路復用是 HTTP/2 的主要特性，但它還包括其他幾個重要特性。 讀者可能會注意到它們都有些相關。

HTTP/2 二進制幀

HTTP/2 將 HTTP 協議標準從低效的人類可讀 ASCII 請求-響應模型轉換為高效的二進制幀。 它不再只是請求和響應：

通過 HTTP 2.0 的客戶端-服務器連接。客戶端同時通過流 5 發送數據，同時服務器按此順序發送流 1 數據、流 3 標頭、流 3 數據、流 1 數據等。

使用 HTTP/2，瀏覽器通過具有多個消息的雙向流與服務器通信，每個消息由多個幀組成。

HTTP/2 HPACK（標頭壓縮）

HTTP/2 的新標頭壓縮，使用 HPACK 格式，為大多數站點節省了大量帶寬。 這是因為在連接中發送的請求的大多數標頭都是相同的。

HPACK 在行動。第一個請求，指定字段的值 :method、:scheme、:host、:path、accept 和 user-agent，按原樣發送。第二個請求有幾個字段——那些與第一個請求中的相應字段相同的字段——被剝離，因為它們的值隱含地是前一個請求的值。生成的請求要小得多，只包含 :path 的值。

Cloudflare 報告說，僅 HPACK 就可以顯著節省帶寬：

  • 入口標頭壓縮 76%
  • 總入口流量減少 53%
  • 出口標頭壓縮 69%
  • 總出口流量減少 1.4% 至 15%

當然，使用更少的帶寬通常意味著更快的網站。

HTTP/2 流優先級和服務器推送

這就是 HTTP/2 的多路復用真正讓服務器最大化效率的地方。 多路復用確實有助於在較慢的資源（例如，大圖像、數據庫生成的 JSON 等）之前提供更快的資源（例如，內存緩存的 JavaScript）。 但它也允許通過 HTTP/2 的流優先級來進一步提升性能。

流優先級有助於確保頁面的幾乎準備就緒的方面完全完成，而無需等待其他資源密集型請求完成。 這是通過加權依賴樹完成的。 該樹用於通知服務器應該分配最多系統資源來服務的響應。

這對於漸進式 Web 應用程序 (PWA) 尤其重要。 例如，假設一個頁面有四個 JavaScript 文件。 兩個用於頁面功能，兩個用於廣告。 最壞的情況是加載一半的功能 JS 和一半的廣告 JS，然後繼續加載大圖像，然後再加載任何剩餘的 JS。 在這種情況下，頁面上的任何內容最初都無法正常工作，因為一切都必須等待最慢的資源。

通過流優先級，Web 瀏覽器可以指示服務器在發送任何廣告 JavaScript 文件之前發送兩個頁面功能 JS 文件。 這樣用戶就不必等待廣告完全加載後才能使用頁面的功能。 儘管整體加載時間沒有改善，但感知性能已顯著提高。 不幸的是，Web 瀏覽器中的這種行為仍然主要是算法問題，而不是 Web 開發人員指定的東西。

同樣，HTTP/2 的服務器推送功能允許服務器向瀏覽器發送尚未發出的請求的響應！ 服務器可以利用傳輸間隙，通過將服務器知道它將很快請求的資源預加載到瀏覽器中來有效地使用帶寬。 這裡的部分希望是消除資源內聯的做法，這只會使資源膨脹並使其加載時間更長。

不幸的是，這兩個功能都需要 Web 開發人員進行大量仔細配置才能真正成功。 僅僅啟用它們是不夠的。

HTTP/2 顯然帶來了許多潛在的優勢——其中一些優勢比其他優勢更便宜。 他們在現實世界中的表現如何？

HTTP 與 HTTP/2 的採用

SPDY 創建於 2009 年。HTTP/2 於 2015 年標準化。SPDY 成為代碼不穩定開發分支的名稱，HTTP/2 成為最終版本。 結果就是 SPDY 已經過時了，而 HTTP/2 通常是每個人都遵循的標準。

標準化後，HTTP/2（或“h2”）的採用率迅速增長到前 1000 個網站的 40% 左右。 這主要是由代表客戶部署支持的大型託管和雲提供商推動的。 不幸的是，幾年後，HTTP/2 的採用速度放緩，大多數互聯網仍然使用 HTTP/1。

缺乏對 HTTP/2 明文模式的瀏覽器支持

有很多人呼籲 HTTP/2 將加密作為標準的必需部分。 相反，該標准定義了加密 (h2) 和明文 (h2c) 模式。 因此，HTTP/2 可以完全取代 HTTP/1。

儘管有標準，所有當前的網絡瀏覽器都只支持通過加密連接的 HTTP/2，並且故意不實現明文模式。 相反，瀏覽器依賴 HTTP/1 向後兼容模式來訪問不安全的服務器。 這是在默認情況下使網絡安全的意識形態推動的直接結果。

為什麼選擇 HTTP/3？ 它有什麼不同？

隨著 HTTP/2 現在解決了 HTTP 的線頭阻塞問題，協議開發人員將注意力轉向了下一個最大的延遲驅動因素： TCP的線頭阻塞問題。

傳輸控制協議 (TCP)

IP（互聯網協議）網絡基於計算機相互發送數據包的想法。 數據包只是頂部附加一些尋址信息的數據。

但是應用程序通常需要處理數據流。 為了實現這種錯覺，傳輸控制協議 (TCP) 為應用程序提供了一個管道，數據流可以通過該管道流動。 與大多數管道一樣，可以保證數據將以與輸入相同的順序退出管道，也稱為“先進先出”（FIFO）。 這些特性使 TCP 非常有用並被廣泛採用。

作為 TCP 提供的數據傳輸保證的一部分，它必須能夠處理各種各樣的情況。 最複雜的問題之一是如何在網絡過載時提供所有數據，而不會使每個人的情況變得更糟。 用於此的算法稱為擁塞控制，是互聯網規範中不斷發展的一部分。 如果沒有足夠的擁塞控制，互聯網就會陷入停頓。

86 年 10 月，互聯網首次出現了一系列“擁塞崩潰”。 在此期間，從 LBL 到 UC Berkeley（站點相距 400 碼和三個 IMP 躍點）的數據吞吐量從 32 Kbps 下降到 40 bps。

五、雅各布森 (1988)

這就是 TCP 線頭阻塞問題的來源。

TCP HOL 阻塞問題

TCP 擁塞控制通過實現數據包的退避和重傳機制來工作，每當檢測到數據包丟失時使用。 退避旨在幫助穩定網絡。 重傳確保數據最終被傳遞。

這意味著 TCP 數據可能會亂序到達目的地，接收方有責任在將數據包重新組合到流中之前對其進行重新排序。 不幸的是，這意味著一個丟失的數據包可能會導致整個 TCP 流在服務器等待重新傳輸時暫停。 因此，該行的頭部被阻塞。

谷歌的另一個項目旨在通過引入一種稱為 QUIC 的協議來解決這個問題。

TCP HOL 通過 HTTP/2 連接阻塞。正在發送一個紅色和幾個綠色和藍色的數據包，但是一個紅色的數據包丟失，導致綠色和藍色數據包的阻塞。

QUIC 協議建立在 UDP 而不是 TCP 之上，QUIC 正在形成 HTTP/3 的基礎。

什麼是 UDP？

用戶數據報協議 (UDP) 是 TCP 的替代方案。 它不提供流的錯覺或 TCP 提供的相同保證。 相反，它只是提供了一種簡單的方法來將數據放入數據包中，將其尋址到另一台計算機，然後發送。 它是不可靠的、無序的，並且沒有任何形式的擁塞控制。

它的目的是輕量級並提供允許通信所需的最少功能。 這樣，應用程序可以實現自己的保證。 這在實時應用程序中通常非常有用。 例如，在電話通話中，用戶通常更願意立即收到 90% 的數據，而不是最終收到 100% 的數據。

HTTP/3 的 TCP HOL 解決方案

解決 TCP HOL 阻塞問題需要的不僅僅是切換到 UDP，因為仍然需要保證所有數據的傳遞並避免網絡擁塞崩潰。 QUIC 協議旨在通過提供優化的 HTTP over UDP 類型的體驗來完成所有這些工作。

由於 QUIC 接管了流管理、二進制幀等的控制權，因此在 QUIC 之上運行時，HTTP/2 所要做的事情已經不多了。 這是將 QUIC + HTTP 的新組合標準化為 HTTP/3 的部分驅動因素。

QUIC OSI 模型，以 IP 為基礎，在其上構建了兩個堆棧。左側的 HTTP 協議棧在 IP 之上添加了 TCP、TLS 和 HTTP/2。右側的 HTTP 協議棧在 IP 之上添加了 UDP、一個特殊塊和“HTTP over QUIC”。特殊塊包含 QUIC 和類似 TCP 的擁塞控制和丟失恢復，其中包含一個用於 QUIC 加密的單獨塊。

注意：QUIC 有很多版本，因為該協議已經在生產環境中開發和部署多年。 甚至還有一個名為 GQUIC 的特定於 Google 的版本。 因此，區分舊的 QUIC 協議和新的 HTTP/3 標準很重要。

始終加密

HTTP/3 包含大量從 TLS 借用但不直接使用它的加密。 HTTP/3 的主要實現挑戰之一是需要修改 TLS/SSL 庫以添加新需要的功能。

此更改是因為 HTTP/3 在加密內容方面與 HTTPS 不同。 使用較舊的 HTTPS 協議，只有數據本身受 TLS 保護，許多傳輸元數據可見。 在 HTTP/3 中，數據和傳輸協議都受到保護。 這聽起來像是一項安全功能，而且確實如此。 但這樣做是為了避免 HTTP/2 中存在的大量開銷。 因此，對傳輸協議和數據進行加密實際上可以提高協議的性能。

HTTPS over TCP+TLS 與 QUIC 的比較。 TCP+TLS 在發送方和負載均衡器之間完全按順序進行通信，包括三個初始往返，重複連接需要 200 毫秒，如果發送方以前從未與服務器通信，則需要 300 毫秒。相比之下，QUIC 在發送其主要數據並接收響應之前有一個初始發送，這意味著重複連接的開銷為零，如果發送者以前從未與服務器交談過，則只有 100 毫秒。

HTTP/3 對網絡基礎設施的影響

HTTP/3 並非沒有爭議。 主要關注點是網絡基礎設施。

客戶端 HTTP/3

在客戶端，UDP 流量受到嚴重的速率限制和/或阻塞是很常見的。 將這些限制應用於 HTTP/3 違背了協議的要點。

其次，HTTP 被監視和/或攔截是很常見的。 即使使用 HTTPS 流量，網絡也會定期觀察協議的明文傳輸元素，以確定它們是否應該放棄連接，以防止從特定網絡或特定區域內訪問某些網站。 在某些國家/地區，法律甚至規定某些服務提供商必須這樣做。 HTTP/3 中的強制加密使這成為不可能。

這不僅僅是政府級別的過濾。 許多大學、公共圖書館、學校和家長關心的家庭積極選擇阻止訪問某些網站，或者至少保留訪問過哪些網站的日誌。 HTTP/3 中的強制加密使這成為不可能。

值得注意的是，目前可以進行有限過濾。 這是因為服務器名稱指示 (SNI) 字段（包含網站的主機名，但不包含路徑、查詢參數等）仍未加密。 但隨著 ESNI（加密 SNI）的引入，這將在不久的將來發生變化，該 SNI 最近被添加到 TLS 標準中。

服務器端 HTTP/3

在服務器端，最好的做法是阻止任何不期望流量的端口和協議，這意味著服務器管理員現在需要為 HTTP/3 打開 UDP 443，而不是依賴於他們現有的 TCP 443 規則。

其次，網絡基礎設施可以使 TCP 會話具有粘性，這意味著即使路由優先級發生變化，它們也將始終路由到同一台服務器。 由於 HTTP/3 在無會話的 UDP 上運行，因此需要更新網絡基礎設施以跟踪特定於 HTTP/3 的連接 ID，這些連接 ID 未加密專門用於幫助粘性路由。

第三，檢查 HTTP 以檢測濫用、監控常見安全問題、檢測和防止惡意軟件和病毒的傳播等是很常見的。由於 HTTP/3 的加密，這是不可能的。 儘管如此，假設設備實現 HTTP/3 支持，攔截設備具有安全密鑰副本的選項仍然是可能的。

最後，許多管理員反對必須管理更多的 SSL 證書，儘管現在有了 Let's Encrypt 等服務可用，這已經不是問題了。

在有廣泛接受的、眾所周知的解決方案來解決這些問題之前，我認為很多大型網絡很可能會簡單地阻止 HTTP/3。

HTTP/3 對 Web 開發的影響

在這方面沒有太多可擔心的。 HTTP/2 的流優先級和服務器推送功能仍然存在於 HTTP/3 中。 如果 Web 開發人員想要真正優化其網站性能，那麼熟悉這些功能是值得的。

立即使用 HTTP/3

Google Chrome 或開源 Chromium 瀏覽器的用戶已經準備好使用 HTTP/3。 HTTP/3 服務器的生產質量版本還有一段路要走——在撰寫本文時，規範還沒有完全確定。 但與此同時，有很多工具可供使用，谷歌和 Cloudflare 都已經將支持推向了他們的生產環境。

最簡單的嘗試方法是在 Docker 中使用 Caddy。 為此需要 SSL 證書，因此可公開訪問的 IP 地址使事情變得容易。 步驟是：

  1. DNS 設置。 獲取一個在 Internet 上運行的有效主機名，例如yourhostname.example.com IN A 192.0.2.1 。
  2. 球童文件創建。 它應該包含以下幾行：
 yourhostname.example.com log stdout errors stdout ext .html .htm .md .txt browse gzip tls [email protected]
  1. 運行 Caddy： docker run -v Caddyfile:/etc/Caddyfile -p 80:80 -p 443:443 abiosoft/caddy --quic — 或在 Docker 外部， caddy --quic 。
  2. 在啟用 QUIC 的情況下運行 chromium： chromium --enable-quic
  3. （可選）安裝協議指示器擴展。
  4. 導航到啟用 QUIC 的服務器，文件瀏覽器應該可見。

開發人員還可以使用以下有用的工具測試他們的服務器：

  • Keycdn 的 HTTP/2 測試
  • LiteSpeed 的 HTTP3Check
  • Qualys 的 SSL 服務器測試

謝謝閱讀！

Google Cloud 合作夥伴徽章
作為 Google Cloud 合作夥伴，Toptal 為公司提供開發解決方案，並在其云之旅的每個階段與他們合作。