對話Robin Marx：HTTP/3和QUIC將帶來重大機遇和挑戰_LiveVideoStack

策劃、翻譯：Alex

技術審校：劉連響

人物對話 #004#

6月7日，IETF貢獻者、HTTP/3和QUIC工作組成員Robin Marx在推特上宣佈：“歷時五年，HTTP/3終於被標準化為RFC 9114！”

圖片來源：推特

這是網際網路的重要時刻。

作為HTTP的最新版本，HTTP/3將帶來重大機遇和挑戰。

為了更好地理解這一新發布的標準，LiveVideoStack邀請了Robin Marx加入我們的訪談，請他來跟大家詳細聊聊HTTP/3。

照片由Robin Marx本人提供

2015年，作為PhD的一部分，Robin開始研究HTTP/2的效能，這使他後來有機會在IETF中參與HTTP/3和QUIC的設計。在研究這些協議的過程中，Robin開發了QUIC和HTTP/3的除錯工具（被稱為qlog和qvis），目前這些工具已經使來自世界各地的許多工程師受益。

在這次郵件採訪中，Robin談論了HTTP/3和QUIC帶來的優勢、設計HTTP/3時所遇到的挑戰、HTTP/3的採用問題以及他對網際網路未來發展的看法。

Robin還告訴了我們他是如何踏上“協議之路”的，並談到了他對即將入職Akamai公司的期待。

以下是LiveVideoStack和Robin Marx的對話。

LiveVideoStack： 你好，Robin。非常感謝你能來到我們的人物對話欄目。在正式訪談開始之前，你可以先簡單介紹一下自己嗎？

Robin Marx： 非常高興參與這次的訪談！2015年，作為我PhD學業的一部分，我開始研究HTTP/2效能，並參與到網路協議的相關工作中。這次研究為我提供了寶貴的機會，使我後來可以在IETF（Internet Engineering Task Force，網際網路工程任務組）中參與HTTP/3和QUIC的設計。我專門開發了一系列除錯和測試工具（被稱為qlog和qvis），這些工具對於協議的實戰測試實現很有幫助，並發現了協議規範中的很多bug和問題。過去所積累的一切最終使我獲得了一份Akamai提供的解決方案架構師/網路效能專家的工作，我將在今年8月份入職。

HTTP/3和QUIC

LiveVideoStack： 與HTTP/2相比，HTTP/3中有哪些重大改進？

圖片由Robin提供

Robin Marx： 作為網路協議，HTTP/3其實和HTTP/2非常相似，它提供相同的特性，如頭部壓縮（header compression）、伺服器推送（server push，雖然依然不推薦普遍使用）、資料流優先順序（stream prioritization，儘管以一種更簡單、更易用的使用方式）。最主要的變化是HTTP的底層協議：HTTP/2所使用是TCP+TLS，而HTTP/3使用的是QUIC——這是一個與TLS深度整合的新型傳輸協議。相較於HTTP/2，QUIC和TLS的使用為HTTP/3提供了很多優勢，尤其是在（網頁載入）效能方面。

首先，QUIC擁有更快的連線設定，原因是它將傳輸層握手（TCP的SYN+SYN/ACK+ACK bootstrap）和加密握手（TLS設定）合併到一次RTT中（而HTTP/2需要2~3個RTT）。除此之外，HTTP/3可以受益於TLS 1.3的0-RTT特性，意味著可以傳送HTTP請求，並能夠在第一次握手期間接收到（部分）響應。尤其當客戶端和伺服器在地理上相距遙遠時，快速連線十分有幫助。

圖片由Robin提供

其次，QUIC使用了HTTP/2中的多路複用概念，並將它應用到傳輸協議層。這一點在技術上不太好理解，不過結果就是QUIC（也指HTTP/3）對於丟包和重新排序的恢復能力得到了提升。這解決了TCP長期存在的“隊頭阻塞”問題：其中HTTP/2連線上的一個丟包就可能導致其後的資料在等待重傳的時候遭到阻塞。在某些情況下，HTTP/3可以解決某些資料的阻塞，以便更早地處理、提交或者執行這些資料。

再次，QUIC還有很多其他效能上的優勢。比如，新的“連線遷移”特性將使切換網路（如從Wi-Fi切換到4G）更加無縫（雖然目前少有部署支援）。QUIC在如何確認接收的資料包方面也更加智慧，從而更容易決定如何/何時重傳丟失的資料包並調整擁塞控制邏輯。這一優勢對於HTTP/3並沒有太大用處，但是它可以允許其他協議（比如WebTransport或者MASQUE代理）在QUIC之上執行。

總結一下，HTTP/3主要受益於重要的新型QUIC協議，並將隨著不斷新增新的優化和特性而繼續獲益。

LiveVideoStack： 對於那些將要配置該協議的人，你有什麼建議嗎？

Robin Marx: 因為它的一些高階特性和基於0-RTT的安全策略以及負載均衡，HTTP/3和QUIC是出了名的複雜。在這一點上，我強烈建議你不要自己部署HTTP/3，而是選擇大型CDN公司（如Akamai、Cloudflare或者Fastly）已有的部署。很快，你將能夠使用AWS和Azure中開箱即用的HTTP/3，到那時，它應該已經成為谷歌託管選項了。

LiveVideoStack： HTTP/3會影響到上層的應用嗎？上層應用會做更改嗎？

Robin Marx: HTTP/3與HTTP/2太相似了，所以網站想在HTTP/3上正常執行幾乎不需要任何更改。這與我們從HTTP1.1遷移到HTTP/2非常不同，後者通常需要進行大量的更改。

對於應用程式（以原生應用為例）來說，你將為了HTTP/3（通常也包括QUIC的實現）而使用完全不同的軟體庫。這裡我會推薦Cloudflare的quiche、ngtcp2或quickly，它們全部開源並且在GitHub上都能找到。在一些不常見的場景中，你可以使用一個內建平臺實現：iOS/OSX已經在它的網路庫中支援了HTTP/3和QUIC（請參見：

http://developer.apple.com/videos/play/wwdc2021/10094），而.NET在其最新版本中也有了HTTP/3和QUIC的初步實現。

如果你只是想通過HTTP/3或者QUIC傳送、接收一些資料，那麼使用上述實現應該不會太難。不過當你真的想為了優化高階效能（如0-RTT或者連線遷移）而調整應用時，情況就會變得困難起來。為此，你需要真正理解HTTP/3和QUIC的工作原理、它們的侷限性以及如何從各類實現的API中正確啟動它們。這個時候你就得拿出幾天時間深入研究原始碼了。（笑）

LiveVideoStack： 對於其他應用場景，比如視訊流媒體，QUIC意味著什麼？它與WebRTC相比如何？新的WebTransport呢？

Robin Marx: 因為QUIC是一個通用傳輸協議，所以我們確實可以在更多的應用場景使用它（而不僅僅將它用於網頁載入）。IETF中有一個特殊的“Media over QUIC”工作組正在認真思考視訊傳輸（包括直播和點播）問題。然而，目前還不清楚如何能夠/應該/將會以最佳方式實現，因為該領域中現有的產品（如WebRTC）已經相當強大並獲得廣泛部署，而QUIC是否（如何）將帶來更多優勢也未可知。除此之外，僅將現有的協議執行在新的QUIC上也相當困難，這些協議通常都需要某些更改。目前還在非常早期的階段，但是學術界已經展示了一些有趣的概念：比如將可靠（關鍵幀）和非可靠（delta壓縮幀）視訊資料在單一QUIC連線中合併。我想我們將不會看到WebRTC-over-QUIC，但是未來肯定會出現它的替代。

WebTransport是另一個有趣的方向，目的是向Web開發者展示更廣泛的網路特性。雖然我們在網頁中被限制在HTTP（通過fetch()）或者長連線（通過WebTransport），但WebTransport將允許對網路效能進行更底層的訪問。我們仍舊不能傳送裸的UDP資料，但WebTransport至少允許在多人遊戲以及自定義流媒體方面做更多的優化。

LiveVideoStack： 你一直在為QUIC和HTTP/3協議開發除錯工具，你可以向我們介紹一下這些工具嗎？對工程師而言，這些工具會帶來哪些幫助？

Robin Marx: 我所開發的主要工具都在一個被稱為qvis的合集中，你可以在http://qvis.quictools.info/ 上檢視。這是一組視覺化工具，它們顯示了跨協議層的擁塞控制、流多路複用和具體分包等高階特性。我已經發現，對於這些複雜的特性而言，Wireshark這種成熟的工具還沒有強大到足以為協議實現者和底層調優人員提供快速和可操作的幫助。對於一般使用者來說，我希望他們永遠不會用到Wireshark，不過那樣的話，qvis對他們來說也會變得更加遙遠。

另一個需要著重注意的地方是，qvis使用了一個專門針對QUIC和HTTP/3的資料logging格式：qlog （qlog為qvis抓包格式：http://github.com/quicwg/qlog），而非標準的抓包格式（.pcap檔案）。這麼做主要有兩個原因：第一、QUIC在傳輸層被深度加密，如果不解密，封包號碼等資訊就無法檢視（與TCP非常不一樣）；第二、抓包不包括當前擁塞控制視窗、預估往返時間和丟包標記原因等資訊。通過讓端點（客戶端和伺服器）直接記錄這些深度資訊，我們能夠建立更加強大的工具，用來幫助除錯實現方式，並避免在部署場景中解密抓包（不僅可以獲取QUIC資料包的元資料，還可以獲取密碼等使用者個人資訊）。因此，qlog為網路內抓包提供了一個保護隱私且更加強大的替代方案。目前，IETF正在將它進行標準化。

挑戰和未來

LiveVideoStack： 你們在設計HTTP/3時面臨的最大挑戰是什麼？最終是是如何克服的？

Robin Marx： 最初，我們本來打算將HTTP/2稍作更改直接執行在QUIC之上。但當我們這樣嘗試的時候，很快發現HTTP/2對TCP的工作方式做出了太多假設，而這些假設在QUIC中發生了變化。最主要的變化就是隊頭阻塞問題；雖然它導致了資料傳輸的低效，但是也保證了所有資料按照發送時的準確順序到達。而在QUIC中，這種保證卻不復存在：如果傳送方傳送了資料包A和資料包B，第二個資料包B很可能在資料包A之前被傳送給接收方應用程式。這種情況與HTTP/2的很多假設都不符，所以我們不得不重新設計其中的很多底層機制，從而可以在HTTP/3中提供相同的高階特性。QPACK頭部壓縮設定和優先順序系統是兩個幾乎完全重新設計的系統，而如何處理後者實際上也是我PhD研究的主要內容。

對於QUIC來說，當時必須解決的挑戰非常多。這耗費了相當長的時間，來自谷歌、Facebook（現更名為Meta）、微軟和Mozilla等各大網際網路公司才能卓越的工程師們進行了多次討論。比如，我們當時的一個目標是儘量縮小協議開銷（協議元資料而非實際使用者資料的資料量），而我們通過在很多地方使用巧妙的壓縮技術實現了它，這些地方包括：從“可變長度整數編碼（Variable-Length Integer Encoding）”到“如何傳送確認”以及“QUIC如何將64位的封包號編碼為一個位元組（對大多數資料包來說）”。我還想到一件事，QUIC對每個資料包進行了兩次加密：一次用於負載，一次用於資料包頭。這裡主要需要在連線週期（對於長時間執行的對話非常重要）內新增對更新加密金鑰的支援，為此我們耗費了相當長的時間。

LiveVideoStack： 雖然HTTP/3採用在不斷增長，但是依然面臨很多重大挑戰。你可以跟我們談談這些挑戰嗎？

Robin Marx： 正如我之前所說，正確、安全地設定和配置HTTP/3和QUIC極其複雜。有幾家大公司為此付出了巨大努力，現在他們將它作為一種易用的商業服務提供。然而，讓小公司或者個人自己部署HTTP/3和QUIC將需要相當長的時間才能實現（至少如果你想使用0-RTT、連線遷移或強大的負載均衡等高階特性的話）。

除此之外，許多網路管理員仍在猶豫是否要將QUIC部署在他們的網路之上。這其中有兩個原因：

首先，QUIC之所以部署在UDP之上，主要就是為了更容易地部署在網際網路上（大部分中介軟體已經熟悉UDP，但卻不知道如何處理QUIC直接執行在IP協議上的情況）。然而，UDP經常遭受各種（阻斷服務）攻擊，許多允許它的網路也僅用於少數幾個應用場景（如DNS）。雖然QUIC集成了大部分已知UDP攻擊的緩解措施（比如內建的放大攻擊限制），但大部分網路管理員對於部署缺乏適當防火牆支援的QUIC依然猶豫不決。由於協議的複雜性，防火牆廠商也一直在支援上行動緩慢；而且如果QUIC被阻止，大部分終端使用者軟體（如瀏覽器）就會自動回退到HTTP/2。

其次，QUIC加密了太多的資料包元資料，所以很難（無法）為QUIC流量提供TCP式的防火牆或者網路健康追蹤服務（如追蹤往返時間或者丟包統計）。因此，網路所有者將會在很大程度上失去對於允許哪種型別的網路連線的控制，並且在沒有額外步驟（比如，這裡qlog可以提供幫助，但為了提取資料需要與內部伺服器端點互動，TCP則不需要這種操作）的情況下，引導此流量的選項也會少很多。這種增加的複雜性將再次成為中短期內更廣泛部署的障礙。

LiveVideoStack： 在你看來，QUIC最終將取代TCP還是僅僅改進它？

Robin Marx： 我認為QUIC並不會完全取代TCP。總會有人選擇TCP更簡單的設定或者執行那些無法輕鬆更新、相對陳舊的應用。我能想到的一個例子就是Netflix，這家公司已投入大量資金來優化他們的TCP+TLS+HTTP/2技術棧，用以直接從Linux核心傳輸視訊。短時間內，他們不太可能切換到HTTP/3。我確實覺得隨著時間的推移，大部分應用都將遷移到QUIC上，新的應用級別的協議也將被設計為只與QUIC一起使用（同時棄用TCP）。

LiveVideoStack： 你如何看待網際網路協議的未來發展？如你所見，未來的網際網路將會是什麼樣的？

Robin Marx: 如此重度加密QUIC的主要原因之一就是防止它變得陳舊且難以發展——這是TCP的致命缺陷。TCP被廣泛地部署與實現於如此多的不同裝置中，核心協議的任何更改都要求大部分裝置的更新，而這種更新可能需要10年以上的時間。

使用QUIC的話，好處就在於只有客戶端和伺服器將新增新功能用以更新，而其他（如防火牆和負載均衡器）仍保持穩定（至少在新增最初的QUIC支援後）。我並不十分確定這種情況是否真的會發生（你依然可以使用QUIC進行TLS攔截/代理），但我確實認為這是朝正確方向邁出的重要一步。

接下來幾十年，我想我們很可能都將使用QUIC和HTTP/3（或者至少是它們的升級版本），然後再決定我們需要新的協議來應對量子網路和星際通訊所帶來的新機遇。（笑）

瞭解Robin

LiveVideoStack： Robin，多年來你一直致力於HTTP/2、HTTP/3 和QUIC協議的發展。你最初是怎麼參與進來的？

Robin Marx： 我最開始的工作就是從HTTP/2開始的，在我加入之前，這個專案就已經存在了。當時是2015年，HTTP/2協議剛剛被IETF標準化，並開始廣泛部署。

我的研究主要集中在HTTP/2效能的提升程度，當時人們聲稱HTTP/2的效能相比HTTP/1.1大幅提升了50%。但即使是我早期的測試也顯示HTTP/2幾乎從沒有過如此大的效能提升。事實上，HTTP/2甚至很多時候還要慢一些。這促使我不斷髮現流行瀏覽器實現中的一些bug和問題，並將它們釋出出來，這也使我的團隊在圈子裡收穫了“street cred（指被圈子裡的其他人所接受並獲得尊重）”的稱號。

然後在2017年左右，我當時在爭論是否繼續堅持HTTP/2的使用（很可能不會有更多有趣的發現），還是切換到完全嶄新的協議上。然而這個時候，IETF正式開始了QUIC的實現工作。我給我的一位研究生布置了一個作業：嘗試建立一個簡單的QUIC協議實現，看看這個過程是否有趣。事實證明，這比預想要困難得多，我不得不加入一起來完成這個作業。在這個過程中，我們一直和IETF的工程師保持聯絡，他們當時也在GitHub上進行QUIC的實現。

很快我們就意識到，我們並不是唯一努力實現QUIC（後來是HTTP/3）並驗證一切可以正確執行的人。那個時期，協議一直在發生大的變化，我們經常不得不重寫程式碼庫中的大部分程式碼。因此，我開始研究一些工具和視覺化技術來幫助除錯和驗證我們自己的協議實現。

這個方法對我們來說非常有效，所以我們決定將它與其他協議實現者分享。令我們沒想到的是，很多來自Facebook和Cloudflare等大公司的實現者對這些工具非常感興趣。許多技術棧決定實現我們提出的qlog格式，並開始使用我們的qvis工具除錯他們的系統。隨著時間的推移，我們擴充套件了這些工具並幫助發現了許多實現中的bug和低效問題，這也使我們能夠在學術場合發表這些內容，我也因此完成了博士學位。（笑）

長話短說，我想正是我們看到解決具體問題的需求，並能夠深入參與到IETF工作中而做到了這一切。

LiveVideoStack： 對於剛開始參與網路協議工作的人，你可以提供一些有用的建議嗎？

Robin Marx： 我會強烈建議大家與已經加入IETF的人建立聯絡[通過郵件列表、GitHub、或者（遠端）參與IETF會議]。這些人幾乎都是來自大公司的工程師，擁有非常深厚的技術積累，並且平易近人。他們非常歡迎新人，而且出人意料地友好，樂於回答即使是非常基礎的問題。

你自己也應該準備好做出承諾……協議工作很有可能會非常複雜，如果你想參與協議的設計併產生影響，你需要花一些時間瞭解IETF的工作方式以及它的歷史。

LiveVideoStack： 你在推特上說，不久之後你將成為Akamai的網路效能專家，你對這個新的角色有什麼樣的期待？

Robin Marx: 自從開始PhD研究，我就一直想加入一家像Akamai這樣的CDN公司。CDN是最有趣的技術公司之一：得益於其固有的全球性和對網路效能和安全的高度關注。為了保持競爭力，它們必須處於（比如）新協議實現的最前沿，因此它們需要專家來幫助內部團隊和外部參與者（比如客戶）理解新技術。

在Akamai，我的主要職能是幫助客戶與內部專業知識建立連線，並以一種易於理解的方式向他們解釋協議和其他Web（效能）相關技術的內部工作原理。這有助於將客戶的業務需求轉化為我們的技術實現。

對我來說，這份工作對技術的要求沒有以往工作那麼高，但它更注重我的其他一些強項，比如我在PhD期間發展起來的技術寫作和公共演講技能。我對這份工作非常期待！（笑）

LiveVideoStack： 最後一個重要問題，如果你有一個機會和一位網際網路先驅對話，你最想和誰對話？你想和他談論什麼？

Robin Marx： 我非常希望和Van Jacobson對話，我還希望能夠和Sally Floyd聊聊（不過非常遺憾的是，她在幾年前去世了）。他（她）們都是為擁塞控制演算法相關工作做出開創性貢獻的人。

當我越深入瞭解各類協議和網路效能，就越清楚底層擁塞控制機制[不僅內置於TCP和QUIC協議，還存在於使用AQM（Active Queue Management，主動佇列管理）的網路]的重要性。

雖然擁塞控制演算法本身通常在概念上並不難理解，但是真正、深入地理解它們實際的工作原理，以及它們在真實、全球範圍內的現代網路中的執行方式並不容易。我非常希望能從早期以及見證了這些協議發展的人們那裡得到一些啟示，來幫助我理解其中的細節之處。

比如，一些谷歌的工程師就曾告訴我，他們公司內部早就存在和我的qvis視覺化非常相似的工具，並且在某些方面要比我的版本好很多，而這些工具就是由Van Jacobson本人實現的。（笑）我非常希望向Jacobson先生請教如何改進我的工作，以及如何最終超越他所實現的工具（也許）。

最後，大家如果想深入瞭解HTTP/3，還可以閱讀Robin在_Smashing Magazine_上發表的技術文章：

http://www.smashingmagazine.com/author/robin-marx/

致謝：

感謝劉連響、李超、王盛三位老師提供問題線索。

更多人物對話：

▲掃描圖中二維碼瞭解音視訊技術大會更多資訊