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

大家好，我今天分享的題目是：《面向流媒體的確定時(shí)延傳輸——從QUIC出發(fā)，走向未來(lái)》?？赡苡腥藢?duì)此會(huì)有疑問：什么是QUIC？未來(lái)又是什么？這個(gè)標(biāo)題到底是什么意思？ QUIC是一個(gè)全新的用戶態(tài)的傳輸協(xié)議。目前在流媒體傳輸優(yōu)化方面，以QUIC為基礎(chǔ)，我們有了一些全新的發(fā)展可能。那么具體有什么，它的未來(lái)又是什么樣，現(xiàn)在有哪些工作涉及它，這就是本次的演講主題。

首先做一個(gè)簡(jiǎn)單的自我介紹，我是清華大學(xué)2021級(jí)計(jì)算機(jī)系網(wǎng)絡(luò)所的碩士研究生馬川，我的導(dǎo)師是崔勇教授。目前我的主要工作是，基于最新的QUIC傳輸協(xié)議來(lái)開發(fā)和研究具有自主知識(shí)產(chǎn)權(quán)的相關(guān)協(xié)議，該協(xié)議目前被稱作DTP協(xié)議。

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

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

未來(lái)也許有未來(lái)的方向。但由于我經(jīng)驗(yàn)尚淺，所以本次只是希望從學(xué)術(shù)和標(biāo)準(zhǔn)化角度給大家提供一些全新的思路。大家可以權(quán)當(dāng)聽個(gè)故事，通過(guò)展示我們走過(guò)的道路可以有進(jìn)一步的交流討論。

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

-01-

IETF簡(jiǎn)介

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

那么IETF是如何工作的？整個(gè)過(guò)程是通過(guò)RFC來(lái)實(shí)現(xiàn)的，它是一種經(jīng)過(guò)大家討論交流后進(jìn)行歸檔的文檔，也是一種不成文的規(guī)定，是不自稱為標(biāo)準(zhǔn)的事實(shí)標(biāo)準(zhǔn)。

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

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

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

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

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

那么參加這個(gè)會(huì)議有什么意義？第一是為了提高我國(guó)的國(guó)際影響力，既然谷歌、蘋果、思科等大廠都在參與，那為什么不能是我們呢，我國(guó)在互聯(lián)網(wǎng)領(lǐng)域并不落于人后。可能有人覺得不懂技術(shù)的人才去做標(biāo)準(zhǔn)，懂技術(shù)的人都在敲代碼，實(shí)際當(dāng)然并不是這樣，如果沒有核心的技術(shù)，自然也就沒有可以作為標(biāo)準(zhǔn)的材料。其次，這不僅可以為國(guó)家和企業(yè)做出貢獻(xiàn)，也有利于搭建自己的人脈，認(rèn)識(shí)更多的新人，了解全新的技術(shù)標(biāo)準(zhǔn)。

那么如何參加呢？最簡(jiǎn)單就是到官網(wǎng)直接加入工作組mailing list來(lái)參與討論交流。另一個(gè)方法是加入IETF的中國(guó)群，大家如果感興趣可通過(guò)以上二維碼來(lái)入群。

-02-

QUIC協(xié)議簡(jiǎn)介

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

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

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

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

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

那么QUIC協(xié)議有什么意義，我們?cè)撊绾慰创?？從上面可以看到，有大量的公司都已?jīng)有了自己內(nèi)部的QUIC協(xié)議，或多或少地構(gòu)筑了自己的體系。QUIC協(xié)議以自己的全新生態(tài)帶給互聯(lián)網(wǎng)全新的可能，例如UDP over QUIC的出現(xiàn)?？梢哉f(shuō)QUIC協(xié)議有一統(tǒng)傳輸層的趨勢(shì)，有大量的生態(tài)將基于它進(jìn)行設(shè)計(jì)。

QUIC協(xié)議相關(guān)的研究方向也非常豐富，例如它的靈活性、它的多徑、它的擁塞控制、它的QoE等等方向，以上在學(xué)術(shù)界也有相關(guān)的研究展示?？梢钥吹?，對(duì)于QUIC協(xié)議而言，它的優(yōu)化空間很大，應(yīng)用范圍很廣，并且使用場(chǎng)景多樣。

-03-

DTP：面向流媒體的QUIC拓展

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

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

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

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

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

我們進(jìn)行了一些簡(jiǎn)單的數(shù)據(jù)層面的測(cè)試，發(fā)現(xiàn)DTP協(xié)議確實(shí)可以使高優(yōu)先級(jí)數(shù)據(jù)的按時(shí)到達(dá)率明顯提高，也可以使低優(yōu)先級(jí)數(shù)據(jù)的到達(dá)率相對(duì)于QUIC協(xié)議而言大量提高。可以看到，在一些網(wǎng)絡(luò)場(chǎng)景下針對(duì)平均數(shù)據(jù)的傳輸也可以得到明顯的優(yōu)化效果。

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

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

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

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

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

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

第二是隧道方案。假設(shè)有兩個(gè)自治域（AS），我們不希望它們知道DTP協(xié)議的存在，那么是否通過(guò)可以部署某種網(wǎng)關(guān)設(shè)備，在中間使用某種DTP隧道來(lái)輔助兩個(gè)自治域之間的數(shù)據(jù)傳輸。我們通過(guò)網(wǎng)關(guān)捕捉這個(gè)數(shù)據(jù)，通過(guò)某種方法使用DTP隧道傳輸?shù)搅硪粋?cè)來(lái)保證服務(wù)質(zhì)量。

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

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

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

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

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

以上為測(cè)試結(jié)果，可以看到最終可以得到更好的傳輸效果。當(dāng)然該方法目前僅用作學(xué)術(shù)討論，在實(shí)際場(chǎng)景下能否適用還有待商榷。

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

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

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

圖中的研究成果主要介紹了Zoom、Meet這些應(yīng)用在帶寬搶占上的表現(xiàn)，結(jié)論是它們（尤其是Zoom）擁有更強(qiáng)的搶占性，使得整體表現(xiàn)并不夠公平，當(dāng)然國(guó)內(nèi)的一些軟件也存在同樣的問題。雖然以QUIC為代表的用戶態(tài)的協(xié)議為用戶提供了強(qiáng)大的自定義能力，不過(guò)我們?nèi)匀恍枰Ｗo(hù)網(wǎng)絡(luò)環(huán)境，不能把網(wǎng)絡(luò)變得更差更擁塞。

-04-

未來(lái)展望：Media over QUIC

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

那么未來(lái)可以利用這些成果做什么呢？首先要介紹近期剛剛成立的Media over QUIC工作組，以上四點(diǎn)總結(jié)是該工作組成立時(shí)最初的愿景，一是關(guān)注媒體傳輸?shù)臅r(shí)延與交互性之間的差異問題，例如連麥因?yàn)榻换シ浅８撸髸r(shí)延必須非常低，而普通的直播場(chǎng)景也許等個(gè)十秒都無(wú)所謂，針對(duì)不同應(yīng)用有不同需求。

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

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

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

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

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

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

第一個(gè)問題是關(guān)于CDN的拓補(bǔ)設(shè)計(jì)，右圖是一個(gè)關(guān)于Media over QUIC Relay和CDN設(shè)計(jì)空間的draft。它有不同的拓補(bǔ)結(jié)構(gòu)，第一種是最樸素的樹狀結(jié)構(gòu)，從發(fā)布者到訂閱者之間按樹狀傳輸。除此之外也可以使用其他方式，例如使用mesh的Relay，在中間用一些中央控制節(jié)點(diǎn)使數(shù)據(jù)之間可以自由交換，這類似于覆蓋網(wǎng)絡(luò)的思路。可以決定用哪些Relay來(lái)傳輸數(shù)據(jù)也類似于阿里L(fēng)ivenet的思路。

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

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

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

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

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

-05-

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

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

第二就是我們?cè)趺凑驹谒募绨蛏线M(jìn)一步發(fā)展，剛才提到QUIC有一統(tǒng)傳輸層的趨勢(shì)，并且已經(jīng)可以看到萬(wàn)物over QUIC的前景，現(xiàn)在出現(xiàn)了DNS over QUIC、RTP over QUIC、QUIC Proxy（類似于UDP over QUIC）、Media over QUIC等，接下來(lái)會(huì)有什么？是否會(huì)有CDN基于QUIC的變化？路由、資源搜尋、內(nèi)部結(jié)構(gòu)等在未來(lái)也可能通通會(huì)發(fā)生變化。底層原本是TCP和UDP，未來(lái)在UDP之上又有一層QUIC來(lái)幫助我們實(shí)現(xiàn)全新的目標(biāo)，那么未來(lái)可以利用它做些什么，這是現(xiàn)在值得思考的事情。

-06-

總結(jié)

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

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