為了保證音視頻的質(zhì)量，WebRTC底層做了大量的工作，尤其是網(wǎng)絡傳輸與服務質(zhì)量，更是其核心技術，本文由北京音視跳動科技有限公司 首席架構(gòu)師 李超在LiveVideoStack線上分享的演講整理而成，詳細解析了WebRTC底層技術與優(yōu)化在網(wǎng)絡質(zhì)量、傳輸實時性與服務質(zhì)量之間的矛盾以及平衡之道。

作者 | 李超

整理 | LiveVideoStack

非常高興和大家一同探討WebRTC傳輸是如何保證音視頻服務質(zhì)量的。

 

 

本次分享我將從四個方面向大家介紹一下WebRTC傳輸是如何保證音視頻服務質(zhì)量的。第一，實時通信的目標。我們首先需要確定實時通信的目標，才能夠知道要將實時通信做成怎樣的系統(tǒng)、保證怎樣的實時性;第二，WebRTC如何保障數(shù)據(jù)傳輸?shù)膶崟r性;第三，進行實時傳輸時，想要滿足實時性，網(wǎng)絡與服務質(zhì)量之間可能存在的矛盾;最后，就是WebRTC如何解決網(wǎng)絡與服務質(zhì)量之間的矛盾。

1. 實時通信的目標

1.1 實時通信的目標是什么?

 

 

首先提出兩個問題：第一，開會時你是喜歡在辦公室里，還是更喜歡在線上開?第二，如果有一場演唱會，你愿意去現(xiàn)場呢?還是愿意在線上聽?

1.2 線上與現(xiàn)在不同的原因

 

 

相信大家更多都會選擇線下，理由是線上線下感覺不一樣。其不同點在于：首先是攝像頭與人眼看到的效果不一樣，例如攝像頭采集的角度過小、無法拍到某些角度的畫面;其次是采集設備的質(zhì)量參差不齊，一場會議中大家所使用的設備有的高清、有的模糊;最后，也是最關鍵的一點就是現(xiàn)場的氣氛無法被攝像頭采集到，每個人都有自己的氣場，當大家聚集在一起時，現(xiàn)場氛圍感非常熱烈，但隔著屏幕無法感受到。

1.3 實時通信的目標

 

 

根據(jù)以上幾點，我們可以總結(jié)出實時通信最終的目標是：盡可能逼近或達到面對面交流的效果。從目前的情況來看，超越面對面交流的效果是幾乎不可能的。

2. 幾個重要指標

2.1 幾個重要指標

 

 

那么如何才能達到面對面交流的效果呢，這里涉及到幾個重要指標。

最為關鍵的是實時通信的延遲指標，只有將延遲指標搞清楚，才能知道做實時通信時，達到怎樣的延遲才算符合要求的，即接近面對面交流的效果。然后是音視頻服務質(zhì)量指標，延遲指標達到后，再根據(jù)這項指標判斷音視頻服務質(zhì)量的好壞。

2.2 實時通信延時指標

 

 

下面具體看一下延遲指標的分級標準。通過圖中表格可以看到，如果端到端延遲在200ms以內(nèi)，說明整個通話是優(yōu)質(zhì)的，通話效果就像大家在同一個房間里聊天一樣;300ms以內(nèi)，大多數(shù)人很滿意，400ms以內(nèi)，有小部分人可以感覺到延遲，但互動基本不受影響;500ms以上時，延遲會明顯影響互動，大部分人都不滿意。

所以最關鍵的一級是500ms，只有延遲低于500ms，才可以說是合格的實時互動系統(tǒng)。

2.3 音頻服務質(zhì)量指標

 

 

接下來是音頻服務質(zhì)量指標，它根據(jù)MOS值來打分。4.0-5.0為“優(yōu)”，評值標準是聽得非常清楚，延時小，交流順暢;3.5-4.0為“良”，音質(zhì)稍差，聽得清，延時小，有點雜音;3.0-3.5為“中”，音質(zhì)較可，能聽清，有一定時延，可以交流;1.5-3.0為“差”，勉強能夠聽清，交流時需要重復多次才能夠表述清楚;0-1.5為“劣”，完全聽不清，延時大，交流不暢。

2.4 視頻服務質(zhì)量指標

 

 

視頻服務質(zhì)量的評價標準有幾個，它們也都是通過MOS值打分來判斷質(zhì)量好壞的，圖中參考是以碼流大小為標準評估指標。以640*480為例，如果想達到MOS值為4.5的優(yōu)質(zhì)效果，可以看到產(chǎn)生的碼流的大小大概在3Mbps左右。這樣的碼流對于實時傳輸來說太大了，如果是640*480的視頻占用3Mbps的帶寬，那是一件非常奢侈的事兒。一般情況下，我們會選擇MOS值為3.5(綠色線)的碼流，其碼流范圍在600kbps左右。

從以上可以看到，在保證傳輸?shù)膶崟r性時，由于帶寬是一定的，可能會犧牲一定的服務質(zhì)量。

3 主要矛盾

3.1 實時通信與服務質(zhì)量的矛盾

 

 

通過了解上述三個指標，我們可以得到實時通信與服務質(zhì)量的主要矛盾。

第一，碼流與帶寬之間的矛盾。要想達到好的質(zhì)量，碼流一般會比較大(當然，不能超過最大碼流)，而帶寬是有限的，于是碼流和帶寬之間就會產(chǎn)生矛盾;第二，實時性和服務質(zhì)量之間的矛盾。通常為了保證好的實時性我們會選擇UDP，而UDP不保證網(wǎng)絡傳輸?shù)目煽啃?，丟包、亂序是經(jīng)常發(fā)生的。一旦出現(xiàn)丟包、亂序，網(wǎng)絡傳輸質(zhì)量就無法得到保證，最終會影響到音視頻的質(zhì)量。

 

 

這里我們就可以總結(jié)出實時通信的主要矛盾，即：音視頻的質(zhì)量與帶寬大小、實時性和網(wǎng)絡質(zhì)量之間存在矛盾，其它包括3A問題都屬于次要矛盾。

4 解決矛盾方法

4.1 解決矛盾的方法

 

 

下面來看下解決矛盾的方法。對于WebRTC來說，主要從以下幾個方面解決主要矛盾：如何保障數(shù)據(jù)傳輸?shù)膶崟r性、如何提高網(wǎng)絡質(zhì)量、如何更準確的評估帶寬、如何平衡碼流與帶寬。

5 保障數(shù)據(jù)的實時性

對于WebRTC來說，為了保障數(shù)據(jù)的實時性，提供了兩種方法：一種是傳輸路徑的選擇，它首先會選擇最佳的傳輸路徑，使得端到端傳輸時采取最好、最短的傳輸路徑從而保障數(shù)據(jù)傳輸?shù)膶崟r性;另一種是傳輸協(xié)議的選擇，可以選擇TCP或者UDP。下面咱們先看一下WebRTC是如何選擇最佳傳輸路徑的。

5.1 選擇一條最好的路徑

 

 

圖為WebRTC路徑選擇的架構(gòu)圖。圖中包括三個端，A端、B端和C端，其中A和B在同一個局域網(wǎng)內(nèi)，對于WebRTC來說，如果發(fā)現(xiàn)同一局域網(wǎng)內(nèi)的兩端需要通信時，會選擇局域網(wǎng)內(nèi)直連，從而保障網(wǎng)絡路徑最短最優(yōu);如果是A和C通信，它們不在同一局域網(wǎng)內(nèi)，那么WebRTC會選擇P2P直連，做NAT穿越，如果穿越成功，便可進行直連，這樣路徑相對服務器中轉(zhuǎn)來說也比較短。只有在P2P不成功時，才會選擇服務端中轉(zhuǎn)。從圖中可以看到，當一端通過TURN服務器將數(shù)據(jù)傳輸給另一端時，其傳輸路徑明顯長于P2P直連，所以對于WebRTC來說，它一定會選擇最短、最優(yōu)的路徑，從而保障端到端的實時傳輸。

5.2 使用TCP還是UDP?

 

 

接下來看一下WebRTC對TCP/UDP協(xié)議的選擇。在網(wǎng)絡比較優(yōu)質(zhì)時，TCP/UDP都可以用于實時傳輸，但大多數(shù)情況下，我們首選UDP(后面會介紹UDP的優(yōu)勢);弱網(wǎng)環(huán)境下不能使用TCP;而在進行網(wǎng)絡穿越時，使用TCP又有較大的好處，在企業(yè)內(nèi)可以使用TCP訪問外網(wǎng)的80端口進行穿透。

5.3 為什么極端網(wǎng)絡環(huán)境下不能用TCP?

 

 

為什么在弱網(wǎng)環(huán)境下不能用TCP?這是由于TCP的機制所造成的。TCP的機制是發(fā)送、確認、丟包、重傳。正常情況下，數(shù)據(jù)從一端傳輸?shù)搅硪欢耸菦]有任何問題的，但當出現(xiàn)丟包時就會有較大的麻煩。

圖中顯示了多次丟包時的延遲情況：從客戶端向服務端發(fā)送數(shù)據(jù)包，服務端需要返回ACK消息進行確認; 客戶端收到確認消息后, 才能繼續(xù)發(fā)送后面的數(shù)據(jù)(有滑窗時也是類似的)。每次客戶端發(fā)完數(shù)據(jù)后，都會啟動一個定時器，定時器的最短超時時間是200ms。如果因某種原因，在200毫秒客戶端沒有收到返回的ACK包，客戶端會重發(fā)上一個包。由于TCP有退避機制，以防止頻繁發(fā)送丟失包，因此會將重發(fā)包的超時時間延長到400ms。如果重發(fā)包依然沒有收到確認消息，則下一次重發(fā)的超時時間會延長到800ms。我們可以看到，連續(xù)幾次丟包后，就會產(chǎn)生非常大的延遲，這就是TCP在弱網(wǎng)環(huán)境下不能使用的根本原因。

5.4 選擇UDP帶來的問題

 

 

由于TCP的機制問題，因此通常我們會選擇UDP來保障音視頻傳輸?shù)膶崟r性。UDP在實時性方面有優(yōu)勢，但缺點同樣明顯。由于UDP是不可靠傳輸，它只能盡力送達，所以出現(xiàn)丟包、亂序是常見的事兒，但對于網(wǎng)絡質(zhì)量來說，丟包是非常嚴重的事情，這就需要我們自己處理這個問題。下面咱們就來看看WebRTC是如何解決這個問題的吧!

6 如何提高網(wǎng)絡質(zhì)量

6.1 網(wǎng)絡質(zhì)量包含哪些指標

 

 

那么，WebRTC是如何處理UDP的網(wǎng)絡質(zhì)量的呢?

要想解決網(wǎng)絡質(zhì)量，首先要知道影響網(wǎng)絡質(zhì)量的幾個因素：它包括了丟包率、延遲時間、抖動、亂序。如果網(wǎng)絡丟包率低、延遲時間小、不抖動、不亂序，這就是非常優(yōu)質(zhì)的網(wǎng)絡啦。但如果丟包率很高，那么網(wǎng)絡質(zhì)量一定會很差。

6.2 造成丟包的原因

 

 

圖中是網(wǎng)絡基本的拓撲，造成丟包的原因有很多，如鏈路質(zhì)量差，當手機與基站連接時，由于信號不好會造成丟包，這就屬于鏈路差，這種情況在移動端是經(jīng)常發(fā)生的;第二是帶寬滿，比如一臺機子上行發(fā)送碼率比較大，而下行接收鏈路比較小，這時在上游的路由器會把數(shù)據(jù)緩存起來慢慢發(fā)送，但緩存是有限制的，一旦緩存被塞滿，后面就會造成大量丟包;第三是主動丟包，比如路由是跨運營商的，在不同運營商之間傳輸數(shù)據(jù)時，可能由于運營商未知的原因造成丟包;第四是光線被挖斷等偶然原因造成丟包。

6.3 減少丟包的方法

 

 

WebRTC主要通過兩種方式解決丟包：NACK和FEC。

6.4 NACK

 

 

NACK的作用是丟包重傳。從圖中你可以看到，WebRTC的發(fā)送端不停地向接收端發(fā)送RTP包，接收端每隔一小段時間，就對這段時間內(nèi)的丟包情況進行統(tǒng)計。如果發(fā)現(xiàn)丟包，它會給發(fā)送端回一個NACK消息，NACK消息中記錄了這一段時間內(nèi)哪些包丟失了。發(fā)送端收到NACK后，會在之前的發(fā)送歷史記錄中找到丟失的包并重新發(fā)送。

6.5 NACK適合使用的場景

 

 

當然，通過NACK重傳，會產(chǎn)生一定的延時，該延時包括：等待發(fā)送NACK的時間(10或20ms)，NACK經(jīng)過網(wǎng)絡的時延以及RTP的網(wǎng)絡時延和重傳RTP包的網(wǎng)絡時延，即1.5RTT+10或20ms。通過這個公式我們可以知道，如果RTT時延比較大，比如200ms，那么1.5RTT就是300ms。通過前面講述的實時傳輸延時指標我們可以知道，端到端實時傳輸?shù)臅r延需要控制在500ms之內(nèi)，如果僅數(shù)據(jù)的網(wǎng)絡傳輸就占了300ms，那數(shù)據(jù)再經(jīng)過采集、編碼、解碼、渲染等流程，這些處理時間加在一起很有可能就超過500ms。

所以可以得出結(jié)論，丟包重傳僅適用于網(wǎng)絡傳輸時延比較小的情況，如果RTT比較大時，就不適合使用丟包重傳來保障網(wǎng)絡質(zhì)量了。

6.6 FEC

 

 

FEC的作用是通過冗余數(shù)據(jù)解決丟包。實際上，它就是一個異或操作。如圖所示，假設傳輸?shù)臄?shù)據(jù)是Data1和Data2，這兩個數(shù)據(jù)如果在傳輸?shù)倪^程中沒有FEC進行保護，其中一個數(shù)據(jù)丟失了，那只能通過NACK重新找回。那么，能否在傳輸過程中加一些冗余數(shù)據(jù)，以保證接收時，當某一個數(shù)據(jù)丟失后，不經(jīng)過重傳就可以將丟失的包找回來呢?這就是FEC。

在圖中我們可以看到，Data1和Data2同時發(fā)送到對端，在發(fā)送時對它們做一下異或操作，即Data1的最后一位0與Data2的最后一位0異或為0，Data1的倒數(shù)第二位1與 Data2的倒數(shù)第二位1異或為0，依次類推，最后就產(chǎn)生了冗余數(shù)據(jù)R，同時將三個包從一端傳輸?shù)搅硪欢恕鬏斶^程中，如果Data1丟失，通過Data2和冗余包R就可以將Data1找回來。找回包的算法也是異或操作，即在接收端將Data2的每一位與冗余包中的相同位進行異或操作就算出了Data1。這就保證了不用重新請求，就將丟失包找回的作用。

而且異或具有傳遞性，A、B、C三個包可以同時異或得到D，如果其中任意一個包丟失，可以通過D和其它包找回丟失的包。

6.7 ULPFEC

 

 

對于WebRTC來說，它默認使用的是ULPFEC。其原理是，將要傳輸?shù)臄?shù)據(jù)包先進行分組，如將三個包分為一組，然后為這一組包產(chǎn)生一個冗余包，如果這一組中某個包丟失了，就可以通過冗余包和其它包的異或操作將其找回。從圖中第一行可以看到1和2到了，3丟了，通過R1可以找回3，第三行同樣可以找回9。其缺點是，如果連續(xù)的兩個包都丟失了，這種算法就失效了，比如第二行4和5丟失后，通過6和R2無法找回它們。

6.8 FlexFEC

 

 

于是就有了改進的FlexFEC，它做了雙向冗余處理，不僅橫向做了冗余，而且縱向也做了冗余。

此時，當4和5同時丟失時，通過1、7和C1可以找到4，2、8和C2可以找到5，這樣就可以找回連續(xù)的兩個丟包。當然它也有弊端，其弊端是無法處理批量的連續(xù)丟包，例如連續(xù)丟失了10個包，F(xiàn)lexFEC對這種情況也無能為力。

以上就是WebRTC對于丟包的解決方法，通過“NACK+FEC”防止丟包。

6.9 如何解決抖動和亂序

 

 

下面來說說抖動和亂序。抖動的意思是，一會兒來了很多包，一會兒又一個沒有，包是一波一波的來，包到達的時間很不平均;而亂序指的是先發(fā)的包后到了，后發(fā)的包先到了。

WebRTC處理抖動和亂序使用的是JitterBuffer和NetEQ。JitterBuffer用于處理視頻包，NetEQ用于處理音頻包。它們的原理大致相同(NetEQ更為復雜一些)，都是通過一個隊列(緩存區(qū))對接收到的數(shù)據(jù)做下緩沖，然后再從隊列的另一端將數(shù)據(jù)包一個個均勻的取出， 這樣取出的數(shù)據(jù)就是平滑的了。

對于亂序的處理也比較好解決，如圖中所示，每個RTP包進來的時候有一個序號(Sequence Number)，在數(shù)據(jù)進入隊列時，它會根據(jù)序號插到對應的位置上，比如圖中104、107包已經(jīng)到達，并且在對應的位置上，而103、105和106沒來，位置就空著，等它們來了再插入對應的位置，這樣就可以防止亂序，所以通過JitterBuffer和NetEQ就可以同時解決亂序和抖動了。

總結(jié)一下，NACK和FEC解決丟包問題，NACK會增加時延，F(xiàn)EC會占用帶寬。JitterBuffer解決視頻的亂序與抖動，NetEQ解決音頻的亂序與抖動。

6.10 網(wǎng)絡延時產(chǎn)生的原因

 

 

說到延時，實際上就與帶寬評估有密切的關系了。延時的產(chǎn)生有兩個原因：第一是鏈路問題，正常的網(wǎng)絡上，數(shù)據(jù)包的傳輸都是時快時慢的;第二是發(fā)生了網(wǎng)絡擁塞，當發(fā)生擁塞后，數(shù)據(jù)包會進行緩沖，就會造成延時，而當緩沖溢出時，就出現(xiàn)了丟包。

所以對于延時來說，我們需要解決的是因擁塞而造成的延時，鏈路問題無法解決。下面咱們就來看看WebRTC是如何防止擁塞的。

7 準確的帶寬評估方法

7.1 如何解決抖動和亂序

 

 

WebRTC防止擁塞的根基是有準確的帶寬評估方法。它提供了兩種帶寬評估方法，一種是基于丟包的帶寬評估，另一種是基于延時的帶寬評估。而基于延時的評估方法又分為接收端(Goog-REMB)和發(fā)送端(Goog-TCC)的帶寬評估方法，目前默認采用的是Goog-TCC方法，因為其相對來說更為精準。

7.2 基于丟包的帶寬評估

 

 

基于丟包的帶寬評估方法比較簡單，根據(jù)丟包率進行計算。實際上，正常帶寬也有一定的丟包，如果丟包率<2%，屬于網(wǎng)絡質(zhì)量不錯的正常丟包，說明帶寬還沒有達到上限，應該增加評估的帶寬值。舉個例子，比如你家里的帶寬是8M，WebRTC最開始是不知道你家里的真實帶寬的，它必須一點點測量，所以一開始它先給你的帶寬設置一個假設值，即500K，當發(fā)現(xiàn)丟包率很低時，它再增加帶寬的評估值，如從500K升到1兆，如果丟包率還是很低，就會加到1.5兆、2兆……，帶寬評估值增加的速度是每次增加8%;如果丟包率>10%，說明發(fā)生擁塞了，此時應該立即降低帶寬，公式如圖(loss>0.1時)所示。如果丟包率<10%，說明現(xiàn)在的帶寬評估的比較準確，此時應該保持這個帶寬，不增加也不減少;

7.3 基于延時的帶寬評估

 

 

基于延時的帶寬評估方法比基于丟包的評估更好一些，因為它可以提前預估是否發(fā)生了擁塞。基于丟包的評估丟包率一旦超過10%就說明可能已經(jīng)發(fā)生擁塞了，而網(wǎng)絡一旦擁塞，再想恢復回原來的狀態(tài)，需要花費一段時間，而這段時間就會影響音視頻的服務質(zhì)量。

而基于延時的帶寬評估就不會產(chǎn)生這種情況。它的基本原理是，如果接收到的數(shù)據(jù)包的網(wǎng)絡傳輸時延在持續(xù)增長，就說明網(wǎng)絡變差了，當達到一定程度時，就要將評估的帶寬值降下來，以防止發(fā)生網(wǎng)絡擁塞。它的計算公式是根據(jù)狀態(tài)機來的(狀態(tài)機比較復雜，我這里就不講了)，當狀態(tài)非常好時，需要增加帶寬，同丟包增加帶寬一樣，每次增加8%;如果延時一直累加，則需要降低帶寬，帶寬降為原來85%，其它情況就保持當前帶寬，無增無減。

8 媒體數(shù)據(jù)與帶寬的平衡

8.1 媒體數(shù)據(jù)與帶寬的平衡

 

 

當帶寬評估準確之后再進行控制就非常容易了。接下來，我們看一下WebRTC如何平衡媒體數(shù)據(jù)與帶寬。

帶寬評估方法和網(wǎng)絡質(zhì)量的提升在前面我已經(jīng)介紹了。在有限的帶寬下，如何才能提供更好的音視頻服務質(zhì)量，是人們一直孜孜不倦追求的目標。因此在同等條件下，可以將數(shù)據(jù)壓縮的更小，一直是解決服務質(zhì)量的一種關鍵方法。目前最常用的視頻編碼器還是H.264，不過新的編碼器已經(jīng)有了很大突破VP9/H265、AV1/H266提供了更高的壓縮率，這使得我們在網(wǎng)絡條件有限的情況下，可以傳輸更多的數(shù)據(jù)從而保障更好的服務質(zhì)量。

另一方面，在帶寬相同且碼流無法壓縮的情況下，還可以采用動態(tài)碼率。通常，在使用動態(tài)碼率時，我們可以直接從產(chǎn)品上看出來，你會發(fā)現(xiàn)視頻一會兒清晰，一會兒模糊。即在帶寬小時，編碼器壓縮碼流，此時視頻變得模糊;帶寬大時，編碼器放大了碼流，所以視頻變得清晰。以上就是通過減少數(shù)據(jù)量的方法來保障實時通信質(zhì)量的。

8.2 Simulcast與SVC

 

 

除此之外，還可以通過Simulcast或SVC解決質(zhì)量問題。Simulcast和SVC解決問題的思路是類似的，它們會在發(fā)送端增大碼流的發(fā)送，將數(shù)據(jù)先傳給服務端，然后由服務端根據(jù)接收端帶寬的不同，選擇合適的碼流下發(fā)。對于網(wǎng)絡較差的用戶，傳輸清晰度低的碼流，對于網(wǎng)絡較好的用戶，傳輸高清晰度的碼流。所以這兩種技術對于發(fā)送方的帶寬和質(zhì)量有非常高的要求。

SVC與Simulcast最大的區(qū)別：SVC上傳的是一路碼流，但這一路碼流是由多層構(gòu)成的。服務端會按照不同接收端的帶寬大小，選擇傳輸不同的層。如上圖所示，手機端帶寬小，就傳輸小的一層數(shù)據(jù)，PC端帶寬大，就將所有層全部傳輸過去;而Simulcast上傳的是多路流，一般分為小、中、大三路。對手機端傳輸小的一路，對PC端傳輸最大的一路。Simulcast的好處在于，每一路流都是獨立的，所以可以對每一路流使用硬件編解碼器，而 SVC的分層方式目前沒有硬件支持，所以無法通過硬件加速。

8.3 流控

 

 

當帶寬評估準確后，如果發(fā)送的的碼流還是大于帶寬大小，此時就需要通過流控來進行控制了。流控的作用是當輸出碼流大于帶寬時，降低發(fā)送碼率，以防止發(fā)生擁塞。當然它會導致時延的增加。實際上，對于流控來說，它需要控制兩個點：第一個點是Pacer，降低發(fā)送碼率。當然僅降低發(fā)送碼率還不夠，因為如果編碼器仍然輸出大量碼流給Pacer，那么Pacer 的緩沖區(qū)遲早會被撐爆。所以在控制Pacer讓它減少發(fā)送碼率的同時，一定要降低音視頻的編碼器的輸出碼率，從而保持平衡，進而使數(shù)據(jù)平緩下行。

正如我前面所說的，流控雖然防止了網(wǎng)絡擁塞的發(fā)生，但會增加一些延時，增加的延時最終會反應到實時通信的總指標里，總的延時必須控制在500ms以內(nèi)。比如以前端到端時延是200ms，由于帶寬不足，時延增加到300ms、400ms都是可以的，但一定不要超過500ms。

此外，對于編碼器的輸出碼流來說，如果流控通過直接降低碼流仍然不能與帶寬適配時，還可以通過降低分辨率的方式來降低碼流。總之，在帶寬不足時，要想盡辦法減少數(shù)據(jù)量。實在不行，也可以關掉視頻只保留音頻來保障網(wǎng)絡的暢通。

9 總結(jié)

 

 

總結(jié)一下，對于服務質(zhì)量保障，首先提高網(wǎng)絡質(zhì)量，NACK和FEC解決丟包問題，JitterBuffer解決視頻的亂序與抖動，NetEQ解決音頻的亂序與抖動;帶寬評估通過Goog-REMB和Goog-TCC，還有丟包的帶寬評估;為了保障實時性，需要選擇更優(yōu)質(zhì)的線路，比如客戶端與服務端通信的時候選擇更好的路線節(jié)點，保證云端網(wǎng)絡帶寬等等;從業(yè)務上，減少數(shù)據(jù)量可以用AV1、SVC、Simulcast、動態(tài)碼率，減少業(yè)務;在防擁塞上，通過Pacer進行流控，只要能控制在500ms之內(nèi)，適當增加時延也是可以接收的。

以上就是本次分享的全部內(nèi)容，謝謝!

Q&A (部分)

1. 路徑的選擇是WebRTC內(nèi)部自動選擇的嗎?

是自動選擇的。WebRTC會自動判斷通信的雙方是否在同一個局域網(wǎng)內(nèi)，如果是就直接在局域網(wǎng)內(nèi)建立連接;如果不是，會通過STUN協(xié)議獲取各自的外網(wǎng)地址，然后進行NAT穿越;如果還不成功的話，才會選擇TURN服務進行數(shù)據(jù)中轉(zhuǎn)。

2. WebRTC網(wǎng)絡傳輸質(zhì)量衡量指標有什么?

衡量任何一個實時傳輸系統(tǒng)時，首要看它的時延是否達到500ms以內(nèi)。其實500ms對于實時通信而言，也是比較苛刻的標準了，因為網(wǎng)絡的變化是非常大的， 所以要實現(xiàn)這個指標其實難度也是蠻大的。其次是丟包率，這是非常關鍵的指標，剛才說到2%的丟包率代表網(wǎng)絡比較好;小于10%，對于WebRTC來說，代表目前的帶寬是準確的;超過10%則代表發(fā)生了擁塞。有些廠商說它的產(chǎn)品可以抗xx%的丟包，這樣的前提是不認為丟包是一個指標，但在真網(wǎng)絡中，當路由的緩沖被撐爆后，必然會出現(xiàn)大量丟包，如果不把丟包當作指標的話，就缺少了一種判斷網(wǎng)絡擁塞發(fā)生的條件，這顯然是不合理的。

3. 視頻JitterBuffer怎么具體控制平滑的?

其實JitterBuffer平滑處理的難度并不像我們想像的那樣復雜，之所以大家認為它復雜，可能是因為一些額外的因素，如還要處理音視頻同步等問題。對于平滑處理，我們完全可以自己通過一個Buffer來實現(xiàn)。Buffer可以是動態(tài)大小或固定大小。為了簡化，我們假設它是固定大小，比如定義一個可以存放 100 個元素的數(shù)組，在數(shù)組的一頭每隔 10 毫秒取一個包，這就是一個最簡單的平滑處理。當然更好的方式是可以根據(jù)網(wǎng)絡的變化讓這個平滑數(shù)組的大小也動態(tài)變化，這樣就更高級一些。當然，如果Buffer是動態(tài)變化的，那在計算平滑數(shù)組的動態(tài)大小時，會稍難一些。

4. WebRTC要和SIP客戶端通訊有什么好的方案?

一般與SIP通信最好借助流媒體服務器比如Janus，它既支持SIP協(xié)議也能支持WebRTC客戶端。這樣SIP終端就可以將數(shù)據(jù)傳輸流媒體服務器，然后再轉(zhuǎn)發(fā)給WebRTC終端了，同理WebRTC終端也可以通過流媒體服務器與SIP終端通信了。

5. FEC和NACK默認是不是都要開啟?

是的。對于WebRTC來說，F(xiàn)EC和NACK都是開啟的，也可以控制它們的開關。

6. 能說下為什么TCC比REMB準確嗎?

TCC和REMB主要有兩個區(qū)別。第一是計算的端不同，REMB是在接收端計算的，接收端計算后再將結(jié)果返回給發(fā)送端進行控制，而在回傳結(jié)果時，可能網(wǎng)絡又發(fā)生了新的變化，這就造成了REMB的及時性不夠;TCC是將所有數(shù)據(jù)都交給發(fā)送端做計算和控制，因此及時性和準確度會更高。第二是濾波器不同，REMB是卡爾曼濾波器(Kalman)，TCC是最小二乘法濾波器(Trend line)。最小二乘法濾波器在網(wǎng)絡延時評估這方面比卡爾曼濾波器效果更好一些。

7. 在內(nèi)網(wǎng)環(huán)境下p2p想讓延時盡可能小，可以做哪些工作?實驗室環(huán)境最小延時可以達到100ms以下嗎?

如果在同一個局域網(wǎng)內(nèi)，實際只有幾十毫秒的延遲。有同學可能會疑惑，有的產(chǎn)品在同一局域網(wǎng)內(nèi)延遲非常小，為什么用WebRTC反而延遲增大了?這就是因為WebRTC為保障網(wǎng)絡質(zhì)量，在內(nèi)部通過多種機制，各種緩沖，來做到的。所以它必然會產(chǎn)生一定的延遲，也就是拿延遲換質(zhì)量。而在局域網(wǎng)內(nèi)，網(wǎng)絡基本沒有延時，不丟包、不抖動、不亂序。這時什么策略都不采用，網(wǎng)絡的傳輸才是最快的，因此在內(nèi)網(wǎng)通信時，WebRTC的實時性一定不如什么策略都不加的產(chǎn)品好。

8. ULPFEC和FLEXFEC區(qū)別是?

ULPFEC只能進行單向冗余處理，而FLEXFEC可以進行雙向冗余處理，即可以橫向分組還可以縱向分組做冗余，所以它的抗丟包性要比ULPFEC好，同時占的帶寬也比ULPFEC多。

9. 可靠性這塊，UDP上的WebRTC做ack是自己封裝了seq嗎?然后，一樣需要ack重傳的話，跟TCP SACK有什么區(qū)別呢?

WebRTC使用的是RTP協(xié)議傳輸數(shù)據(jù)。RTP協(xié)議中有seq字段。此外，WebRTC用的NACK與TCP的ACK機制不同。TCP每一塊數(shù)據(jù)都需要通過ACK進行確認，如果沒收到ACK就重發(fā)，直到成功收到ACK或斷連;而NACK允許丟包，當重傳多次不行時，就不傳了。且而即使重傳了數(shù)據(jù)包，在接收端發(fā)現(xiàn)它已經(jīng)過期時，也會將其丟掉。

10. WebRTC后面會用QUIC協(xié)議嗎?

這個問題爭論較大。WebRTC也在一直在嘗試使用QUIC協(xié)議，從我的角度來看，QUIC協(xié)議最主要的是解決Http3，Http3解決的是TCP的問題，就要保證數(shù)據(jù)的可靠性，那么實時性就會受到影響，什么時候QUIC如果可以解決好實時性問題就可以用，反之則不能。

從我的角度看，一種協(xié)議最好只解決一件事兒，很難通過一套協(xié)議解決所有問題。