實(shí)時(shí)視頻通話超低延遲架構(gòu)的思考與實(shí)踐
2017年12月23日，由即構(gòu)科技主辦的 ZEGO Meetup 第一期 實(shí)時(shí)音視頻開發(fā)者沙龍?jiān)谏钲趫A滿結(jié)束。另外，2018年3月17日(本周六)，ZEGO Meetup 第二期 視頻直播+的技術(shù)實(shí)踐之道在北京舉行。此刻，讓我們把深圳 ZEGO Meetup 會上的精彩技術(shù)演講總結(jié)起來分享給業(yè)界，3月17日在北京中關(guān)村舉行的ZEGO Meetup技術(shù)沙龍總的精彩技術(shù)演講，也將會總結(jié)成技術(shù)文章來和讀者分享。
以下是即構(gòu)科技音視頻核心工程師關(guān)旭就如何打造實(shí)時(shí)視頻通話超低延遲架構(gòu)的精彩分享。
嘉賓簡介：
關(guān)旭，即構(gòu)科技音視頻引擎核心專家，碩士畢業(yè)于南開大學(xué)數(shù)學(xué)系，先后就職于中興通訊、騰訊等公司負(fù)責(zé)音視頻相關(guān)的研發(fā)工作，在實(shí)時(shí)音視頻技術(shù)上有多年積累，當(dāng)前在即構(gòu)科技主要負(fù)責(zé)音視頻引擎核心開發(fā)。
正文：
大家好，今天我分享的內(nèi)容主要分如下幾部分：
- 實(shí)時(shí)音視頻場景——從直播到線上抓娃娃
- 實(shí)時(shí)架構(gòu)的若干點(diǎn)思考
- 關(guān)于信源編碼的思考
- 關(guān)于信道編碼的思考
- 引入延遲的環(huán)節(jié)和降低延遲的思路
1. 實(shí)時(shí)音視頻場景——從直播到線上抓娃娃
圖 1
圖1展示了實(shí)時(shí)音視頻兩種不同的應(yīng)用場景——連麥互動直播和線上娃娃機(jī)。雖然這兩種都是互動，但是對于實(shí)時(shí)音視頻的要求卻不同。第一個(gè)實(shí)時(shí)連麥?zhǔn)钦Z音視頻流的互動，例如其中一個(gè)說了一句話，另外一個(gè)人聽到了，再回復(fù)一句話，這個(gè)實(shí)時(shí)性只是對語音視頻流的實(shí)時(shí)性要求很高。而第二種線上抓娃娃則對信令的延遲提出了更高的要求，操縱者無需說話，看到的是娃娃機(jī)傳回來的視頻流結(jié)果。如果考量互動直播是用實(shí)時(shí)音視頻的延遲，那么線上抓娃娃則是用信令和視頻流的延時(shí)。隨著時(shí)代的發(fā)展，我們對實(shí)時(shí)語音視頻的定義會慢慢有一些不同，將來可能還有更多的因素需要考慮。
圖 2
圖2是即構(gòu)互動直播的實(shí)時(shí)架構(gòu)圖，我們把互動直播分為兩部分，一個(gè)是主播側(cè)，需要更低的延遲，另一側(cè)是普通觀眾，對延時(shí)不太敏感，但對流暢性敏感，中間通過一些旁路的服務(wù)把這兩個(gè)集群(一個(gè)集群叫超低延遲集群，另外一個(gè)集群叫圍觀集群)連接起來。
在超低延時(shí)部分，我們提供的服務(wù)包括流狀態(tài)更新、房間管理等，以及一些流媒體服務(wù)，主要起到分發(fā)的作用。我們通過超低延遲服務(wù)器集群(和觀眾側(cè)不太一樣)，提供實(shí)時(shí)分發(fā)的功能。此外還提供了動態(tài)調(diào)度的服務(wù)，幫助我們在現(xiàn)有的資源網(wǎng)絡(luò)上找到更好的鏈路。后面的觀眾集群是另外一個(gè)集群，把它們分開是出于一些業(yè)務(wù)方和我們自己成本上的考慮，另外會提供存儲、PCB加速、分發(fā)的功能。
中間的旁路服務(wù)包括混流、轉(zhuǎn)格式(主要是轉(zhuǎn)碼)、轉(zhuǎn)協(xié)議等。為什么要混流?舉一個(gè)比較簡單的例子。當(dāng)主播一側(cè)有9個(gè)人連麥，如果沒有混流服務(wù)，觀眾端就會同時(shí)拉9路音視頻，這樣對帶寬壓力很大。普通觀眾是通過圍觀服務(wù)器集群(延遲相對大的集群)去拉這些流的，這個(gè)集群的延遲可控性相對比較弱，有可能會出現(xiàn)這9路畫面之間的不同步現(xiàn)象，通過混流服務(wù)，觀眾拉的都是合成好的音視頻流，就不會出現(xiàn)各路流之間的不同步問題。還有轉(zhuǎn)格式轉(zhuǎn)碼的服務(wù)，前面集群提供的是很低延遲的服務(wù)，里面一些，比如說編碼碼流，不能夠在傳統(tǒng)的CDN網(wǎng)絡(luò)分發(fā)，如果想在傳統(tǒng)的CDN網(wǎng)絡(luò)上分發(fā)，就要服務(wù)端的轉(zhuǎn)碼。還有就是轉(zhuǎn)協(xié)議，因?yàn)榍懊嫣峁┮粋€(gè)更低延時(shí)的服務(wù)，后面要在CDN網(wǎng)絡(luò)上分發(fā)，所以協(xié)議也需要轉(zhuǎn)。
圖 3
圖3是線上娃娃機(jī)的APP版本的架構(gòu)圖，這里的是特色是線上娃娃機(jī)可以實(shí)時(shí)推兩路視頻流，上機(jī)玩家可以隨時(shí)任意去切其中一路畫面去看。這兩路視頻流首先通過我們超低延時(shí)服務(wù)器集群，同時(shí)上機(jī)玩家也可以推一路流上去，可以給圍觀觀眾方看到這個(gè)人在抓娃娃時(shí)候的一些表情、反應(yīng)、語言，增加一種互動性。此外，玩家需要通過手機(jī)遠(yuǎn)程操控娃娃機(jī)，因此還需要實(shí)時(shí)信令的分發(fā)。
圖 4
接下來是娃娃機(jī)的H5架構(gòu)圖。在推流方面和APP版本沒有太大的區(qū)別，娃娃機(jī)一側(cè)還是走的私有協(xié)議。不同的地方是因?yàn)樗接袇f(xié)議沒有辦法直接讓H5拉到流，所以中間會加入一個(gè)媒體網(wǎng)關(guān)，作用是把我們的私有協(xié)議翻譯成H5可以識別的碼流格式，然后H5端通過websocket方式把這路流拉下來，這里需要媒體網(wǎng)關(guān)做到超低延時(shí)的轉(zhuǎn)換。簡單來看，這里的網(wǎng)關(guān)服務(wù)器只是做了一個(gè)分發(fā)服務(wù)，好像不會引入延時(shí)，實(shí)際上不然。因?yàn)閣ebsocket拉的是TCP的流，但是我們推的是UDP的，當(dāng)視頻幀很大的時(shí)候，一個(gè)幀數(shù)據(jù)就要切割成很多UDP包上行，服務(wù)器需要將這些UDP包攢起來，湊成一個(gè)完整的幀后才下發(fā)給H5,這樣才能保證不花屏，才能跑得通，所以這個(gè)攢包組幀的過程是會有延遲的。信令部分和APP部分基本是相似的。
2. 實(shí)時(shí)架構(gòu)的若干點(diǎn)思考
剛才介紹了實(shí)時(shí)音視頻的兩種場景，下面提出一點(diǎn)思考：實(shí)時(shí)音視頻有什么樣的特征?怎么樣去架構(gòu)一個(gè)實(shí)時(shí)音視頻系統(tǒng)?
這是仁者見仁，智者見智的問題。你可以通過很多方式把這個(gè)系統(tǒng)架構(gòu)起來，都會達(dá)到相對不錯(cuò)的效果。但是我認(rèn)為，無論怎樣，實(shí)時(shí)音視頻都有繞不過如下幾個(gè)點(diǎn)，只有把它們做好了，才能夠在業(yè)界有更高的知名度、更好的技術(shù)儲備。
第一是實(shí)時(shí)音視頻是不能等的，因?yàn)榈攘司筒皇菍?shí)時(shí)音視頻了。不能等，這里會引入一個(gè)矛盾。既然不能等，例如你把實(shí)時(shí)音視頻也看作一個(gè)消費(fèi)模型來看，那是提前生產(chǎn)還是按需生產(chǎn)?字面上理解很簡單，肯定是按需生產(chǎn)，需要的時(shí)候才生產(chǎn)，如果提前生產(chǎn)就是延時(shí)了。但是并不是每一個(gè)點(diǎn)都做成按需生產(chǎn)是合理的。舉一個(gè)例子，比如你要去播放一段音頻，最好的做法是系統(tǒng)或者驅(qū)動告訴你，它需要數(shù)據(jù)了，然后去解一幀塞給它，這就是按需生產(chǎn)。但是為什么還有提前生產(chǎn)一說呢?就是系統(tǒng)告訴你它要數(shù)據(jù)的時(shí)候，實(shí)際上它有一個(gè)對響應(yīng)周期的要求。你現(xiàn)去生產(chǎn)可能就要等去解完一幀，但是這個(gè)時(shí)候來得及嗎?如果你只有一路下行，可能就來得及。但是現(xiàn)在要求很多路下行，在很短的時(shí)間周期內(nèi)解很多幀，對硬件性能有很高的要求。通常來講，并不可取。這只是實(shí)時(shí)音視頻中一個(gè)簡單的例子。提前生產(chǎn)會引入延遲的，那么到底要提前多久生產(chǎn)，怎么樣動態(tài)估計(jì)我們什么時(shí)候應(yīng)該生產(chǎn)?這是一個(gè)開放性的問題，也是一個(gè)大家在設(shè)計(jì)系統(tǒng)時(shí)要重點(diǎn)考慮的。
第二是實(shí)時(shí)音視頻不能久等。實(shí)時(shí)音視頻中有些等待是避免不了的，例如你要做音頻編碼，它本來一定要20毫秒一幀或者40毫秒一幀去做，給一個(gè)采樣點(diǎn)點(diǎn)是編不了的。這里既然有些延遲和等待避免不了，我們當(dāng)然希望系統(tǒng)處理的粒度越低越好，這樣可能會帶來更低的延時(shí)。但是處理的粒度越低，整個(gè)系統(tǒng)在頻繁跑的時(shí)候，你可以認(rèn)為它是一套循環(huán)，當(dāng)循環(huán)的東西很少，這個(gè)循環(huán)就會跑很多次，對系統(tǒng)來說就是一個(gè)很大的開銷和負(fù)擔(dān)。所以不能久等的時(shí)候，我們當(dāng)然希望它處理粒度小。另外處理粒度小還有一個(gè)優(yōu)勢，在整個(gè)系統(tǒng)中并不能保證每一個(gè)環(huán)節(jié)的處理粒度是一致的。例如這個(gè)節(jié)點(diǎn)可能要求是10毫秒，下一個(gè)結(jié)點(diǎn)要求15毫秒，這是由于算法的限制，可能沒有辦法避免。如果在整個(gè)系統(tǒng)內(nèi)選一個(gè)相對小的粒度，在粒度拼接的時(shí)候，例如10-15毫秒，要兩個(gè)10毫秒才能夠15毫秒，還剩下5毫秒，剩的就比較少。如果粒度很粗，可能剩下的東西就很多。在粒度拼接的時(shí)候，這個(gè)剩余的量代表了整個(gè)鏈路中的延遲。所以我們希望處理粒度盡量小，但是又不能小到整個(gè)系統(tǒng)沒有辦法接受的粒度。
第三，實(shí)時(shí)音視頻不能死等。例如你需要接收一個(gè)網(wǎng)絡(luò)包的時(shí)候，這個(gè)包遲遲不到，這個(gè)時(shí)候你不能完全不等，完全不等就會卡。但是在等的時(shí)候有一個(gè)超時(shí)的機(jī)制，例如這個(gè)音頻包就是很久不到，就把它跳過去做一個(gè)糾幀補(bǔ)償，當(dāng)包最終還是到了的時(shí)候，我也只能把它扔掉，而不應(yīng)該把它利用起來。
圖 5
此外，實(shí)時(shí)音視頻在服務(wù)器端還需要深入考慮這樣幾個(gè)問題：第一是負(fù)載均衡。第二是就近接入，第三是質(zhì)量評估，第四是動態(tài)路由，第五是算法流控。
第一，負(fù)載均衡是說讓整個(gè)服務(wù)器的每一個(gè)節(jié)點(diǎn)都承擔(dān)相對均勻的服務(wù)，不至于使得某一個(gè)節(jié)點(diǎn)負(fù)載過高造成一些丟包，造成網(wǎng)絡(luò)往返時(shí)的增大，這樣對任何的網(wǎng)絡(luò)損傷來講，對實(shí)時(shí)音視頻都會造成比較大的延遲增加。
第二是就近接入，這里的“近”并不是指地域上的近，而是“網(wǎng)絡(luò)上的近”。很簡單的例子，我們在深圳做推流，香港離得很近，可以推到香港的服務(wù)器，但實(shí)際上這畢竟是一個(gè)跨域的網(wǎng)絡(luò)，有不穩(wěn)定的因素在里面，所以我們寧愿推遠(yuǎn)一點(diǎn)。這個(gè)近指的應(yīng)該是在網(wǎng)絡(luò)質(zhì)量評估意義上的近，例如網(wǎng)絡(luò)往返時(shí)很小、往返時(shí)很平穩(wěn)、分布在延遲比較大的時(shí)刻不會還具有很大的概率，丟包率很低等。
要做到就近接入，這個(gè)近要有一個(gè)很好的質(zhì)量評估體系。質(zhì)量評估方法有兩種：
- 事后質(zhì)量評估。在復(fù)盤的時(shí)候，例如這個(gè)網(wǎng)絡(luò)平穩(wěn)的運(yùn)行了一個(gè)月，復(fù)盤看一下整個(gè)月中的質(zhì)量怎么樣，這樣的質(zhì)量評估可以認(rèn)為是一個(gè)相對離線的評估，它能夠給我們提供一個(gè)指標(biāo)，最近一個(gè)月的網(wǎng)絡(luò)和上個(gè)月相比是否有所改善。我們可以從中學(xué)習(xí)到一些經(jīng)驗(yàn)，例如這個(gè)月和上個(gè)月的調(diào)度上有些策略上的不同。這是一個(gè)系統(tǒng)化的經(jīng)驗(yàn)總結(jié)和優(yōu)化的方法。
- 實(shí)時(shí)質(zhì)量評估。更重要的應(yīng)該是一個(gè)實(shí)時(shí)上的評估，例如我現(xiàn)在推流，能夠?qū)崟r(shí)監(jiān)控到當(dāng)前的質(zhì)量是怎么樣的，就可以做到實(shí)時(shí)動態(tài)路由。實(shí)時(shí)動態(tài)路由是說某個(gè)人推流從北京推到迪拜，有很多鏈路可以選，他可能根據(jù)之前的一些經(jīng)驗(yàn)，假如他之前經(jīng)驗(yàn)告訴你，直接推到迪拜，這個(gè)鏈路是很好的，但是畢竟有個(gè)例。有動態(tài)實(shí)時(shí)的質(zhì)量評估，就知道這個(gè)時(shí)候推迪拜是否好，如果不好，可以在用戶無感知的情況下更換，隨時(shí)增減整個(gè)鏈路中一些路由的節(jié)點(diǎn)。這就是動態(tài)路由的思路。
實(shí)時(shí)動態(tài)路由是說某個(gè)人推流從北京推到迪拜，有很多鏈路可以選，他可能根據(jù)之前的一些經(jīng)驗(yàn)，假如他之前經(jīng)驗(yàn)告訴你，直接推到迪拜，這個(gè)鏈路是很好的，但是畢竟有個(gè)例。有動態(tài)實(shí)時(shí)的質(zhì)量評估，就知道這個(gè)時(shí)候推迪拜是否好，如果不好，可以在用戶無感知的情況下更換，隨時(shí)增減整個(gè)鏈路中一些路由的節(jié)點(diǎn)。這就是動態(tài)路由的思路。
實(shí)際情況中是結(jié)合前面這4個(gè)點(diǎn)，在我們的網(wǎng)絡(luò)和服務(wù)器資源集中，去選出質(zhì)量最優(yōu)或者近似最優(yōu)的鏈路來保證實(shí)時(shí)音視頻的服務(wù)的。但是資源集是有限的，沒有人可以保證你的資源集中一定可以選出的這個(gè)最優(yōu)具有很好的鏈路特征。保證不了就要考慮第五點(diǎn)，我即使選出了一個(gè)認(rèn)為是整個(gè)資源集中最優(yōu)的鏈路，但是它的質(zhì)量還達(dá)不到很好的標(biāo)準(zhǔn)，就要通過一些算法才能彌補(bǔ)。這些算法包括在一個(gè)不可靠的網(wǎng)絡(luò)中怎么樣進(jìn)行可靠的音視頻傳輸?shù)募夹g(shù)，這些技術(shù)在接下來我們會和大家稍微分享一下，也包括整個(gè)鏈路的一些擁塞控制。
3. 關(guān)于信源編碼的思考
圖 6
信源編碼是為了減少網(wǎng)絡(luò)中的負(fù)擔(dān)，把大量的數(shù)據(jù)壓縮成比較小的網(wǎng)絡(luò)數(shù)據(jù)，來減少網(wǎng)絡(luò)負(fù)擔(dān)的方式。壓縮方式有很多種，我們先以音頻來看，上面畫了一些圖(圖6)，我們重點(diǎn)看Opus編碼器，它有幾種模式在里面，一種是線性預(yù)測模式，還有一種是混合模式，還有一種是頻域編碼模式。混合模式是把兩種編碼模式混合在一起，根據(jù)不同的情況進(jìn)行選擇。
圖6是一個(gè)編碼器，橫軸是碼率，縱軸是它的質(zhì)量，中間是各種音頻編解碼器的表現(xiàn)。你會發(fā)現(xiàn)線性預(yù)測的方式能夠在低碼率上提供比較好的質(zhì)量，但是在20K左右的時(shí)候就沒有曲線了，因?yàn)樗恢С帜敲锤叩拇a率。然后看MDCT編碼，它可以在比較高的碼率上達(dá)到近似透明的音質(zhì)。音頻編碼器是有不同的編碼原理在里面的，像這種LP Mode是模擬人的發(fā)聲模型，既然有了數(shù)學(xué)建模，它的特征是能夠在一個(gè)比較低的碼率上提供一個(gè)比較可靠的質(zhì)量。但是它的特點(diǎn)是容易達(dá)到一種質(zhì)量上的飽和，也就是說當(dāng)你碼率給它很高的時(shí)候，實(shí)際上它也就編的效果還是那樣，因?yàn)樗吘故且环N參數(shù)化的編碼。所以根據(jù)業(yè)務(wù)場景，當(dāng)你需要一個(gè)很高的音質(zhì)，又需要音樂場景的時(shí)候，選擇它明顯不合適。MDCT MODE沒有任何的模型在里面，實(shí)際上就是把信號轉(zhuǎn)換成頻域，直接去量化。既然沒有模型化，它是比較消耗碼率的，但是它可以在一個(gè)較高的碼率上提供很好的質(zhì)量，可是低碼率的表現(xiàn)遠(yuǎn)遠(yuǎn)不如模型化的方法。
圖 7
整體總結(jié)起來，音頻包括語音和音樂兩種，因此有適合語音的codec和適合音樂的codec。第一種codec適合語音，語音可以模型化，適用于語音的codec能夠在低碼率上提供很好的質(zhì)量，提供一個(gè)相對高的壓縮比,但是它容易達(dá)到飽和，不能夠提供一個(gè)近似于透明的音質(zhì)。另外一種codec的編碼原理不一樣，能夠把音樂、語音都編得很好，但是特點(diǎn)是不能夠提供太高的壓縮比，指望它能夠在低碼率下提供很高的編碼質(zhì)量是做不到的。
圖 8
關(guān)于視頻編碼，最簡單的幾個(gè)點(diǎn)有I幀、P幀、B幀。I幀是自參考，P幀是向前參考，它會參考?xì)v史幀的特性進(jìn)行編碼。B幀是雙向參考，它可以參考前面的幀，也可以參考后面的幀。B幀可以帶來更高的壓縮比，提供更好的質(zhì)量。但是因?yàn)樗鼤⒖紝淼膸?，所以會引入延遲，因此我們在實(shí)時(shí)音視頻系統(tǒng)中是很少用到B幀的。
想要做好實(shí)時(shí)的音視頻系統(tǒng)，流控是一定要做的，流控對視頻的編解碼有什么要求?至少有一點(diǎn)，編解碼器的碼控一定要很穩(wěn)定。為什么?舉例說，我現(xiàn)在有一個(gè)很好的擁塞控制策略，帶寬估計(jì)做得很好，一點(diǎn)差錯(cuò)都沒有，估計(jì)出某一個(gè)時(shí)刻可分配視頻的帶寬就是500kbps，就可以讓視頻編碼器設(shè)置成500kbps。但是，如果碼控不是很穩(wěn)定，你設(shè)置500kbps的時(shí)候，視頻編碼器可能就跑到600kbps了，這樣就會帶來一些阻塞和延遲。因此，我們希望選擇的codec具有很好的碼控策略。
實(shí)際上一些開源代碼都是有做碼控的，但是直接拿來用并不是適合你的場景，因?yàn)檫@些開源代碼做起來，可能或多或少的考慮其他的場景，并不只是實(shí)時(shí)音視頻場景。比如說某個(gè)codec是用來是壓片的，希望半個(gè)小時(shí)或者一個(gè)小時(shí)之內(nèi)達(dá)到預(yù)定的碼率就可以，不會管這一秒鐘或者下一秒是什么樣子的，但是實(shí)時(shí)音視頻就是要求要把時(shí)間窗做得很小。
另外我們希望codec有分層編碼的能力。什么是分層編碼?為什么要有分層編碼?分層編碼也分兩種，一種是時(shí)域上的分層，一種是空域上的分層。前者是編碼的時(shí)候是當(dāng)前幀不參考上一幀，而是有隔幀參考的策略;后者可以認(rèn)為使用較低的碼率先編碼一個(gè)小的畫面，然后使用剩余的碼率編碼增量的部分，得到更高分辨率的畫面。 為什么要這樣做?實(shí)時(shí)音視頻中并不是很多場景都是一對一的，當(dāng)不是一對一，要做流控的時(shí)候，不可能因?yàn)槟骋宦酚^眾的下行不好，就把主播上行推流的碼率降下來，因?yàn)榭赡苓€有一千個(gè)觀眾的網(wǎng)絡(luò)很好，這些網(wǎng)絡(luò)好的觀眾也會因?yàn)閭€(gè)別觀眾網(wǎng)絡(luò)不好，而只能看到不那么清晰的畫面。所以要分層，可以在服務(wù)器端選擇給用戶到底下發(fā)哪一層的，因?yàn)橛蟹謱硬呗?，如果這個(gè)人線路不好，只要選擇其中一個(gè)比較小的層次發(fā)給他就可以了，例如核心層，這樣可以緊緊利用核心層把整個(gè)視頻還原，可能會損傷一些細(xì)節(jié)或者幀率偏低，但是至少整體可用。
最后，我想說一下，很多人認(rèn)為，視頻的數(shù)據(jù)量很大，視頻的延時(shí)比音頻應(yīng)該更高才對，實(shí)際上不是。因?yàn)楹芏嗟难舆t實(shí)際上是編解碼自有的延遲，如果編解碼中沒有B幀的話，你可以理解為視頻編碼是沒有任何延遲的。但是音頻編碼或多或少都會參考一些將來的數(shù)據(jù)，也就是說音頻編碼器的延時(shí)一定是存在的。因此，通常來講，音頻的延時(shí)比視頻的延時(shí)更高才對。
4. 關(guān)于信道編碼技術(shù)的思考
圖 9
信道編碼分幾個(gè)部分。一種是根據(jù)先驗(yàn)知識的網(wǎng)絡(luò)冗余編碼技術(shù)——前向糾錯(cuò)技術(shù)。以RS(4，6)編碼為例，我要發(fā)一個(gè)分組，這個(gè)分組有六個(gè)包，其中有四個(gè)包是實(shí)際媒體數(shù)據(jù)，有兩個(gè)包是冗余包。那么在解碼端收到六個(gè)包中任意的四個(gè)，就可以完全恢復(fù)所有攜帶媒體內(nèi)容的包。例如這里2、3都丟了，收到了1、4、r1、r2，也能夠完全恢復(fù)2和3。這樣看來很好，任意兩個(gè)丟掉都可以完全恢復(fù)。但是這樣的算法也有它的弱點(diǎn)，不太適合突發(fā)性的丟包。因?yàn)檫@個(gè)分組不宜太大，如果分組很大，分組就有很大的延時(shí)。分組如果很小，很可能整個(gè)分組都丟掉了。實(shí)際上這種做法就沒有任何意義。所以它不太適合突發(fā)性丟包，而且它畢竟是根據(jù)先驗(yàn)知識去做的一種冗余，也就是說它永遠(yuǎn)是根據(jù)上一時(shí)刻網(wǎng)絡(luò)的狀態(tài)作出的判斷，下一時(shí)刻網(wǎng)絡(luò)是什么樣的，是預(yù)測的東西。網(wǎng)絡(luò)是實(shí)時(shí)發(fā)生變化的，這種預(yù)測的東西并不完全可靠。所以它恢復(fù)的效率在實(shí)際網(wǎng)絡(luò)中相對比較低，而且這樣的算法復(fù)雜度相對比較高。當(dāng)然它也有優(yōu)勢，例如我們是提前算好的，一次性發(fā)過去，不需要等到你發(fā)現(xiàn)丟包時(shí)我再做怎樣的冗余傳輸，所以不受網(wǎng)絡(luò)往返的影響。而且這種分組可以任意、隨機(jī)調(diào)整大小冗余度，比較適合均勻丟包的場景。
圖 10
另外一項(xiàng)技術(shù)是丟包重傳技術(shù)。相對來說，丟包重傳相對RS來講，更有針對性，所以恢復(fù)效率比較高。第一個(gè)Go Back N技術(shù)是類似于TCP的傳輸技術(shù)，發(fā)送端在不斷的發(fā)包，接收端要負(fù)責(zé)告訴發(fā)送端我現(xiàn)在收到包的情況是怎么樣，收到的連續(xù)的幀的是序列號什么樣的。發(fā)送端發(fā)現(xiàn)發(fā)了10個(gè)幀，接收端只正確收到8，不管9號包或者10號包是否收到，都會丟包重傳。所以Go Back N技術(shù)有一定的目的性，維護(hù)的是丟包狀態(tài)，它知道哪些包是沒有收到的，但是并不精準(zhǔn)。
接下來是自動選擇重傳技術(shù)(Selective ARQ)。選擇性的重傳，是在接收端發(fā)現(xiàn)了哪個(gè)包丟了，然后才會讓發(fā)送端重新發(fā)送這個(gè)包。聽起來是非常好的一個(gè)技術(shù)，效率很高，丟了哪個(gè)包就重傳哪個(gè)包。但是它的弱點(diǎn)在于，你必須要假定這個(gè)包是頻密的發(fā)送才可以。例如發(fā)送端發(fā)出1、2、3、4這樣的包，但是一秒鐘才發(fā)一個(gè)包，什么時(shí)候發(fā)現(xiàn)2丟了呢?收到3的時(shí)候。如果2作為最后一包，永遠(yuǎn)發(fā)現(xiàn)不了丟掉了。也就是如果發(fā)包不頻密，至少需要1秒鐘才發(fā)現(xiàn)它丟。這個(gè)時(shí)候再讓它重傳，就很晚了。
所以在一個(gè)真實(shí)的系統(tǒng)中，選擇性重傳是首選，因?yàn)橐粢曨l的大部分場景是頻密的，但是可能也要結(jié)合一些Go-Back -N的做法。發(fā)一些確認(rèn)機(jī)制，這樣才能把重傳做得更加完備。另外所有的重傳都要至少等一個(gè)網(wǎng)絡(luò)往還時(shí)，因?yàn)闊o論是確認(rèn)丟包還是反饋收包情況，都需要一個(gè)網(wǎng)絡(luò)往返時(shí)，所以它的弱點(diǎn)是，它受網(wǎng)絡(luò)往返時(shí)影響比較大，如果控制不好，有可能造成重傳風(fēng)暴。優(yōu)勢是算法計(jì)算復(fù)雜比較低，且容易實(shí)現(xiàn)。另外，因?yàn)樗泻艽蟮尼槍π裕瑹o效的重傳包會比較少，針對突發(fā)性的丟包會有比較好的效果。
剛才講了針對不可靠網(wǎng)絡(luò)的兩種傳輸技術(shù)，前向糾錯(cuò)和丟包重傳，它們都有各自的優(yōu)點(diǎn)和缺點(diǎn)。實(shí)際上一個(gè)好的網(wǎng)絡(luò)分發(fā)技術(shù)應(yīng)該是將這兩種結(jié)合在一起的，根據(jù)不同的信道情況把這兩種技術(shù)結(jié)合在一起。
圖 11
圖11來自于網(wǎng)絡(luò)，首先從左下角藍(lán)色部分看起，當(dāng)網(wǎng)絡(luò)往返時(shí)很小，丟包率不高的時(shí)候就用重傳。但是當(dāng)網(wǎng)絡(luò)RTT很高的時(shí)候，在這個(gè)圖里面去看，就沒有選用重傳策略。從我個(gè)人的角度來看，我認(rèn)為這并不是一個(gè)非常合理的做法。因?yàn)閯偛盘岬搅耍現(xiàn)EC是一個(gè)無目的性的、根據(jù)先驗(yàn)知識去做的一種冗余技術(shù)，雖然當(dāng)RTT很高，重傳很耗時(shí)，但如果沒有重傳，要加很多冗余包，才能把丟掉的包完全恢復(fù)，實(shí)際就會帶來很大的資源浪費(fèi)。而且當(dāng)你丟包率很高的時(shí)候，可能還并不能夠完全恢復(fù)所有包。視頻只要丟幀就會很卡，視頻丟包率應(yīng)該控制在千分之幾以下，才可以達(dá)到順暢的可以觀看的水平。
圖 12
關(guān)于信道編碼的思考。信道編碼和網(wǎng)絡(luò)吞吐呈反比關(guān)系。無論是重傳性編碼還是冗余性編碼，都會占用帶寬，從而減低實(shí)際媒體信息的吞吐量?，F(xiàn)實(shí)的生活中，信道都有限制。當(dāng)你傳輸?shù)臅r(shí)候，就要根據(jù)信道的特征去做一些策略。信道如果有擁塞，我們就需要有一個(gè)擁塞控制的算法，去估計(jì)應(yīng)該把整個(gè)信道怎么樣做合理分配。
另外，在做一個(gè)系統(tǒng)的時(shí)候，想清楚如何去評價(jià)一個(gè)系統(tǒng)的效果是很重要的一個(gè)點(diǎn)。在信道編碼的時(shí)候，一個(gè)很重要的指標(biāo)是，信道編碼的有效性是什么樣子的。有效性分為兩種，一種是重傳或者冗余能否真的把丟掉的包補(bǔ)回來，這是一個(gè)有效性。即使這個(gè)包補(bǔ)回來了，但是如果經(jīng)過一個(gè)信道編碼策略之后，還有一些丟包。例如原來的丟包是20%，補(bǔ)回來變成1%，那么這個(gè)重傳在我們的評價(jià)當(dāng)中實(shí)際上是沒有效果的，因?yàn)?%的丟包對音頻來講是無所謂的，但是對視頻來講是很卡的。在這樣的評價(jià)系統(tǒng)中，補(bǔ)回來還有1%的丟包，那么所有的編碼都是沒有太大意義的。舉這個(gè)例子，如果在這時(shí)信道也發(fā)生擁塞，再進(jìn)行這樣的信道編碼，就不會達(dá)到很好的效果。這個(gè)時(shí)候是否應(yīng)該停止所有的信道編碼呢?
還有信道編碼有效性的判斷，衡量它是否好，就是加了多少冗余，冗余中有多少沒有被利用好，如果這些冗余像剛才那個(gè)例子那樣，6包帶2包的冗余，剛好丟掉2包，整個(gè)包都恢復(fù)出來了都使用到了，那就是百分之百的冗余都有效。如果4包信息丟了1包，卻帶了2包冗余，其中1包就沒有效果。所以想要做一個(gè)好的系統(tǒng)，應(yīng)該先想到如何評價(jià)這個(gè)系統(tǒng)的好壞。
5. 引入延遲的環(huán)節(jié)和降低延遲的思路
延遲的引入主要分三部分，一個(gè)是采集/渲染。這好像是很簡單一個(gè)部分，但是它引入延遲可能是最大的，可能是整個(gè)分發(fā)過程中最大的環(huán)節(jié)。有很多人不是特別理解，但實(shí)際上在即構(gòu)現(xiàn)有的網(wǎng)絡(luò)結(jié)構(gòu)中，網(wǎng)絡(luò)往返時(shí)的延遲都控制在50毫秒以內(nèi)，但是渲染和采集，尤其是渲染，幾乎沒有任何移動端系統(tǒng)可以保證它百分之百的50毫秒，這是一些硬件上的限制。如何去降低這些延遲?剛才我已經(jīng)舉了一個(gè)生產(chǎn)消費(fèi)模型的思路，到底是按需生產(chǎn)還是提前生產(chǎn)，這些都是可以仔細(xì)去考慮的。
還有編解碼會帶來一些延遲，尤其是音頻會帶來一些延遲。這些延遲中有些是避免不了的，我們就要根據(jù)實(shí)際的使用場景去減少這些延遲，這些都是要在具體形態(tài)上做一些權(quán)衡的東西。還有處理粒度上的考慮，也會影響整個(gè)系統(tǒng)的延遲。
還有一個(gè)延遲，大家都能看到的，就是網(wǎng)絡(luò)分發(fā)延遲。如何去減小?除了在資源集中找到一個(gè)最優(yōu)子集之外，還有信道編碼的東西，要做一個(gè)很好的信道編碼系統(tǒng)，我們?nèi)绾卧u價(jià)信道編碼系統(tǒng)的好壞。有了這些思路之后，可以指導(dǎo)我們?nèi)プ龈玫南乱徊降拈_發(fā)工作。
【本文為51CTO專欄作者“冼牛”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信號：xianniu1216)】
