核心概念Robin講HTTP/3

寫在前面

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

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

所以在本文開始前，我們要向先大家介紹一下Smashing Magazine和Robin Marx。 Smashing Magazine既是一家技術網站，同時也是電子書出版商，專注于為網絡開發(fā)人員和網頁設計師提供高質量內容和專業(yè)資源。它由Sven Lennartz和Vitaly Friedman于 2006 年在德國創(chuàng)立。自 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開發(fā)資源出版商之一（數(shù)據(jù)來自Wikipedia）。

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

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

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

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

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

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

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

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

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

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

我們?yōu)槭裁葱枰狧TTP/3？

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

你知道嗎?

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

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

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

審核編輯 ：李倩