正文字?jǐn)?shù)：5401 ?閱讀時(shí)長(zhǎng)：8分鐘

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

?

文 /?劉泓昊

整理 / LiveVideoStack

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

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

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

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

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

我們所有的東西都是基于零緩沖，超低延遲，大帶寬來(lái)設(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ì)說(shuō)一下我們對(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ū)е碌?#xff0c;舉個(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>

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

接下來(lái)我們來(lái)說(shuō)一下FEC和重傳的關(guān)系， FEC和重傳的優(yōu)缺點(diǎn)大家是有共識(shí)的，通過(guò)FEC可以降低丟包帶來(lái)的影響，減小幀延遲，但是FEC會(huì)導(dǎo)致帶寬的浪費(fèi)；重傳不會(huì)帶來(lái)帶寬的浪費(fèi)， 但是重傳就意味著延遲的增加。最合適的用法一定是把它們結(jié)合起來(lái)一起使用，延遲小、丟包率低的時(shí)候帶寬優(yōu)先，延遲大、持續(xù)丟包的時(shí)候FEC優(yōu)先。?這個(gè)地方我想強(qiáng)調(diào)兩點(diǎn)：第一，丟包是可以預(yù)測(cè)的，通過(guò)合理的預(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包丟了，客戶端是不知道的，或者說(shuō)收到NACK包，重傳包丟了，客戶端也是不知道的，沒(méi)有一個(gè)邏輯能閉環(huán)保證我能知道這個(gè)包一定丟了。一旦出現(xiàn)上述情況，就只能靠超時(shí)，在超低延遲的場(chǎng)景下，超時(shí)是一個(gè)非常不好的手段。因?yàn)槌瑫r(shí)有兩種可能性，第一種超時(shí)值太大了，超時(shí)太大意味著這一幀的延遲和抖動(dòng)非常大，從用戶感受來(lái)說(shuō)就是卡頓或者手感不好。第二種如果說(shuō)超時(shí)設(shè)置很小，會(huì)導(dǎo)致生產(chǎn)重復(fù)的包，讓擁塞更加嚴(yán)重。這個(gè)點(diǎn)是很難平衡的，核心原因是NACK沒(méi)有一個(gè)閉環(huán)邏輯能保證所有的丟包判斷邏輯是準(zhǔn)確的。

SACK其實(shí)是現(xiàn)在做可靠傳輸協(xié)議純ALOHA協(xié)議的機(jī)制里面常用的方法。包括TCP，QUIC也是類(lèi)似。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一定能判斷出來(lái)。

展開(kāi)一下，老的Linux內(nèi)核里實(shí)現(xiàn)里面SACK的邏輯很復(fù)雜，是因?yàn)樗腔谛蛱?hào)序的，整個(gè)判斷邏輯是以序號(hào)來(lái)判斷是否丟包，這會(huì)導(dǎo)致整個(gè)隊(duì)列邏輯判斷非常痛苦。我們?cè)?3年做了一個(gè)新的方法，我們稱(chēng)為基于時(shí)間序的丟包。如圖所示，我們根據(jù)數(shù)據(jù)包的發(fā)送時(shí)間來(lái)判斷做丟包的判斷，基于這樣一個(gè)邏輯，整體判斷邏輯會(huì)比傳統(tǒng)內(nèi)核簡(jiǎn)單很多而且更精準(zhǔn)，在這個(gè)邏輯下只要保證最后一個(gè)包不丟，那就能快速判斷出前面的包有沒(méi)有丟。如果最后一個(gè)包丟了，另一個(gè)辦法叫prob包。類(lèi)似的工作Google在16、17年已經(jīng)patch到內(nèi)核里了，QUIC上也有類(lèi)似的實(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)景下，碼率限制被徹底打開(kāi)了，從實(shí)用的角度來(lái)說(shuō)，流控的作用和價(jià)值就變得尤其巨大了。

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

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

還有一條，TCP擁塞控制算法其實(shí)不太糾結(jié)微觀的情況，它關(guān)心的是宏觀的收斂性能，但是在流控上微觀的收斂情況，尤其是收斂速度是很重要的。因?yàn)閷?duì)于我們這種沒(méi)有緩沖的場(chǎng)景來(lái)說(shuō)，在降速的時(shí)候收斂慢就是卡頓。對(duì)于視頻流來(lái)說(shuō)，碼率波動(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ì)帶來(lái)的另一個(gè)問(wèn)題是怎么把數(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è)問(wèn)題的方式是幀粒度，因?yàn)閹怯羞壿?#xff0c;有狀態(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ì)算過(guò)程可以在任何一個(gè)中間態(tài)進(jìn)行。發(fā)端采集數(shù)據(jù)不準(zhǔn)的部分，用收端來(lái)補(bǔ)充。

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

流控算法

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

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

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

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

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

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

?

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

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

流控流程

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

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

從視頻流來(lái)講，很顯然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ù)來(lái)看，在高碼率情況下UDP的丟包率是要高于TCP，而且碼率越高丟包率越高。

在實(shí)踐過(guò)程中我們做了一套基于TCP的傳輸體系，在我們體系里面，TCP協(xié)議棧主要功能是可靠傳輸和圍觀尺度的PACING，但是不做擁塞控制。實(shí)際上，為什么TCP做視頻傳輸做不好，很重要的一個(gè)原因是上面有應(yīng)用層流控，下面又有擁塞控制，他們是互相沖突的。我們改造之后，整體的效果我們還是非常滿意的。我們平均端到端的延遲，即從發(fā)送數(shù)據(jù)到被確認(rèn)時(shí)間已經(jīng)非常接近物理延遲了，到ACK回來(lái)不到二十毫秒，我們?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 。

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

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

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

LiveVideoStackCon 2021?上海站

時(shí)間：2021年4月16日-4月17日

我們準(zhǔn)備好全新的內(nèi)容，在上海歡迎您的到來(lái)

點(diǎn)擊【閱讀原文】了解更多詳情

總結(jié)

以上是生活随笔為你收集整理的超低延迟实时流媒体传输技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。