核心概念Robin講HTTP/3

寫在前面

前段時間，LiveVideoStack采訪了IETF貢獻者、HTTP/3和QUIC工作組成員Robin Marx，在采訪中，他向我們介紹了HTTP/3和QUIC帶來的優勢、設計HTTP/3時所遇到的挑戰、HTTP/3的采用問題以及他對互聯網未來發展的看法等等（對話Robin Marx：HTTP/3和QUIC將帶來重大機遇和挑戰）。

許多讀者在閱讀Robin的采訪后表示意猶未盡，想了解和學習更多關于HTTP/3和QUIC的知識。恰巧，Robin去年在Smashing Magazine上發表了一系列講解HTTP/3和QUIC的文章（原文鏈接： https://www.smashingmagazine.com/2021/08/http3-core-concepts-part1/）。因此，我們向Smashing Magazine和Robin本人申請翻譯該系列文章，并在未來一段時間依次將其發表在LiveVideoStack的平臺上，以饗讀者。 在這里，我們要特別感謝Smashing Magazine和Robin的慷慨授權。

所以在本文開始前，我們要向先大家介紹一下Smashing Magazine和Robin Marx。 Smashing Magazine既是一家技術網站，同時也是電子書出版商，專注于為網絡開發人員和網頁設計師提供高質量內容和專業資源。它由Sven Lennartz和Vitaly Friedman于 2006 年在德國創立。自 2012 年起，它開始在歐洲和北美舉辦網頁設計會議—— Smashing Conference。

Smashing Magazine（https://www.smashingmagazine.com/）

截至 2017 年 5 月，Smashing Magazine每月的頁面瀏覽量約為 300 萬，全球Twitter關注者接近100萬，并擁有29.5萬名Facebook粉絲，25.2萬名Feedly訂閱者，以及超過23萬名newsletter訂閱者。Smashing Magazine是最活躍和最大的Web開發資源出版商之一（數據來自Wikipedia）。

Robin Marx:IETF貢獻者、HTTP/3和QUIC工作組成員。2015年，作為PhD的一部分，Robin開始研究HTTP/2的性能，這使他后來有機會在IETF中參與HTTP/3和QUIC的設計。在研究這些協議的過程中，Robin開發了QUIC和HTTP/3的調試工具（被稱為qlog和qvis），目前這些工具已經使來自世界各地的許多工程師受益。今年8月，Robin將入職Akamai，成為一名解決方案架構師/網絡性能專家。

速覽：經過近五年的開發，新的HTTP/3協議終于接近尾聲。雖然作為實驗性功能的早期迭代早已可用，但HTTP/3的可用性和使用將在2021年進一步增加。所以到底什么是HTTP/3? 為什么在HTTP/2之后，這么快我們就需要HTTP/3？你應該（或可以）如何使用它？尤其是，HTTP/3如何提升網絡性能？讓我們來一一了解。

你也許已經讀過一些相關博客或者聽過這方面的演講，并認為自己知道上述問題的答案。你可能聽過這樣的說法：“當丟包時，HTTP/3比HTTP/2快多了”或“HTTP/3連接延遲更低，設置時間更短”或“HTTP/3能夠更快地發送數據，而且可以并行發送更多資源”。 這些說法和文章通常略過了關鍵的技術細節、缺乏對于技術細微差別的描述，而且并不完全正確。它們經常將HTTP/3描述為一場性能革命，但其實它是一次更加“溫和（但依然有用！）”的演進。這些關于HTTP/3的表述很危險，因為這一新的協議將可能無法在實際中符合這些高期望。我擔心，很多人最終會對HTTP/3感到失望，而新人將困惑于這些盲目存在的錯誤信息。 我之所以擔心，是因為HTTP/2也經歷過同樣的處境。當初HTTP/2被譽為一場驚人的性能革命，并擁有服務器推送（server push）、并行流（parallel stream）和優先級（prioritization）等激動人心的新功能。我們將停止打包資源、停止在多個服務器上sharding資源、并在很大程度上簡化頁面加載過程。只需輕輕一按，網站就能神奇地快上50%！ 五年后，我們知道，服務器推送在實際中并未起作用，并行流和優先級也經常無法得到很好的實現，因此（減少的）資源打包甚至是sharding在某些情況中依然是常用的做法。 同樣，其他調整協議行為的機制，比如預加載，通常含有隱蔽的細節和bug，導致它們很難正確使用。 因此，我認為對于HTTP/3來說，阻止這些錯誤信息和不切實際的期望的傳播很重要。 在本系列的文章中，我將討論新協議（尤其是它的性能特點）的更多細微差別。我將向你說明，雖然HTTP/3確實擁有一些備受期待的新概念，但遺憾的是，對于大部分網頁和用戶來說（除了對其中一小部分非常關鍵），它們的影響將很可能相對有限。HTTP/3的設置和使用（正確）也很具有挑戰性，所以配置新協議時一定要多加注意。

第一部分：HTTP/3的歷史和核心概念

這一部分針對不了解HTTP/3和其他一般協議的讀者，主要介紹基礎知識。

第二部分：HTTP/3 性能特點

這一部分更深入，技術內容更多。已經了解基礎知識的讀者可以從這里開始。

第三部分：實用的HTTP/3部署選項

系列中的第三部分解釋了自己部署和測試HTTP/3所遇到的挑戰。它詳細解釋了你應如何或者是否更改網頁或者資源。

注意：本系列主要目標讀者是那些還沒有深入了解協議知識并想進行學習的Web開發者。此外，本系列文章包含了豐富的技術內容和很多外部資源鏈接，同樣也適用于感興趣的高階讀者。

我們為什么需要HTTP/3？

我經常遇到的一個問題是：“在HTTP/2（在2015年才標準化）之后，我們為什么這么快就需要HTTP/3？”這的確很奇怪，直到你意識到，首先我們并不是真的需要一個新的HTTP版本，而是需要升級TCP（傳輸控制協議，Transmission Control Protocol ）。 TCP是向HTTP等協議提供可靠性和按順序發送等關鍵服務的主要協議。這也是我們一直和許多并發用戶一起使用互聯網的原因，因為TCP巧妙地將每個用戶的帶寬限制在他們的公平份額之內。

你知道嗎?

使用HTTP(S)時，你同時也在使用除HTTP之外的幾個協議。協議棧中的每個協議都有其自身的特點和功能（見下方圖片）。比如，HTTP處理URL和數據解析；TLS（Transport Layer Security）確保安全加密；TCP通過重傳丟包實現可靠數據傳輸；IP在中間的不同設備（中間件）上將數據包從一個端點傳送到另一個端點。

這種相互疊加的協議“分層”可以輕松重用它們的特性。高層協議（如HTTP）無需重新實現復雜特性（如加密），因為底層協議（如TSL）已經具備加密特性。除此之外，互聯網上大多數內部使用TCP的應用可以確保它們的數據獲得完整傳輸。正因如此，TCP成為互聯網上最廣泛使用和部署的協議之一。

HTTP/2 vs.HTTP/3協議棧對比 幾十年來，TCP一直是網絡的基礎，但在2000年后期開始初現老態。它預期中的替代品——新型傳輸協議QUIC，在很多關鍵處都與TCP大不相同，所以直接在其上運行HTTP/2將非常困難。因此，HTTP/3本身其實是對HTTP/2相對較小的更改，從而與新的QUIC協議（包括了大部分令人激動的新特性）兼容。 之所以需要QUIC，是因為TCP在互聯網早期時就已存在，但在開發它時并沒有考慮到最大效率。比如，TCP需要“握手”建立新的連接。這么做的目的是確保客戶端和服務端都存在，且它們愿意并能夠交換數據。TCP還需要一個完整的RTT，才能在連接上進行其他操作。如果客戶端和服務端的地理位置相距較遠，那么每個RTT都要超過100毫秒，因此會導致明顯的延遲。 其次，即使實際上我們正在通過TCP同時傳輸幾個文件（比如，當下載包含多個資源的網頁時），TCP依然將所有它傳輸的數據都看作單一“文件”或者“字節流”。這意味著如果包含單一文件的TCP數據包丟失，所有其他文件也將延遲，直到那些數據包被恢復。 上述現象被稱為“隊頭阻塞 [head-of-line (HoL) blocking]”。雖然這些低效操作在實際中可控（不然，我們也不會使用TCP長達三十余年），但它們明顯影響到了HTTP等高層協議。 隨著時間的推移，為了改進這些情況甚至推出新的性能特性，我們嘗試發展和升級TCP。比如，TCP快速打開（TFO，TCP Fast Open）使高層協議從最開始就可以發送數據，而避免了握手次數進而提升了效率。另一個是多通路TCP（MultiPath TCP），其中的原理是：你的移動手機通常包括Wi-Fi和（4G）蜂窩連接，所以為什么不同時使用它們來增加吞吐量和魯棒性呢？ 實現這些TCP擴展并不困難。不過，將它們實際大規模部署在互聯網上卻極具挑戰。因為，TCP太流行了，幾乎每個連接它的設備都有自己的TCP實現。如果這些實現過于陳舊、缺乏更新或者充滿bug，那么在實際中，這些TCP擴展將無法使用。換句話說，為了在實際中可以使用，所有實現都需要了解這些擴展。 如果只是涉及終端用戶設備（比如你的電腦或者Web服務器），上文所述不會成為太大的問題，因為這些設備可以相對輕松地通過手動升級。但是，客戶端和服務端之間存在許多其他設備，它們有其自己的TCP代碼（其中包括防火墻、負載均衡器、路由器、緩存服務器和代理等）。 想要升級這些中間件，通常非常困難，而且有時它們所接受的操作也更加嚴格。比如，如果設備是防火墻，它可能被配置為阻止所有包含（未知）擴展的流量。實際上事實證明，大量活躍的中間件都認定TCP不再適用新的擴展。 因此，要使足夠的TCP實現獲得更新（從而可以大規模使用這些擴展）將耗費多年甚至超過十年的時間。也可以說，TCP的發展在實際中不可行。 所以很明顯，我們需要一個TCP的替代協議，而不是直接升級TCP來解決問題。然而，由于十分復雜的TCP特性及其多種不同的實現，從零開始開發新的、更好的協議將會是一項艱巨的任務。因此，在2010初，這項工作被推遲了。 歸根結底，這些問題不僅存在于TCP，也同時存在于HTTP/1.1。我們選擇將這項工作拆分：先“修理”HTTP/1.1，使其成為現在的HTTP/2；完成之后，開始開發替換TCP的協議，也就是現在的QUIC。最初，我們希望在QUIC之上直接運行HTTP/2，但在實際中這將造成各類實現過于低效[主要是因為特性重復（feature duplication）]。 為了與QUIC兼容，HTTP/2在幾個關鍵領域進行了調整。這個調整的版本最終被命名為HTTP/3（而不是HTTP/2-over-QUIC），以此命名主要是從市場推廣和理解清晰的角度考慮。因此，HTTP/1.1和HTTP/2之間的差異要比HTTP/2和HTTP/3的差異大很多。

要 點

本文的關鍵要點：我們真正需要的并不是HTTP/3，而是“TCP/2”，只不過在這個過程中我們“免費”收獲了HTTP/3。HTTP/3中這些令人激動的主要特性（快速連接設置、減少的隊頭阻塞、連接遷移等等）實際上都是來自QUIC。

References:

https://www.ctrl.blog/entry/http2-push-chromium-deprecation.html https://github.com/andydavies/http2-prioritization-issues https://twitter.com/yoavweiss/status/1254650804524507136 https://twitter.com/zachleat/status/1055219667894259712 https://speeder.edm.uhasselt.be/webist/files/h2bestpractices_RobinMarx_WEBIST2017.pdf https://twitter.com/programmingart/status/1351557858354225159 https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/preload https://www.rfc-editor.org/rfc/rfc9000.html https://squeeze.isobar.com/2019/04/11/the-sad-story-of-tcp-fast-open/ https://developer.mozilla.org/en-US/docs/Glossary/TCP_handshake https://hpbn.co/http2/#design-and-technical-goals

審核編輯 ：李倩