1. 首頁 > 生活 > >

服務質量差距分析模型 服務質量評價模型

小知識



文章插圖
服務質量差距分析模型 服務質量評價模型

文章插圖
為了保證音視頻的質量，WebRTC底層做了大量的工作，尤其是網絡傳輸與服務質量，更是其核心技術，本文由北京音視跳動科技有限公司 首席架構師 李超在LiveVideoStack線上分享的演講整理而成，詳細解析了WebRTC底層技術與優化在網絡質量、傳輸實時性與服務質量之間的矛盾以及平衡之道 。
作者 | 李超
整理 | LiveVideoStack
非常高興和大家一同探討WebRTC傳輸是如何保證音視頻服務質量的 。
本次分享我將從四個方面向大家介紹一下WebRTC傳輸是如何保證音視頻服務質量的 。第一，實時通信的目標 。我們首先需要確定實時通信的目標，才能夠知道要將實時通信做成怎樣的系統、保證怎樣的實時性；第二，WebRTC如何保障數據傳輸的實時性；第三，進行實時傳輸時，想要滿足實時性，網絡與服務質量之間可能存在的矛盾；最后，就是WebRTC如何解決網絡與服務質量之間的矛盾 。
1. 實時通信的目標
1.1 實時通信的目標是什么？
首先提出兩個問題：第一，開會時你是喜歡在辦公室里，還是更喜歡在線上開？第二，如果有一場演唱會，你愿意去現場呢？還是愿意在線上聽？
1.2 線上與現在不同的原因
相信大家更多都會選擇線下，理由是線上線下感覺不一樣 。其不同點在于：首先是攝像頭與人眼看到的效果不一樣，例如攝像頭采集的角度過小、無法拍到某些角度的畫面；其次是采集設備的質量參差不齊，一場會議中大家所使用的設備有的高清、有的模糊；最后，也是最關鍵的一點就是現場的氣氛無法被攝像頭采集到，每個人都有自己的氣場，當大家聚集在一起時，現場氛圍感非常熱烈，但隔著屏幕無法感受到 。
1.3 實時通信的目標
根據以上幾點，我們可以總結出實時通信最終的目標是：盡可能逼近或達到面對面交流的效果 。從目前的情況來看，超越面對面交流的效果是幾乎不可能的 。
2. 幾個重要指標
2.1 幾個重要指標
那么如何才能達到面對面交流的效果呢，這里涉及到幾個重要指標 。
最為關鍵的是實時通信的延遲指標，只有將延遲指標搞清楚，才能知道做實時通信時，達到怎樣的延遲才算符合要求的，即接近面對面交流的效果 。然后是音視頻服務質量指標，延遲指標達到后，再根據這項指標判斷音視頻服務質量的好壞 。
2.2 實時通信延時指標
下面具體看一下延遲指標的分級標準 。通過圖中表格可以看到，如果端到端延遲在200ms以內，說明整個通話是優質的，通話效果就像大家在同一個房間里聊天一樣；300ms以內，大多數人很滿意，400ms以內，有小部分人可以感覺到延遲，但互動基本不受影響；500ms以上時，延遲會明顯影響互動，大部分人都不滿意 。
所以最關鍵的一級是500ms，只有延遲低于500ms，才可以說是合格的實時互動系統 。
2.3 音頻服務質量指標
接下來是音頻服務質量指標，它根據MOS值來打分 。4.0-5.0為“優”，評值標準是聽得非常清楚，延時小，交流順暢；3.5-4.0為“良”，音質稍差，聽得清，延時小，有點雜音；3.0-3.5為“中”，音質較可，能聽清，有一定時延，可以交流；1.5-3.0為“差”，勉強能夠聽清，交流時需要重復多次才能夠表述清楚；0-1.5為“劣”，完全聽不清，延時大，交流不暢 。
2.4 視頻服務質量指標
視頻服務質量的評價標準有幾個，它們也都是通過MOS值打分來判斷質量好壞的，圖中參考是以碼流大小為標準評估指標 。以640*480為例，如果想達到MOS值為4.5的優質效果，可以看到產生的碼流的大小大概在3Mbps左右 。這樣的碼流對于實時傳輸來說太大了，如果是640*480的視頻占用3Mbps的帶寬，那是一件非常奢侈的事兒 。一般情況下，我們會選擇MOS值為3.5（綠色線）的碼流，其碼流范圍在600kbps左右 。
【服務質量差距分析模型 服務質量評價模型】從以上可以看到，在保證傳輸的實時性時，由于帶寬是一定的，可能會犧牲一定的服務質量 。
3 主要矛盾
3.1 實時通信與服務質量的矛盾
通過了解上述三個指標，我們可以得到實時通信與服務質量的主要矛盾 。
第一，碼流與帶寬之間的矛盾 。要想達到好的質量，碼流一般會比較大（當然，不能超過最大碼流)，而帶寬是有限的，于是碼流和帶寬之間就會產生矛盾；第二，實時性和服務質量之間的矛盾 。通常為了保證好的實時性我們會選擇UDP，而UDP不保證網絡傳輸的可靠性，丟包、亂序是經常發生的 。一旦出現丟包、亂序，網絡傳輸質量就無法得到保證，最終會影響到音視頻的質量 。
這里我們就可以總結出實時通信的主要矛盾，即：音視頻的質量與帶寬大小、實時性和網絡質量之間存在矛盾，其它包括3A問題都屬于次要矛盾 。
4 解決矛盾方法
4.1 解決矛盾的方法
下面來看下解決矛盾的方法 。對于WebRTC來說，主要從以下幾個方面解決主要矛盾：如何保障數據傳輸的實時性、如何提高網絡質量、如何更準確的評估帶寬、如何平衡碼流與帶寬 。
5 保障數據的實時性
對于WebRTC來說，為了保障數據的實時性，提供了兩種方法：一種是傳輸路徑的選擇，它首先會選擇最佳的傳輸路徑，使得端到端傳輸時采取最好、最短的傳輸路徑從而保障數據傳輸的實時性；另一種是傳輸協議的選擇，可以選擇TCP或者UDP 。下面咱們先看一下WebRTC是如何選擇最佳傳輸路徑的 。
5.1 選擇一條最好的路徑
圖為WebRTC路徑選擇的架構圖 。圖中包括三個端，A端、B端和C端，其中A和B在同一個局域網內，對于WebRTC來說，如果發現同一局域網內的兩端需要通信時，會選擇局域網內直連，從而保障網絡路徑最短最優；如果是A和C通信，它們不在同一局域網內，那么WebRTC會選擇P2P直連，做NAT穿越，如果穿越成功，便可進行直連，這樣路徑相對服務器中轉來說也比較短 。只有在P2P不成功時，才會選擇服務端中轉 。從圖中可以看到，當一端通過TURN服務器將數據傳輸給另一端時，其傳輸路徑明顯長于P2P直連，所以對于WebRTC來說，它一定會選擇最短、最優的路徑，從而保障端到端的實時傳輸 。
5.2 使用TCP還是UDP？
接下來看一下WebRTC對TCP/UDP協議的選擇 。在網絡比較優質時，TCP/UDP都可以用于實時傳輸，但大多數情況下，我們首選UDP（后面會介紹UDP的優勢）；弱網環境下不能使用TCP；而在進行網絡穿越時，使用TCP又有較大的好處，在企業內可以使用TCP訪問外網的80端口進行穿透 。
5.3 為什么極端網絡環境下不能用TCP？
為什么在弱網環境下不能用TCP？這是由于TCP的機制所造成的 。TCP的機制是發送、確認、丟包、重傳 。正常情況下，數據從一端傳輸到另一端是沒有任何問題的，但當出現丟包時就會有較大的麻煩 。
圖中顯示了多次丟包時的延遲情況：從客戶端向服務端發送數據包，服務端需要返回ACK消息進行確認; 客戶端收到確認消息后, 才能繼續發送后面的數據（有滑窗時也是類似的） 。每次客戶端發完數據后，都會啟動一個定時器，定時器的最短超時時間是200ms 。如果因某種原因，在200毫秒客戶端沒有收到返回的ACK包，客戶端會重發上一個包 。由于TCP有退避機制，以防止頻繁發送丟失包，因此會將重發包的超時時間延長到400ms 。如果重發包依然沒有收到確認消息，則下一次重發的超時時間會延長到800ms 。我們可以看到，連續幾次丟包后，就會產生非常大的延遲，這就是TCP在弱網環境下不能使用的根本原因 。
5.4 選擇UDP帶來的問題
由于TCP的機制問題，因此通常我們會選擇UDP來保障音視頻傳輸的實時性 。UDP在實時性方面有優勢，但缺點同樣明顯 。由于UDP是不可靠傳輸，它只能盡力送達，所以出現丟包、亂序是常見的事兒，但對于網絡質量來說，丟包是非常嚴重的事情，這就需要我們自己處理這個問題 。下面咱們就來看看WebRTC是如何解決這個問題的吧！
6 如何提高網絡質量
6.1 網絡質量包含哪些指標
那么，WebRTC是如何處理UDP的網絡質量的呢？
要想解決網絡質量，首先要知道影響網絡質量的幾個因素：它包括了丟包率、延遲時間、抖動、亂序 。如果網絡丟包率低、延遲時間小、不抖動、不亂序，這就是非常優質的網絡啦 。但如果丟包率很高，那么網絡質量一定會很差 。
6.2 造成丟包的原因
圖中是網絡基本的拓撲，造成丟包的原因有很多，如鏈路質量差，當手機與基站連接時，由于信號不好會造成丟包，這就屬于鏈路差，這種情況在移動端是經常發生的；第二是帶寬滿，比如一臺機子上行發送碼率比較大，而下行接收鏈路比較小，這時在上游的路由器會把數據緩存起來慢慢發送，但緩存是有限制的，一旦緩存被塞滿，后面就會造成大量丟包；第三是主動丟包，比如路由是跨運營商的，在不同運營商之間傳輸數據時，可能由于運營商未知的原因造成丟包；第四是光線被挖斷等偶然原因造成丟包 。
6.3 減少丟包的方法
WebRTC主要通過兩種方式解決丟包：NACK和FEC 。
6.4 NACK
NACK的作用是丟包重傳 。從圖中你可以看到，WebRTC的發送端不停地向接收端發送RTP包，接收端每隔一小段時間，就對這段時間內的丟包情況進行統計 。如果發現丟包，它會給發送端回一個NACK消息，NACK消息中記錄了這一段時間內哪些包丟失了 。發送端收到NACK后，會在之前的發送歷史記錄中找到丟失的包并重新發送 。
6.5 NACK適合使用的場景
當然，通過NACK重傳，會產生一定的延時，該延時包括：等待發送NACK的時間（10或20ms），NACK經過網絡的時延以及RTP的網絡時延和重傳RTP包的網絡時延，即1.5RTT+10或20ms 。通過這個公式我們可以知道，如果RTT時延比較大，比如200ms，那么1.5RTT就是300ms 。通過前面講述的實時傳輸延時指標我們可以知道，端到端實時傳輸的時延需要控制在500ms之內，如果僅數據的網絡傳輸就占了300ms，那數據再經過采集、編碼、解碼、渲染等流程，這些處理時間加在一起很有可能就超過500ms 。
所以可以得出結論，丟包重傳僅適用于網絡傳輸時延比較小的情況，如果RTT比較大時，就不適合使用丟包重傳來保障網絡質量了 。
6.6 FEC
FEC的作用是通過冗余數據解決丟包 。實際上，它就是一個異或操作 。如圖所示，假設傳輸的數據是Data1和Data2，這兩個數據如果在傳輸的過程中沒有FEC進行保護，其中一個數據丟失了，那只能通過NACK重新找回 。那么，能否在傳輸過程中加一些冗余數據，以保證接收時，當某一個數據丟失后，不經過重傳就可以將丟失的包找回來呢？這就是FEC 。
在圖中我們可以看到，Data1和Data2同時發送到對端，在發送時對它們做一下異或操作，即Data1的最后一位0與Data2的最后一位0異或為0，Data1的倒數第二位1與 Data2的倒數第二位1異或為0，依次類推，最后就產生了冗余數據R，同時將三個包從一端傳輸到另一端 。傳輸過程中，如果Data1丟失，通過Data2和冗余包R就可以將Data1找回來 。找回包的算法也是異或操作，即在接收端將Data2的每一位與冗余包中的相同位進行異或操作就算出了Data1 。這就保證了不用重新請求，就將丟失包找回的作用 。
而且異或具有傳遞性，A、B、C三個包可以同時異或得到D，如果其中任意一個包丟失，可以通過D和其它包找回丟失的包 。
6.7 ULPFEC
對于WebRTC來說，它默認使用的是ULPFEC 。其原理是，將要傳輸的數據包先進行分組，如將三個包分為一組，然后為這一組包產生一個冗余包，如果這一組中某個包丟失了，就可以通過冗余包和其它包的異或操作將其找回 。從圖中第一行可以看到1和2到了，3丟了，通過R1可以找回3，第三行同樣可以找回9 。其缺點是，如果連續的兩個包都丟失了，這種算法就失效了，比如第二行4和5丟失后，通過6和R2無法找回它們 。
6.8 FlexFEC
于是就有了改進的FlexFEC，它做了雙向冗余處理，不僅橫向做了冗余，而且縱向也做了冗余 。
此時，當4和5同時丟失時，通過1、7和C1可以找到4，2、8和C2可以找到5，這樣就可以找回連續的兩個丟包 。當然它也有弊端，其弊端是無法處理批量的連續丟包，例如連續丟失了10個包，FlexFEC對這種情況也無能為力 。
以上就是WebRTC對于丟包的解決方法，通過“NACK+FEC”防止丟包 。
6.9 如何解決抖動和亂序
下面來說說抖動和亂序 。抖動的意思是，一會兒來了很多包，一會兒又一個沒有，包是一波一波的來，包到達的時間很不平均；而亂序指的是先發的包后到了，后發的包先到了 。
WebRTC處理抖動和亂序使用的是JitterBuffer和NetEQ 。JitterBuffer用于處理視頻包，NetEQ用于處理音頻包 。它們的原理大致相同（NetEQ更為復雜一些），都是通過一個隊列（緩存區）對接收到的數據做下緩沖，然后再從隊列的另一端將數據包一個個均勻的取出， 這樣取出的數據就是平滑的了 。
對于亂序的處理也比較好解決，如圖中所示，每個RTP包進來的時候有一個序號（Sequence Number），在數據進入隊列時，它會根據序號插到對應的位置上，比如圖中104、107包已經到達，并且在對應的位置上，而103、105和106沒來，位置就空著，等它們來了再插入對應的位置，這樣就可以防止亂序，所以通過JitterBuffer和NetEQ就可以同時解決亂序和抖動了 。
總結一下，NACK和FEC解決丟包問題，NACK會增加時延，FEC會占用帶寬 。JitterBuffer解決視頻的亂序與抖動，NetEQ解決音頻的亂序與抖動 。
6.10 網絡延時產生的原因
說到延時，實際上就與帶寬評估有密切的關系了 。延時的產生有兩個原因：第一是鏈路問題，正常的網絡上，數據包的傳輸都是時快時慢的；第二是發生了網絡擁塞，當發生擁塞后，數據包會進行緩沖，就會造成延時，而當緩沖溢出時，就出現了丟包 。
所以對于延時來說，我們需要解決的是因擁塞而造成的延時，鏈路問題無法解決 。下面咱們就來看看WebRTC是如何防止擁塞的 。
7 準確的帶寬評估方法
7.1 如何解決抖動和亂序
WebRTC防止擁塞的根基是有準確的帶寬評估方法 。它提供了兩種帶寬評估方法，一種是基于丟包的帶寬評估，另一種是基于延時的帶寬評估 。而基于延時的評估方法又分為接收端（Goog-REMB）和發送端（Goog-TCC）的帶寬評估方法，目前默認采用的是Goog-TCC方法，因為其相對來說更為精準 。
7.2 基于丟包的帶寬評估
基于丟包的帶寬評估方法比較簡單，根據丟包率進行計算 。實際上，正常帶寬也有一定的丟包，如果丟包率<2%，屬于網絡質量不錯的正常丟包，說明帶寬還沒有達到上限，應該增加評估的帶寬值 。舉個例子，比如你家里的帶寬是8M，WebRTC最開始是不知道你家里的真實帶寬的，它必須一點點測量，所以一開始它先給你的帶寬設置一個假設值，即500K，當發現丟包率很低時，它再增加帶寬的評估值，如從500K升到1兆，如果丟包率還是很低，就會加到1.5兆、2兆……，帶寬評估值增加的速度是每次增加8%；如果丟包率>10%，說明發生擁塞了，此時應該立即降低帶寬，公式如圖（loss>0.1時）所示 。如果丟包率<10%，說明現在的帶寬評估的比較準確，此時應該保持這個帶寬，不增加也不減少；
7.3 基于延時的帶寬評估
基于延時的帶寬評估方法比基于丟包的評估更好一些，因為它可以提前預估是否發生了擁塞 ?；趤G包的評估丟包率一旦超過10%就說明可能已經發生擁塞了，而網絡一旦擁塞，再想恢復回原來的狀態，需要花費一段時間，而這段時間就會影響音視頻的服務質量 。
而基于延時的帶寬評估就不會產生這種情況 。它的基本原理是，如果接收到的數據包的網絡傳輸時延在持續增長，就說明網絡變差了，當達到一定程度時，就要將評估的帶寬值降下來，以防止發生網絡擁塞 。它的計算公式是根據狀態機來的（狀態機比較復雜，我這里就不講了），當狀態非常好時，需要增加帶寬，同丟包增加帶寬一樣，每次增加8%；如果延時一直累加，則需要降低帶寬，帶寬降為原來85%，其它情況就保持當前帶寬，無增無減 。
8 媒體數據與帶寬的平衡
8.1 媒體數據與帶寬的平衡
當帶寬評估準確之后再進行控制就非常容易了 。接下來，我們看一下WebRTC如何平衡媒體數據與帶寬 。
帶寬評估方法和網絡質量的提升在前面我已經介紹了 。在有限的帶寬下，如何才能提供更好的音視頻服務質量，是人們一直孜孜不倦追求的目標 。因此在同等條件下，可以將數據壓縮的更小，一直是解決服務質量的一種關鍵方法 。目前最常用的視頻編碼器還是H.264，不過新的編碼器已經有了很大突破VP9/H265、AV1/H266提供了更高的壓縮率，這使得我們在網絡條件有限的情況下，可以傳輸更多的數據從而保障更好的服務質量 。
另一方面，在帶寬相同且碼流無法壓縮的情況下，還可以采用動態碼率 。通常，在使用動態碼率時，我們可以直接從產品上看出來，你會發現視頻一會兒清晰，一會兒模糊 。即在帶寬小時，編碼器壓縮碼流，此時視頻變得模糊；帶寬大時，編碼器放大了碼流，所以視頻變得清晰 。以上就是通過減少數據量的方法來保障實時通信質量的 。
8.2 Simulcast與SVC
除此之外，還可以通過Simulcast或SVC解決質量問題 。Simulcast和SVC解決問題的思路是類似的，它們會在發送端增大碼流的發送，將數據先傳給服務端，然后由服務端根據接收端帶寬的不同，選擇合適的碼流下發 。對于網絡較差的用戶，傳輸清晰度低的碼流，對于網絡較好的用戶，傳輸高清晰度的碼流 。所以這兩種技術對于發送方的帶寬和質量有非常高的要求 。
SVC與Simulcast最大的區別：SVC上傳的是一路碼流，但這一路碼流是由多層構成的 。服務端會按照不同接收端的帶寬大小，選擇傳輸不同的層 。如上圖所示，手機端帶寬小，就傳輸小的一層數據，PC端帶寬大，就將所有層全部傳輸過去；而Simulcast上傳的是多路流，一般分為小、中、大三路 。對手機端傳輸小的一路，對PC端傳輸最大的一路 。Simulcast的好處在于，每一路流都是獨立的，所以可以對每一路流使用硬件編解碼器，而 SVC的分層方式目前沒有硬件支持，所以無法通過硬件加速 。
8.3 流控
當帶寬評估準確后，如果發送的的碼流還是大于帶寬大小，此時就需要通過流控來進行控制了 。流控的作用是當輸出碼流大于帶寬時，降低發送碼率，以防止發生擁塞 。當然它會導致時延的增加 。實際上，對于流控來說，它需要控制兩個點：第一個點是Pacer，降低發送碼率 。當然僅降低發送碼率還不夠，因為如果編碼器仍然輸出大量碼流給Pacer，那么Pacer 的緩沖區遲早會被撐爆 。所以在控制Pacer讓它減少發送碼率的同時，一定要降低音視頻的編碼器的輸出碼率，從而保持平衡，進而使數據平緩下行 。
正如我前面所說的，流控雖然防止了網絡擁塞的發生，但會增加一些延時，增加的延時最終會反應到實時通信的總指標里，總的延時必須控制在500ms以內 。比如以前端到端時延是200ms，由于帶寬不足，時延增加到300ms、400ms都是可以的，但一定不要超過500ms 。
此外，對于編碼器的輸出碼流來說，如果流控通過直接降低碼流仍然不能與帶寬適配時，還可以通過降低分辨率的方式來降低碼流 。總之，在帶寬不足時，要想盡辦法減少數據量 。實在不行，也可以關掉視頻只保留音頻來保障網絡的暢通 。
9 總結
總結一下，對于服務質量保障，首先提高網絡質量，NACK和FEC解決丟包問題，JitterBuffer解決視頻的亂序與抖動，NetEQ解決音頻的亂序與抖動；帶寬評估通過Goog-REMB和Goog-TCC，還有丟包的帶寬評估；為了保障實時性，需要選擇更優質的線路，比如客戶端與服務端通信的時候選擇更好的路線節點，保證云端網絡帶寬等等；從業務上，減少數據量可以用AV1、SVC、Simulcast、動態碼率，減少業務；在防擁塞上，通過Pacer進行流控，只要能控制在500ms之內，適當增加時延也是可以接收的 。
以上就是本次分享的全部內容，謝謝！
Q&A (部分)
1. 路徑的選擇是WebRTC內部自動選擇的嗎？
是自動選擇的 。WebRTC會自動判斷通信的雙方是否在同一個局域網內，如果是就直接在局域網內建立連接；如果不是，會通過STUN協議獲取各自的外網地址，然后進行NAT穿越；如果還不成功的話，才會選擇TURN服務進行數據中轉 。
2. WebRTC網絡傳輸質量衡量指標有什么？
衡量任何一個實時傳輸系統時，首要看它的時延是否達到500ms以內 。其實500ms對于實時通信而言，也是比較苛刻的標準了，因為網絡的變化是非常大的， 所以要實現這個指標其實難度也是蠻大的 。其次是丟包率，這是非常關鍵的指標，剛才說到2%的丟包率代表網絡比較好；小于10%，對于WebRTC來說，代表目前的帶寬是準確的；超過10%則代表發生了擁塞 。有些廠商說它的產品可以抗xx%的丟包，這樣的前提是不認為丟包是一個指標，但在真網絡中，當路由的緩沖被撐爆后，必然會出現大量丟包，如果不把丟包當作指標的話，就缺少了一種判斷網絡擁塞發生的條件，這顯然是不合理的 。
3. 視頻JitterBuffer怎么具體控制平滑的？
其實JitterBuffer平滑處理的難度并不像我們想像的那樣復雜，之所以大家認為它復雜，可能是因為一些額外的因素，如還要處理音視頻同步等問題 。對于平滑處理，我們完全可以自己通過一個Buffer來實現 。Buffer可以是動態大小或固定大小 。為了簡化，我們假設它是固定大小，比如定義一個可以存放 100 個元素的數組，在數組的一頭每隔 10 毫秒取一個包，這就是一個最簡單的平滑處理 。當然更好的方式是可以根據網絡的變化讓這個平滑數組的大小也動態變化，這樣就更高級一些 。當然，如果Buffer是動態變化的，那在計算平滑數組的動態大小時，會稍難一些 。
4. WebRTC要和SIP客戶端通訊有什么好的方案？
一般與SIP通信最好借助流媒體服務器比如Janus，它既支持SIP協議也能支持WebRTC客戶端 。這樣SIP終端就可以將數據傳輸流媒體服務器，然后再轉發給WebRTC終端了，同理WebRTC終端也可以通過流媒體服務器與SIP終端通信了 。
5. FEC和NACK默認是不是都要開啟？
是的 。對于WebRTC來說，FEC和NACK都是開啟的，也可以控制它們的開關 。
6. 能說下為什么TCC比REMB準確嗎？
TCC和REMB主要有兩個區別 。第一是計算的端不同，REMB是在接收端計算的，接收端計算后再將結果返回給發送端進行控制，而在回傳結果時，可能網絡又發生了新的變化，這就造成了REMB的及時性不夠；TCC是將所有數據都交給發送端做計算和控制，因此及時性和準確度會更高 。第二是濾波器不同，REMB是卡爾曼濾波器（Kalman），TCC是最小二乘法濾波器（Trend line） 。最小二乘法濾波器在網絡延時評估這方面比卡爾曼濾波器效果更好一些 。
7. 在內網環境下p2p想讓延時盡可能小，可以做哪些工作？實驗室環境最小延時可以達到100ms以下嗎？
如果在同一個局域網內，實際只有幾十毫秒的延遲 。有同學可能會疑惑，有的產品在同一局域網內延遲非常小，為什么用WebRTC反而延遲增大了？這就是因為WebRTC為保障網絡質量，在內部通過多種機制，各種緩沖，來做到的 。所以它必然會產生一定的延遲，也就是拿延遲換質量 。而在局域網內，網絡基本沒有延時，不丟包、不抖動、不亂序 。這時什么策略都不采用，網絡的傳輸才是最快的，因此在內網通信時，WebRTC的實時性一定不如什么策略都不加的產品好 。
8. ULPFEC和FLEXFEC區別是？
ULPFEC只能進行單向冗余處理，而FLEXFEC可以進行雙向冗余處理，即可以橫向分組還可以縱向分組做冗余，所以它的抗丟包性要比ULPFEC好，同時占的帶寬也比ULPFEC多 。
9. 可靠性這塊，UDP上的WebRTC做ack是自己封裝了seq嗎？然后，一樣需要ack重傳的話，跟TCP SACK有什么區別呢？
WebRTC使用的是RTP協議傳輸數據 。RTP協議中有seq字段 。此外，WebRTC用的NACK與TCP的ACK機制不同 。TCP每一塊數據都需要通過ACK進行確認，如果沒收到ACK就重發，直到成功收到ACK或斷連；而NACK允許丟包，當重傳多次不行時，就不傳了 。且而即使重傳了數據包，在接收端發現它已經過期時，也會將其丟掉 。
10. WebRTC后面會用QUIC協議嗎？
這個問題爭論較大 。WebRTC也在一直在嘗試使用QUIC協議，從我的角度來看，QUIC協議最主要的是解決Http3，Http3解決的是TCP的問題，就要保證數據的可靠性，那么實時性就會受到影響，什么時候QUIC如果可以解決好實時性問題就可以用，反之則不能 。
從我的角度看，一種協議最好只解決一件事兒，很難通過一套協議解決所有問題 。