現(xiàn)在云游戲，云應(yīng)用越來越火，所以超低延遲實(shí)時(shí)流媒體傳輸技術(shù)的需求應(yīng)用場(chǎng)景會(huì)越來越多。騰訊專家工程師劉泓昊老師在LiveVideoStackCon 2020北京站的演講中，對(duì)超低延遲傳輸技術(shù)從傳輸協(xié)議的設(shè)計(jì)選擇到流控算法和采集都分享了自己不同于行業(yè)的理解。

類似云游戲這一類場(chǎng)景是實(shí)時(shí)視頻傳輸領(lǐng)域中最難的場(chǎng)景，今天主要分享一下我們這兩年云游戲場(chǎng)景上做的一些工作和思考，也會(huì)提到一些我們不同于行業(yè)的觀點(diǎn)。

這兩年云VR，云游戲，云應(yīng)用重新火起來。很多大公司都在加入這個(gè)行業(yè)，像云游戲，從全球來看所有巨頭都在做，包括阿里，騰訊，Amazon，F(xiàn)acebook，Google都在做這個(gè)領(lǐng)域。其實(shí)這些應(yīng)用早些年并不是沒有，沒有做起來的一個(gè)重要原因是網(wǎng)絡(luò)能力跟不上。我非常感同身受，幾年前要求幾十兆碼率延時(shí)只有幾十毫秒是不可能的，但是隨著整個(gè)中國(guó)互聯(lián)網(wǎng)的發(fā)展，家庭都做到光纖入戶百兆起步， WIFI5的大規(guī)模普及，已經(jīng)有越來越多的用戶網(wǎng)絡(luò)能滿足應(yīng)用的要求，未來隨著WIFI6的普及和5G的興起，我相信新的時(shí)代快要來了。

從依賴buffer抗抖動(dòng)到不抖動(dòng)

簡(jiǎn)單看一下類似場(chǎng)景對(duì)網(wǎng)絡(luò)的要求，這種場(chǎng)景本質(zhì)上是內(nèi)容生產(chǎn)即消費(fèi)，它們的間隔在十毫秒級(jí)。我們要讓用戶得到非常好的視聽感受，需要足夠大的速率來傳輸視頻畫面。以云游戲?yàn)槔朴螒蛳胱層脩舻捏w驗(yàn)接近于本地游戲，只是就1080P而言，需要碼率在20Mb以上，這還不算未來的4K、8K視頻。云VR可能需要70兆。

簡(jiǎn)單用三個(gè)詞描述對(duì)應(yīng)用的要求，就是零緩沖，超低延遲，大帶寬。隨著邊緣計(jì)算的大規(guī)模普及，網(wǎng)絡(luò)的物理延遲倒還不是太大的挑戰(zhàn)，關(guān)鍵是我們?cè)趺醋屲浖膫鬏斞舆t無(wú)限接近于物理延遲，怎么充分利用帶寬、怎么從以前利用buffer來對(duì)抗網(wǎng)絡(luò)抖動(dòng)，變成讓網(wǎng)絡(luò)不抖動(dòng)。 我們一直以來的觀點(diǎn)是，網(wǎng)絡(luò)傳輸協(xié)議設(shè)計(jì)和優(yōu)化的本質(zhì)是端到端的QoS，即結(jié)合應(yīng)用的QoS來設(shè)計(jì)最合適的協(xié)議和算法，因此面向新的應(yīng)用場(chǎng)景和技術(shù)挑戰(zhàn)，我們需要圍繞著零緩沖，超低延遲，大帶寬來設(shè)計(jì)我們的系統(tǒng)、協(xié)議和算法。

我們所有的東西都是基于零緩沖，超低延遲，大帶寬來設(shè)計(jì)的。

協(xié)議設(shè)計(jì)的關(guān)鍵點(diǎn)

今天的內(nèi)容我主要講三點(diǎn)：

可靠性， 為什么我要強(qiáng)調(diào)可靠性，主要有兩點(diǎn)原因：

1. 大碼率場(chǎng)景下，單位吞吐大幅增加，單幀大小大幅增加，導(dǎo)致丟包數(shù)大幅增加，尤其是重傳包丟包數(shù)大幅增加對(duì)我們的丟包處理提出了更高的要求；

2. 低延遲的要求導(dǎo)致我們對(duì)于重傳的實(shí)時(shí)性提出了更好的要求；

流控算法，新的應(yīng)用場(chǎng)景對(duì)單位吞吐和低延遲的要求，對(duì)流控算法提出了極高的收斂性和利用率要求，需要我們有顛覆性的算法設(shè)計(jì)；

最后我會(huì)說一下我們對(duì)于UDP和TCP的選擇上，有不同于行業(yè)的觀點(diǎn)和效果很不錯(cuò)的實(shí)踐。

關(guān)于可靠傳輸機(jī)制

關(guān)于可靠傳輸機(jī)制的第一個(gè)觀點(diǎn)，雖然視頻流并不是完全不能丟包，但是應(yīng)用層丟包是應(yīng)該盡量避免的。所有的數(shù)據(jù)丟棄應(yīng)該都是主動(dòng)丟棄而不是能力不夠?qū)е碌模e個(gè)例子，傳一個(gè)O幀數(shù)據(jù)中有個(gè)包因?yàn)槟芰Σ粔騺G失了，就得生產(chǎn)一個(gè)I幀，平均一個(gè)I幀的大小是p幀的6-12倍，因?yàn)槟芰Σ粔騺G失一個(gè)數(shù)據(jù)包導(dǎo)致要生產(chǎn)一個(gè)數(shù)倍大的數(shù)據(jù)，這對(duì)傳輸延遲的體驗(yàn)是很糟糕的。所以要盡可能保證所有數(shù)據(jù)丟失，是我主動(dòng)丟失的，而不是能力不夠?qū)е碌摹?/p>

類FEC和重傳的關(guān)系

接下來我們來說一下FEC和重傳的關(guān)系， FEC和重傳的優(yōu)缺點(diǎn)大家是有共識(shí)的，通過FEC可以降低丟包帶來的影響，減小幀延遲，但是FEC會(huì)導(dǎo)致帶寬的浪費(fèi)；重傳不會(huì)帶來帶寬的浪費(fèi)， 但是重傳就意味著延遲的增加。最合適的用法一定是把它們結(jié)合起來一起使用，延遲小、丟包率低的時(shí)候帶寬優(yōu)先，延遲大、持續(xù)丟包的時(shí)候FEC優(yōu)先。 這個(gè)地方我想強(qiáng)調(diào)兩點(diǎn)：第一，丟包是可以預(yù)測(cè)的，通過合理的預(yù)測(cè)是可以大幅降低FEC的使用的；第二，在使用FEC的情況下，尤其是網(wǎng)絡(luò)不好的時(shí)候，是有機(jī)會(huì)去做先驗(yàn)冗余的。

NACK和SACK的選擇

既然重傳一定要有，就看怎么發(fā)現(xiàn)丟包，行業(yè)有兩種通用做法。第一種做法是NACK 。NACK的優(yōu)點(diǎn)是丟包判斷邏輯非常簡(jiǎn)單，發(fā)現(xiàn)客戶端有hole就知道它丟包了，但是如果NACK包丟了，客戶端是不知道的，或者說收到NACK包，重傳包丟了，客戶端也是不知道的，沒有一個(gè)邏輯能閉環(huán)保證我能知道這個(gè)包一定丟了。一旦出現(xiàn)上述情況，就只能靠超時(shí)，在超低延遲的場(chǎng)景下，超時(shí)是一個(gè)非常不好的手段。因?yàn)槌瑫r(shí)有兩種可能性，第一種超時(shí)值太大了，超時(shí)太大意味著這一幀的延遲和抖動(dòng)非常大，從用戶感受來說就是卡頓或者手感不好。第二種如果說超時(shí)設(shè)置很小，會(huì)導(dǎo)致生產(chǎn)重復(fù)的包，讓擁塞更加嚴(yán)重。這個(gè)點(diǎn)是很難平衡的，核心原因是NACK沒有一個(gè)閉環(huán)邏輯能保證所有的丟包判斷邏輯是準(zhǔn)確的。

SACK其實(shí)是現(xiàn)在做可靠傳輸協(xié)議純ALOHA協(xié)議的機(jī)制里面常用的方法。包括TCP，QUIC也是類似。SACK的缺點(diǎn)是判斷邏輯非常復(fù)雜，SACK的優(yōu)點(diǎn)是ACK丟包不敏感。第一因?yàn)镾ACK是有一串閉合邏輯的，丟掉任何一個(gè)包，后續(xù)的包能補(bǔ)上，所有丟一個(gè)SACK不會(huì)影響整體的判斷邏輯。第二因?yàn)镾ACK是個(gè)有狀態(tài)的，這個(gè)狀態(tài)能做到丟包判斷更準(zhǔn)確，更實(shí)時(shí)，用一個(gè)rtt一定能判斷出來。

展開一下，老的Linux內(nèi)核里實(shí)現(xiàn)里面SACK的邏輯很復(fù)雜，是因?yàn)樗腔谛蛱?hào)序的，整個(gè)判斷邏輯是以序號(hào)來判斷是否丟包，這會(huì)導(dǎo)致整個(gè)隊(duì)列邏輯判斷非常痛苦。我們?cè)?3年做了一個(gè)新的方法，我們稱為基于時(shí)間序的丟包。如圖所示，我們根據(jù)數(shù)據(jù)包的發(fā)送時(shí)間來判斷做丟包的判斷，基于這樣一個(gè)邏輯，整體判斷邏輯會(huì)比傳統(tǒng)內(nèi)核簡(jiǎn)單很多而且更精準(zhǔn)，在這個(gè)邏輯下只要保證最后一個(gè)包不丟，那就能快速判斷出前面的包有沒有丟。如果最后一個(gè)包丟了，另一個(gè)辦法叫prob包。類似的工作Google在16、17年已經(jīng)patch到內(nèi)核里了，QUIC上也有類似的實(shí)現(xiàn)方法。

所以，在大帶寬、低延遲的場(chǎng)景下，丟包判斷的邏輯會(huì)變得更重要，這個(gè)時(shí)候SACK是遠(yuǎn)比NACK更好的方法，雖然它的實(shí)現(xiàn)復(fù)雜度要大很多。

關(guān)于流控

關(guān)于流控我們有三個(gè)觀點(diǎn)，第一個(gè)觀點(diǎn)是面向超低延遲和大吞吐場(chǎng)景我們需要新的流控目標(biāo)模型，它跟傳統(tǒng)的TCP的擁塞控制是不一樣的。第二個(gè)觀點(diǎn)是我們對(duì)延遲要求非常高，就意味著采集周期會(huì)變得很關(guān)鍵，百毫秒級(jí)的采集粒度已經(jīng)完全滿足不了新應(yīng)用的要求了。第三個(gè)觀點(diǎn)，流控算法的核心是吞吐，不是丟包，不是delay，也不是buffer，基于吞吐模型可以讓我們有更好的收斂性。

流控的新目標(biāo)

實(shí)時(shí)視頻流是App Limit，它在宏觀上的上限是受到碼率限制的，在新的場(chǎng)景下，碼率限制被徹底打開了，從實(shí)用的角度來說，流控的作用和價(jià)值就變得尤其巨大了。

實(shí)際上TCP的擁塞控制算法和流控，尤其是沒有buffer的流控還真不是一回事。擁塞控制算法的設(shè)計(jì)目標(biāo)是效率、公平、收斂。結(jié)合低延遲、零buffer的特性，流控的目標(biāo)是在不超出網(wǎng)絡(luò)瓶頸帶寬的條件下，盡可能的充分利用網(wǎng)絡(luò)帶寬。

所以如圖所示的紅線才是我們期望的結(jié)果，即碼率不斷在接近目標(biāo)帶寬的下面徘徊， 如果說傳統(tǒng)的TCP擁塞控制算法目標(biāo)是帶寬利用率100%的話，我們只要做到90%就可以了。

還有一條，TCP擁塞控制算法其實(shí)不太糾結(jié)微觀的情況，它關(guān)心的是宏觀的收斂性能，但是在流控上微觀的收斂情況，尤其是收斂速度是很重要的。因?yàn)閷?duì)于我們這種沒有緩沖的場(chǎng)景來說，在降速的時(shí)候收斂慢就是卡頓。對(duì)于視頻流來說，碼率波動(dòng)大，QoE肯定好不了。

關(guān)于采集

第一點(diǎn)，如果希望延遲是幾十毫秒，那網(wǎng)絡(luò)波動(dòng)的時(shí)候，采集周期是一百毫秒。等到一百毫秒才知道網(wǎng)絡(luò)波動(dòng)再去做處理，那意味著網(wǎng)絡(luò)一波動(dòng)就卡頓，所以采集的精度一定要足夠細(xì)。但是采集精度足夠細(xì)帶來的另一個(gè)問題是怎么把數(shù)據(jù)做準(zhǔn)，這是一個(gè)非常矛盾的點(diǎn)，又需要很小的采集間隔，又需要把數(shù)據(jù)做準(zhǔn)，甚至能反應(yīng)網(wǎng)絡(luò)情況的，這是非常不容易的事。這也是為什么以前系統(tǒng)會(huì)把采集間隔放的稍微大一點(diǎn)的原因，這樣采集數(shù)據(jù)是能真實(shí)體現(xiàn)網(wǎng)絡(luò)情況的。解決這個(gè)問題的方式是幀粒度，因?yàn)閹怯羞壿嫞袪顟B(tài)的，這些邏輯和狀態(tài)是可以梳理清楚并且建模的。幀粒度是目前為止我們能找到的最好的采集間隔和采集方法。

第二點(diǎn)，因?yàn)檠舆t性要求，所以要快速發(fā)現(xiàn)。這里面就兩種采集方法一種是在發(fā)端采集，一種在收端采集，收端采集有一定時(shí)間間隔才能往上報(bào)，這樣會(huì)導(dǎo)致判斷的時(shí)間偏晚，這樣和我們需要的盡可能實(shí)時(shí)判斷和低延遲又是矛盾的。所以建議數(shù)據(jù)采集是發(fā)端為主，收端為輔。因?yàn)榘l(fā)端的采集和計(jì)算過程可以在任何一個(gè)中間態(tài)進(jìn)行。發(fā)端采集數(shù)據(jù)不準(zhǔn)的部分，用收端來補(bǔ)充。

第三點(diǎn)，沒有數(shù)據(jù)也是數(shù)據(jù)。沒有數(shù)據(jù)背后反映很多東西，是很有價(jià)值的，這一點(diǎn)在我們做的過程中，效果是非常好的。

流控算法

流控的本質(zhì)是不斷尋找可用帶寬的過程。它在實(shí)際實(shí)現(xiàn)過程中無(wú)非是帶寬沒有用完的時(shí)候，通過不斷上探的方法，找到合適的速率。當(dāng)網(wǎng)絡(luò)擁塞或者抖動(dòng)的時(shí)候，快速降低速率以適配當(dāng)前的網(wǎng)絡(luò)情況。這里面就幾個(gè)問題，第一個(gè)問題是當(dāng)網(wǎng)絡(luò)擁塞的時(shí)候依靠什么來發(fā)現(xiàn)。通常的方法就兩種，第一種就是丟包，在中國(guó)有90%的場(chǎng)景是先rtt先升高再丟包，但是對(duì)于低延遲的場(chǎng)景來說，rtt的大幅升高是不可接受的。另外，早年關(guān)于TCP的不公平性，定義了兩個(gè)場(chǎng)景，一個(gè)是rtt的不公平性，即rtt越大，速率越低；一個(gè)是多瓶頸鏈路的不公平性，它指的是在非瓶頸鏈路產(chǎn)生的丟包會(huì)導(dǎo)致連接的速率偏低，這就是因?yàn)槲覀兺ǔ０褋G包做為擁塞的判斷依據(jù)導(dǎo)致的。因此，丟包一定不是好的判斷依據(jù)。

基于buffer來判斷網(wǎng)絡(luò)擁塞，有兩個(gè)問題，第一，實(shí)際雖然我們是App Limit型的，但每幀大小是不一致的，buffer的堆積并不完全是因?yàn)榫W(wǎng)絡(luò)的帶寬不匹配導(dǎo)致的；第二， buffer的堆積是以犧牲體驗(yàn)為代價(jià)的，并不是一個(gè)好的信號(hào)。

從目前我們的探索來看， 速率模型是一個(gè)更好的模型，理由有三：

1. 流控的本質(zhì)是讓發(fā)送的帶寬和網(wǎng)絡(luò)瓶頸鏈路的接收能力是一致的，接收能力是速率，發(fā)送帶寬也是速率，所以基于速率來作為模型更實(shí)時(shí)的判斷卡頓依據(jù)是更好的方法。

2. 接收速率來決定降速到多少，是可以實(shí)現(xiàn)降速的快速收斂的。

3. 帶寬的探測(cè)過程本質(zhì)還是預(yù)測(cè)速率，他背后還是速率模型。

TCP的擁塞控制早年最經(jīng)典的算法是AIMD，即加性增，乘性減。我個(gè)人非常認(rèn)可AIMD這個(gè)思路的，因?yàn)锳IMD是我目前看到收斂到公平的最好的機(jī)制。雖然有很多啟發(fā)式的算法，例如MIMD號(hào)稱可以收斂的效率很快，但是收斂到公平的能力是很差的。然而今天互聯(lián)網(wǎng)音視頻最大的問題不是最快的那個(gè)跑的有多快，而是最慢的那個(gè)跑的太慢了，這是有人說應(yīng)用體驗(yàn)不好的核心原因。這本質(zhì)上就是收斂到公平的能力，所以收斂到公平都是其中非常重要的因素。

基于此，我們認(rèn)為AIMD并不是一個(gè)過時(shí)的方法，問題是我們應(yīng)用怎么使用。最后說一下基于人工智能的流控，我的觀點(diǎn)是，流控的核心是模型，人工智能是模型之上的補(bǔ)充，不存在完全的人工智能，人工智能是加分項(xiàng)，不是地基，它或許能幫我們做到95分，前提是我們自己能做到80分。

流控流程

因?yàn)樽龀脱舆t的應(yīng)用，不同于其他場(chǎng)景，為了保證實(shí)時(shí)性，清阻過程（包括丟幀）是很重要的階段，不能被忽略。

關(guān)于網(wǎng)絡(luò)傳輸協(xié)議

從視頻流來講，很顯然UDP是比TCP更合適的。第一，UDP比TCP更靈活，丟數(shù)據(jù)更好丟，用TCP的話在底層丟數(shù)據(jù)是非常不容易的；第二，UDP可以用FEC，但是TCP用不了；第三，如果我們是推流，那手機(jī)端內(nèi)核我們是改不了的，內(nèi)核改不了用傳統(tǒng)TCP效果肯定是不好的；第四，是內(nèi)核代碼不好改，相比應(yīng)用層代碼，Linux內(nèi)核的學(xué)習(xí)成本確實(shí)不低。但是，從我們的數(shù)據(jù)來看，在高碼率情況下UDP的丟包率是要高于TCP，而且碼率越高丟包率越高。

在實(shí)踐過程中我們做了一套基于TCP的傳輸體系，在我們體系里面，TCP協(xié)議棧主要功能是可靠傳輸和圍觀尺度的PACING，但是不做擁塞控制。實(shí)際上，為什么TCP做視頻傳輸做不好，很重要的一個(gè)原因是上面有應(yīng)用層流控，下面又有擁塞控制，他們是互相沖突的。我們改造之后，整體的效果我們還是非常滿意的。我們平均端到端的延遲，即從發(fā)送數(shù)據(jù)到被確認(rèn)時(shí)間已經(jīng)非常接近物理延遲了，到ACK回來不到二十毫秒，我們?cè)谟芯€網(wǎng)絡(luò)上的卡頓情況并不比硬件產(chǎn)生的卡頓更多，我們空口的卡頓率比線上直播要低。

比較理想的方案是既把UDP用上又把TCP低丟包特性用上，所以我們最終的系統(tǒng)是我們會(huì)在一個(gè)會(huì)話里跑兩個(gè)連接，一個(gè)TCP一個(gè)UDP，當(dāng)我延遲小丟包率低碼率高的時(shí)候我會(huì)用TCP，當(dāng)我網(wǎng)絡(luò)不好延遲高丟包率高碼率上不去的時(shí)候用UDP。低延遲用TCP高延遲用UDP，高碼率用TCP低碼率用UDP 。

我們這里說的UDP指的是基于UDP實(shí)現(xiàn)的具備重傳和FEC能力的應(yīng)用層可靠傳輸協(xié)議，我們目前使用的是我們自研的可靠傳輸協(xié)議RPD 在可靠傳輸協(xié)議之上我們還需要實(shí)現(xiàn)一個(gè)協(xié)議實(shí)現(xiàn)多個(gè)連接跑在同一個(gè)會(huì)話上，讓兩個(gè)連接能做到無(wú)縫實(shí)時(shí)切換。

我們現(xiàn)在面臨的最大的問題并不是匹配不了用戶帶寬，而是所使用鏈路根本不具備傳輸超低延遲的這個(gè)能力。我們發(fā)現(xiàn)很多用戶的wifi上連兩兆速率的穩(wěn)定傳輸都做不到。這個(gè)問題在wifi 2.4GHZ頻段上非常明顯，在wifi 5GHZ頻段上就好很多。我相信隨著wifi6的出現(xiàn)，未來會(huì)更好 。但是無(wú)論如何空口傳輸?shù)姆€(wěn)定性，它們都是比不過有線網(wǎng)絡(luò)的。我們的觀點(diǎn)是，我們要做兩件事：第一我們要深耕產(chǎn)業(yè)鏈，我們要把整個(gè)產(chǎn)業(yè)鏈打通，讓空口的能力適配低延遲的要求。第二是空口很大一部分的問題是概率，如果能把兩個(gè)獨(dú)立的信道疊加起來，如果有兩個(gè)信道的話就等于把兩個(gè)獨(dú)立的概率事件疊加起來，2個(gè)9有機(jī)會(huì)變成4個(gè)9。所以未來在不可靠的無(wú)線鏈路上，用多鏈路實(shí)現(xiàn)高可靠是有很大機(jī)會(huì)的。用現(xiàn)在大部分手機(jī)都能支持wifi/4g雙通道了，我們判斷wifi/5G 、wifi/wifi、5G/5G雙通道一定是未來保證超低延遲的基礎(chǔ)手段。而且這種手段不止在超低延遲的場(chǎng)景下使用，當(dāng)前主流的直播、點(diǎn)播應(yīng)用上都有很大的應(yīng)用價(jià)值。

我們相信，多通道技術(shù)一定是未來網(wǎng)絡(luò)傳輸系統(tǒng)發(fā)展的趨勢(shì)。

首先Sack是更好的重傳發(fā)現(xiàn)機(jī)制；第二點(diǎn)是幀粒度的采集是合適的采集方法；第三點(diǎn)是速率模型做流控；第四是TCP和UDP混用在超低延遲場(chǎng)景效果很好，最后未來是多鏈路的。
編輯：lyn