QUIC（Quick UDP Internet Connections）是Google設計的一套可靠UDP傳輸協議，旨在為HTTP提供一個安全、可靠、高效和低延時的通信基礎。QUIC協議已被IETF采納為標準，并且HTTP/3已選擇使用QUIC來代替TCP作為其傳輸層協議。LiveVideoStackCon2022 北京站邀請了清華大學的馬川為我們介紹QUIC協議的誕生、目前的拓展成果以及未來的發展方向。

大家好，我今天分享的題目是：《面向流媒體的確定時延傳輸——從QUIC出發，走向未來》。可能有人對此會有疑問：什么是QUIC？未來又是什么？這個標題到底是什么意思？ QUIC是一個全新的用戶態的傳輸協議。目前在流媒體傳輸優化方面，以QUIC為基礎，我們有了一些全新的發展可能。那么具體有什么，它的未來又是什么樣，現在有哪些工作涉及它，這就是本次的演講主題。

首先做一個簡單的自我介紹，我是清華大學2021級計算機系網絡所的碩士研究生馬川，我的導師是崔勇教授。目前我的主要工作是，基于最新的QUIC傳輸協議來開發和研究具有自主知識產權的相關協議，該協議目前被稱作DTP協議。

DTP協議現在已經被清華的A類會議ICNP所收錄，并且成為了CCSA的通信協會標準。除此之外我還積極參與了IETF若干工作組的相關工作，推廣發展DTP的思想，并且嘗試對該協議進行落地和應用。現階段取得的主要成果是關于DTP協議的相關研究工作被列為國家重點研發項目亮眼成果。

本次是希望與大家分享我們隨著互聯網發展同步開展的研究工作。首先世界上出現了全新的標準，有了統一的協議，于是我們在新協議基礎上創新了新技術，并且嘗試將新技術進行落地。從IETF的QUIC協議開始，我們按照上圖中的流程取得了相關工作成果，包括流媒體方向、內部接入方向，協議接入方向。

未來也許有未來的方向。但由于我經驗尚淺，所以本次只是希望從學術和標準化角度給大家提供一些全新的思路。大家可以權當聽個故事，通過展示我們走過的道路可以有進一步的交流討論。

以上是本次演講的主要內容，首先為大家簡單介紹IETF組織，然后對QUIC協議進行介紹，隨后向大家介紹我們所做的DTP協議，最終是對未來的展望和總結。

-01-

IETF簡介

首先介紹IETF組織，它名字的中文含義即互聯網工程任務組，它是一種國際民間自治組織，并沒有強大的政府和企業在背后支持。它的主要工作就是制定互聯網標準，如TCP、IP、HTTP等協議標準均尤其所制定。它分為很多方向（Area），例如路由、傳輸等，每個方向下由很多工作組（WorkingGroup）來承擔。以上為各工作組最新的研究成果，如TLS1.3、WebRTC以及QUIC協議。

那么IETF是如何工作的？整個過程是通過RFC來實現的，它是一種經過大家討論交流后進行歸檔的文檔，也是一種不成文的規定，是不自稱為標準的事實標準。

IETF每年開三次會，大家會就有關工作進行交流討論。它是免費的組織，只要加入郵件列表就可以參與。David Clark曾提出一句名言：“我們拒絕國王、總統和投票，簡單多數和可運行的代碼就是我們的信仰。”

接下來介紹RFC的誕生過程，首先需要完成一篇稿子，稿子在經過討論后可能被某工作組接受，稱為Adoption，待成為工作組文稿后再進行討論，經過大家一致同意后會進入一個Last Call的環節，相當于公示，公示后再經IESG審核通過就可以形成RFC。整個過程歷時較長，可能要2到3年。

那么各國對RFC的貢獻情況如何呢？目前全球有約9000個RFC，美國占到其中的三分之二。我國也在逐漸發力，貢獻度達到了500多個。從某種角度上來說，我國確實是一個互聯網大國，但還難說是互聯網強國，我們還無法將優勢推給其他人，讓其他人按照我們的思路進行設計發展。

以上是每一屆IETF的參會人數。很遺憾，和美國、歐洲相比，中國的參會人數還較少，參會人數整體上呈現美、歐、亞三足鼎立的趨勢，美國尤其最強。

那么參與者的構成是什么，最主要是設備商，如思科、華為等企業，然后是互聯網大廠，如谷歌、META等，剩下的是網絡運營商和大學研究者。

那么參加這個會議有什么意義？第一是為了提高我國的國際影響力，既然谷歌、蘋果、思科等大廠都在參與，那為什么不能是我們呢，我國在互聯網領域并不落于人后。可能有人覺得不懂技術的人才去做標準，懂技術的人都在敲代碼，實際當然并不是這樣，如果沒有核心的技術，自然也就沒有可以作為標準的材料。其次，這不僅可以為國家和企業做出貢獻，也有利于搭建自己的人脈，認識更多的新人，了解全新的技術標準。

那么如何參加呢？最簡單就是到官網直接加入工作組mailing list來參與討論交流。另一個方法是加入IETF的中國群，大家如果感興趣可通過以上二維碼來入群。

-02-

QUIC協議簡介

接下來介紹QUIC協議，它到底是什么？這首先要從它的發展歷史講起。

從2012年開始，谷歌對它的原型系統進行測試；13年開始在Chromium中進行進一步部署測試；14年開始，QUIC協議開始在YouTube等網站作為HTTPS的底層協議在谷歌進行部署；16年-21年QUIC工作組成立，相關工作在IETF上進行了大量討論，最終發布了RFC9000，即正式的QUIC協議。 截至2017年，QUIC協議初展拳腳；2018年，IETF宣布，HTTP/3將棄用TCP協議，改用QUIC協議實現；2020年，華為也在自研的內核組件中推出了自己的QUIC，被稱為hQUIC；2020年，Facebook宣布其超過75%的流量將使用QUIC協議，它的流行度未來有望進一步提升。

那么QUIC協議的優勢是什么？QUIC的諧音代表了它高性能和快速迭代兩種特性，它在基礎上是TCP協議的拓展。

以上為QUIC與TCP的對比表，QUIC主要針對兩個方向，首先是TCP協議的頭部阻塞問題，前面的數據沒傳完，后面就不許傳。這種情況在HTTP/2中尤為嚴重，雖然它使用一個TCP流代表很多HTTP流，但前面發生阻塞，后面就傳不到。

其次是TCP的握手時間較長，尤其跟TLS1.2結合總是要重新握手。QUIC協議提出了一種更快的，不需要RTT即可握手成功的方法。基于TCP協議長年累月的積累，QUIC協議在此基礎上創造了全新的體系，在IP協議之上，HTTP協議之下結合了安全的加密系統形成了如今QUIC協議的全新內容。

那么QUIC協議有什么意義，我們該如何看待它？從上面可以看到，有大量的公司都已經有了自己內部的QUIC協議，或多或少地構筑了自己的體系。QUIC協議以自己的全新生態帶給互聯網全新的可能，例如UDP over QUIC的出現。可以說QUIC協議有一統傳輸層的趨勢，有大量的生態將基于它進行設計。

QUIC協議相關的研究方向也非常豐富，例如它的靈活性、它的多徑、它的擁塞控制、它的QoE等等方向，以上在學術界也有相關的研究展示。可以看到，對于QUIC協議而言，它的優化空間很大，應用范圍很廣，并且使用場景多樣。

-03-

DTP：面向流媒體的QUIC拓展

到此為大家簡單介紹了QUIC協議的定義，接下來介紹我們的工作成果，即被稱為DTP的協議。它到底是什么？

從標題上看，它是一個QUIC協議的拓展，那么是如何拓展的？該協議的全稱為Deadline-aware Transport Protocol，即時延敏感的傳輸協議。

它的使用場景為滿足應用在截止時間之前完成塊傳輸的需求。截止時間和塊的定義都是什么呢？以觀看直播為例，我們實際需要在短時間（如一秒鐘）內完成視頻畫面傳輸，這個時延即為截止時間，假如超出這個時間，即使畫面完成傳輸，對直播的效果影響也很大。而塊相當于視頻幀、控制信令，它是一個單獨的，可控的并且可以單獨使用的數據組件。

DTP協議通過使用截止時間和塊的概念，聯合應用提供的相關數據來使用網絡提供對應服務，包括使用冗余編碼來防止數據重傳帶來的時延。為了避免排隊時延，采用一些全新的擁塞控制算法以及數據調度和丟棄的思路，使其內部不會自我進行擁塞。

結合這一系列的優化方法，相對于QUIC協議，DTP協議可以讓數據預期的按時到達率提高最大約 10 倍。

我們進行了一些簡單的數據層面的測試，發現DTP協議確實可以使高優先級數據的按時到達率明顯提高，也可以使低優先級數據的到達率相對于QUIC協議而言大量提高。可以看到，在一些網絡場景下針對平均數據的傳輸也可以得到明顯的優化效果。

視頻效果會更加直觀，我們模擬了一個低軌衛星的鏈路場景，在如此場景下，相對于QUIC協議，DTP協議可以使卡頓更少，視頻質量更高，傳輸時延更低。

下面來進行一個簡單的總結，DTP協議和QUIC協議相比有什么優勢？那便是時延更低，安全性和靈活性更高。但它的問題是它只是一個半可靠的傳輸協議，數據的到達率不穩定，有些數據可能會因為傳輸速率而進行一定的丟棄，它在適用的流媒體和弱網環境下傳輸可以展現出很明顯的優化效果。

關于DTP協議我們做了若干工作，例如參加開源點亮計劃，將它作為一個可供參與的開源項目給大家提供相關工作和服務；我們也在QUIC工作組進行了相關推廣，發布了相關的draft；我們還在MoQ工作組進行了相關的討論和推廣，在MoQ將這種思路進行討論和延伸。

針對DTP協議的其他應用方案我們也有一些自己的思路，首先要考慮的問題是應用可能難以隨著協議的修改而改變，因此我們希望為應用提供一種更快捷的接入方式，現階段思考了三種方法。第一種是采用API，第二種是搭建中間Proxy，用代理節點在維護現有傳輸邏輯的前提下接入全新協議，甚至可以通過某種網關設備讓兩端使用無感知的數據傳輸。

下面看第一個想法，我們在另一個國家重點研發項目中考慮，基于現有TCP的CDN系統可以在終端應用上使用DTP協議實現一些應用。然后在中間部署Proxy，將TCP和DTP的信令進行轉換，使得原來的業務邏輯不會發生變化，只要前面部署一個代理應用，就可以保證業務邏輯持續正常的運行下去。

右側視頻是系統的測試結果，可以看到相對于QUIC協議，DTP協議可以得到10%～20%的時延優化，整個過程非常流暢，其中在CDN端仍然是TCP協議，另一側是DTP協議，視頻在限網中播放得非常流暢。

第二是隧道方案。假設有兩個自治域（AS），我們不希望它們知道DTP協議的存在，那么是否通過可以部署某種網關設備，在中間使用某種DTP隧道來輔助兩個自治域之間的數據傳輸。我們通過網關捕捉這個數據，通過某種方法使用DTP隧道傳輸到另一側來保證服務質量。

我們在此進行了一個簡陋的測試，該測試在TSN網絡上進行，TSN網絡上有若干設備，例如大家看到的燈泡，我們使用終端對燈泡進行一定操控。中間網絡是帶寬有波動，具有丟包率的不穩定網絡，但是通過這種隧道方案就可以在這種具有大量波動，不可靠的網絡上提供更好的服務質量保障，以上是我們關于無感知接入所做的一種嘗試。

另一個嘗試就是端網結合，它的意義是什么？這個想法聽起來好像不是非常的計算機，尤其不是非常的計算機網絡，端側搞端側的事情，網絡側搞網絡側的事情當然最好。但只靠端側處理難以掌握網絡的具體情況，無論探測得再好，設備哪兒排隊了，要轉發什么，我們無法得知。網絡側最大的問題就是它不能適應應用的需求。 于是我們考慮能否通過傳遞應用的需求，利用傳輸協議提供給網絡的設備，用例如SDWAN和傳輸協議結合的方法將網絡設備與端側設備進行結合，得到更好的優化效果。

我們考慮了兩種優化方法，第一是差異化轉發，首先利用DTP協議在端側進行流量優化整形，將亂序數據依據優先級重要性進行調度。整形后通過通知中間節點使高優先級數據利用某條更加空曠、高效的道路得到優先轉發服務。

以上為測試結果，圖中藍色線條代表高優先級數據按時到達率，黃色線條代表低優先級數據按時到達率。可以看到，在只使用端側優化的情況下，兩者的按時到達率會有明顯下降。采用端網協同方式便可使兩者服務質量得到明顯的提升和保障。原因是我們可以更好地分配鏈路的帶寬資源，使高低優先級數據之間不會互相搶占。從而得到更高的優化效果。

那么假如將這種差異化端網結合的思路放到路由器上呢？我們也進行了相應嘗試，例如使用差異化路由使高低優先級數據通過不同鏈路進行傳輸，選擇不同路由方式來適配應用需求。

以上為測試結果，可以看到最終可以得到更好的傳輸效果。當然該方法目前僅用作學術討論，在實際場景下能否適用還有待商榷。

在開發過程中發生了一些小故事在此想和大家進行分享，首先我們發現有時換個版本將代碼更新一下，即可獲得二十倍的傳輸效率提升。老版本可能跑出100Mbps就到頭了，而換個版本可能瞬間即到達1Gbps速度。

但老版本可能早已搭建了很大的系統架構，代碼難以說改就改。在這個問題上我們按并行思路來考慮，需要功能就使用老版本，需要性能就用新版本，一點一點遷移，不要讓歷史成為包袱，而是要成為優勢。雖然我們了解原來的代碼，但為了得到新功能，必須要向前邁進。

另一個小故事就是關于公平性分析。在此強調一下，TCP、UDP是寫在Kernel里，要修改就需要改動Kernel的操統代碼。QUIC協議是基于UDP的用戶態的協議，它支持任意修改。這會帶來公平性的問題，例如Zoom、Meet等應用都存在協議公平性的問題。

圖中的研究成果主要介紹了Zoom、Meet這些應用在帶寬搶占上的表現，結論是它們（尤其是Zoom）擁有更強的搶占性，使得整體表現并不夠公平，當然國內的一些軟件也存在同樣的問題。雖然以QUIC為代表的用戶態的協議為用戶提供了強大的自定義能力，不過我們仍然需要保護網絡環境，不能把網絡變得更差更擁塞。

-04-

未來展望：Media over QUIC

接下來是未來展望環節，剛才談到了IETF組織；談到了怎樣把基于UDP的擁有全新特性的QUIC協議逐漸變成未來的新可能、新基石；介紹了DTP協議，基于QUIC協議如何采用調度冗余和丟棄的思路使流媒體傳輸效果更好。

那么未來可以利用這些成果做什么呢？首先要介紹近期剛剛成立的Media over QUIC工作組，以上四點總結是該工作組成立時最初的愿景，一是關注媒體傳輸的時延與交互性之間的差異問題，例如連麥因為交互非常高，要求時延必須非常低，而普通的直播場景也許等個十秒都無所謂，針對不同應用有不同需求。

Media over QUIC聚焦的核心場景就是低時延媒體傳輸場景，像點播這種對時延要求不高的場景不在其考慮范圍內。工作組提出的Media over QUIC架構可以支持多種不同的媒體格式，用QUIC或WebTransport等下層支持來完成多種低時延的媒體傳輸，并且允許有全新的加密方法，中間Relay的處理等等全新的工作。

我們來看看它的整體結構，它針對上層主要提供了一種媒體分發方案，包括上傳、下載、編解碼同步等等。這里說的媒體即低時延的媒體傳輸，例如直播、互動、遠程桌面等。對下層則基本上是使用QUIC或HTTP/3的WebTransport接口進行傳輸。對中間設備它們會使用接力節點并基于Media over QUIC的思路和邏輯對數據進行轉發處理。

由于詳解所需的時間太長，所以在此就他們的設計方向我為大家做一個簡單總結。首先關于傳輸特征分為以上三類問題，一是視頻和控制信息是否可靠，我們需要考慮到數據傳輸的可靠性來決定是使用Message還是Quick Stream傳輸。第二是與媒體信息的強結合性，Media over QUIC工作組和Codec工作組的工作交流相當密切，如何聯系這些內容進行工作也是重點內容之一。然后就是如何提供靈活的中間設備支持，使中間設備更加智能，更加適配Media over QUIC的工作思路。

接下來是一系列基本上已經在不同實踐方案中使用的優化策略，例如針對不可靠傳輸使用QUIC的datagram來進行，或是為了節約帶寬丟棄中間傳輸的數據幀，除此之外還有很多類似的優化思路；其次數據幀的抽象在工作中也非常關鍵，它在Media over QUIC工作組中被稱作object；然后是使用一些合適的重傳與冗余策略來防止時延的增加；最后是通過在接力節點中允許一些調度和緩存的思路來節約傳輸時間。

但除此之外現在仍有大量的探索方向，MoQ形成基礎的協議內容還需要開展大量工作。

接下來我們看看未來還有哪些工作要做。例如解碼器怎么用，遷移會話是不是要做，能否對特定時延范圍進行特定優化，對接力節點又應有什么策略？

第一個問題是關于CDN的拓補設計，右圖是一個關于Media over QUIC Relay和CDN設計空間的draft。它有不同的拓補結構，第一種是最樸素的樹狀結構，從發布者到訂閱者之間按樹狀傳輸。除此之外也可以使用其他方式，例如使用mesh的Relay，在中間用一些中央控制節點使數據之間可以自由交換，這類似于覆蓋網絡的思路。可以決定用哪些Relay來傳輸數據也類似于阿里Livenet的思路。

第二個問題就是媒體元數據要放在哪里，以上問題雖然看起來都比較trivial，但實際上是標準制定的關鍵，你要告訴大家你要做點兒什么，大家要怎么做。既然他們還不知道，我們也可以上去提提意見。

下一個問題是為什么要做MoQ，首先工作組的前景是有望使MoQ作為RTP的代替品成為下一代流媒體的傳輸協議。

我和工作組交流了他們對未來的愿景，工作組說現在很多在線的視頻用的是WebRTC。如果有一個直播場景，WebRTC寫一個，又來一個在線會議場景，WebRTC又需要重新寫一個。怎么辦，那么應該有一種統一的分發低時延媒體的協議，來作為某種統一的基石。

目前有很多大廠（蘋果、思科、Twitch、Meta等）都在推進相關的標準化工作，我們希望能有更多的中國公司帶來一些奇招妙招。然后也有大量業界大佬重點關注這方面工作。在這里簡單介紹一下Ted Hardie，他之前是WebRTC的主席，現在跳到了MoQ工作組。可見WebRTC已經難以滿足當下大眾的需求。其他著名人士基本都來自IAB，IAB是IETF上最聰明的決策者團體，可謂是一人之下萬人之上。

接下來進行一個簡單的總結，MoQ的整體設計思路就是針對流媒體低時延的傳輸協議，它的核心優化場景是面向直播這樣對時延有一定要求的場景。它有多樣的優化策略，未來也有大量的可以供大家進行設計和討論的空間。眾多大廠和業界大佬也在關注這方面工作，我們也在努力做一些事情，發布了一些draft。同時也歡迎大家加入郵件列表來討論，看看大家對此有什么樣的思路。本頁下方有郵件列表的訂閱方法，大家如果感興趣可以關注一下。

-05-

未來展望：QUIC生態系統

接下來是最后的展望，目前QUIC的生態系統有兩大發展方向，第一大方向是QUIC+，通過剛才我們可以了解到QUIC協議是非常棒的用戶態協議，支持任意修改，QUIC+是關于如何向QUIC增加我們特定的需求，例如不可靠傳輸、優先級調度等等。它大量的優化方向代表它具備大量迭代和優化的可能。例如我們完成了DTP，阿里團隊做了XLINK，基于QUIC的協議設計已經成為我們探索的一大方向。

第二就是我們怎么站在它的肩膀上進一步發展，剛才提到QUIC有一統傳輸層的趨勢，并且已經可以看到萬物over QUIC的前景，現在出現了DNS over QUIC、RTP over QUIC、QUIC Proxy（類似于UDP over QUIC）、Media over QUIC等，接下來會有什么？是否會有CDN基于QUIC的變化？路由、資源搜尋、內部結構等在未來也可能通通會發生變化。底層原本是TCP和UDP，未來在UDP之上又有一層QUIC來幫助我們實現全新的目標，那么未來可以利用它做些什么，這是現在值得思考的事情。

-06-

總結

接下來是最后的總結，剛才我們看到了IETF組織的發展流程，了解了IETF在傳輸協議層面上如何從TCP轉到QUIC，使QUIC協議成為了現在的標準。而后我為大家介紹了DTP協議的內容，展示了未來的一些思路，包括MoQ以及QUIC新生態的介紹。

在此我想說，在大廠工作的各位相對于我一定會更加了解用戶需求，那么關鍵就是如何把歷史經驗作為自己的力量，把握用戶需求開發全新內容。希望大家可以嘗試在QUIC協議的基礎上完成一些新的成果，站在巨人的肩膀上為自己和未來創造一些發展空間。