核心概念Robin講HTTP/3

寫在前面

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

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

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

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

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

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

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

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

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

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

第二部分：HTTP/3 性能特點(diǎn)

這一部分更深入，技術(shù)內(nèi)容更多。已經(jīng)了解基礎(chǔ)知識(shí)的讀者可以從這里開始。

第三部分：實(shí)用的HTTP/3部署選項(xiàng)

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

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

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

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

你知道嗎?

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

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

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

要 點(diǎn)

本文的關(guān)鍵要點(diǎn)：我們真正需要的并不是HTTP/3，而是“TCP/2”，只不過在這個(gè)過程中我們“免費(fèi)”收獲了HTTP/3。HTTP/3中這些令人激動(dòng)的主要特性（快速連接設(shè)置、減少的隊(duì)頭阻塞、連接遷移等等）實(shí)際上都是來自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

審核編輯 ：李倩