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

大家好，我今天分享的題目是：《面向流媒體的確定時延傳輸——從QUIC出發(fā)，走向未來》?？赡苡腥藢Υ藭幸蓡枺菏裁词荙UIC？未來又是什么？這個標題到底是什么意思？ QUIC是一個全新的用戶態(tài)的傳輸協(xié)議。目前在流媒體傳輸優(yōu)化方面，以QUIC為基礎，我們有了一些全新的發(fā)展可能。那么具體有什么，它的未來又是什么樣，現(xiàn)在有哪些工作涉及它，這就是本次的演講主題。

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

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

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

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

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

-01-

IETF簡介

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

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

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

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

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

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

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

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

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

-02-

QUIC協(xié)議簡介

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

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

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

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

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

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

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

-03-

DTP：面向流媒體的QUIC拓展

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

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

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

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

結合這一系列的優(yōu)化方法，相對于QUIC協(xié)議，DTP協(xié)議可以讓數(shù)據(jù)預期的按時到達率提高最大約 10 倍。

我們進行了一些簡單的數(shù)據(jù)層面的測試，發(fā)現(xiàn)DTP協(xié)議確實可以使高優(yōu)先級數(shù)據(jù)的按時到達率明顯提高，也可以使低優(yōu)先級數(shù)據(jù)的到達率相對于QUIC協(xié)議而言大量提高?？梢钥吹?，在一些網絡場景下針對平均數(shù)據(jù)的傳輸也可以得到明顯的優(yōu)化效果。

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

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

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

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

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

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

第二是隧道方案。假設有兩個自治域（AS），我們不希望它們知道DTP協(xié)議的存在，那么是否通過可以部署某種網關設備，在中間使用某種DTP隧道來輔助兩個自治域之間的數(shù)據(jù)傳輸。我們通過網關捕捉這個數(shù)據(jù)，通過某種方法使用DTP隧道傳輸?shù)搅硪粋葋肀ＷC服務質量。

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

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

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

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

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

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

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

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

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

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

-04-

未來展望：Media over QUIC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-05-

未來展望：QUIC生態(tài)系統(tǒng)

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

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

-06-

總結

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

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