本文首發在雲+社區，未經許可，不得轉載。算法
雲+導語：4月21日，騰訊雲+社區在京舉辦「‘音’你而來，‘視’而可見——音視頻技術開發實戰沙龍」，騰訊音視頻實驗室高級工程師張軻圍繞網絡傳輸方面講解了《騰訊雲H5語音通訊QoE優化》，包含騰訊雲H5解決方案，音頻QOS優化總體框架及優化技術，和運營方法幾個方面。QOS優化包含帶寬估計擁塞控制、抗丟包技術、延時、抗抖動技術四個領域。張珂重點分享了WebRTC與WebRTC之間，tbs與WebRTC之間，tbs與natvie之間互通所涉及的QoS相關的技術問題，回溯分析工具可以提升工做效率，能夠快速發現潛在技術改進點，加快技術迭代速度。編程
騰訊音視頻實驗室高級工程師張軻
11月份，W3C發佈了WebRTC的標準。另一個專一於WebRTC的國際組織RETF在12月份也發佈了第一個RFC8298，目前尚未成爲真正的標準。我今天講的重點，是圍繞網絡傳輸的一些心得。瀏覽器
2017年3月份CallStatus.io WebRTC發佈的全球質量報告中，第一個有10%的通話會由於各類帶寬、丟包、流失緣由，形成中途中斷。第二個是有10%到15%的用戶，對音視頻通話的質量不滿意。第三個是有7%左右的大丟包，有95%左右的用戶已經流失在240毫秒如下。安全
正是由於如今的WebRTC方案有不少問題，咱們簡單分析一下剛纔的一些質量不佳的緣由，有大概三個緣由：微信
第一個，自己WebRTC涉及的是P2P的網絡鏈接，中間可能沒有大量的中轉系統，在遇到跨運營商，甚至小運營商的時候，它的網絡鏈路是沒有質量保證的。網絡
第二個，各個瀏覽器互操做性、兼容性不好。這些問題恰好都是咱們的專長。咱們基於此開發了一套解決方案。併發
兩個核心的技術優點
第一個是咱們的實時音視頻；第二個是基於QQ瀏覽器的TBS內核的瀏覽器上面支持了WebRTC的能力。咱們能夠針對WebRTC代碼作不少修改，甚至優化。框架
咱們用戶端能夠在微信、QQ瀏覽器上面，對WebRTC進行編程。咱們還有一些推流、錄製、點播等等的能力。dom
三種差別化的服務質量
實現一套基本的WebRTC，工做量是後臺的搭建，接入部署，包括在後臺實現傳輸控制、媒體加密，增長運營能力。QQ的東西是十多年海量用戶的經驗，咱們如今天天QQ的通話時長大概在10到20億分鐘左右。擴展的WebRTC，是至關於在QQ瀏覽器內核裏面，集成了WebRTC的內核，同時對它作了一個擴展，解決了如今WebRTC的一些問題。咱們對QOS也作了一些簡單的擴展。咱們會根據後面用戶量的一些使用狀況來決策，看這三個怎麼更好地協調，或者說優點互補。工具
接口機的分配及接入的情況
咱們創建了一套機房節點全球鏈路質量監控系統，在WebRTC項目裏面，大概部署了60多個節點，覆蓋了30多個國家。國內98%的節點之間鏈路延時小於36ms。有90%全球的網絡節點之間，大概鏈路節點小於100毫秒。鏈路優化是持續的過程，包括節點的部署，也會根據用戶量的使用狀況來決策，在哪些地域或者是地區投放咱們的節點部署。
QOS優化——擁塞避免算法和抗丟包技術
後臺質量控制示意圖中能看到咱們實現了SFU和MCU。質量控制，就是三級策略，接口級這個地方，先估計終端上行網絡的質量，包括作帶寬估計，包括抗丟包機制的對接。下行的帶寬估計，抗丟包的一些機制對接。最核心的地方，控制策略是根據上下行的一些質量信息，來決策咱們的流量控制到底應該怎麼作，這裏面有一個核心決策體系，這個東西也是咱們整個實時數據裏面一個很是核心、很是有競爭力的技術。
QOS優化到底有哪些技術？
分帶寬、丟包和延時、抗抖四個領域。想作好QOS，環節特別多，從編解器、鏈路、傳輸、處理、設備等衆多環節，處理好技術的協做關係，各類算法的調度、管理、配合是核心難點。
帶寬工具，包括網絡擁塞，有GCC、NANA、SCReam、FRACTal。抗丟包技術裏面有ARQ、FEC、PLC延時構成，包括咱們的核心在作採集播放的時候，咱們會控制不少領域的東西。不一樣的問題牽扯到不一樣的技術，各類基礎技術的理解深度和廣度以及應用策略，這是第一個層面的東西。
第二個層面，各類技術、各類因素，它的配合影響，包括反饋以及聯動策略，相對來講比較綜合的第二個層面的東西。
第三個層面，不少業務特性決定了基於場景的差別化的策略，也會致使要採用的策略不同。
想作好QOS，必需要把這三個層面的東西解決好，否則QOS是作很差的。
什麼樣的算法纔是比較好的擁塞控制算法？
實時媒體擁塞避免控制方案，一直是IETF RMCAT的熱點研究課題。傳輸延時要小於100毫秒。數據流之間不能相互干擾，不能由於自發引發不恰當的使用帶寬。丟包是越小越好，帶寬應用率要高，儘量使用帶寬。在帶寬有限的狀況下，傳輸通道不能餓死。出於安全的考慮，要對可能的一些擁塞控制領域的反饋攻擊作一些處理。安全性方面，媒體數據的發送必定要是平滑的。公平性方面，不要餓死，也不能搶更多的帶寬，要共享帶寬。
適應性有不少方面，第一適應實際帶寬的波動。好比說在音頻裏面會啓動不連續傳輸，可能致使帶寬愈來愈弱，這時候怎麼處理？最後一個就是反饋，反饋通道很差了怎麼辦？反饋包丟失了怎麼辦？怎麼去控制好？能把這10個方面作好，就提供了比較好的工具。
TFRC是大概十年前用的技術，最大的問題是延時不可控，視頻幀大小常常發生變化。有速率振盪行爲。高丟包下的準確度有問題。
LEBDBT，好處是延時相對來講絕對可控。它的缺點是太靈敏了，有網絡波動或者是在帶寬上有一些突發流量，都會致使它迅速崩潰，致使帶寬飢渴。還有一個是後來者效應。它會把第一路的帶寬給搶佔了。
GCC，它是有兩部分，第一部分是收端是基於延時的控制算法，發端是基於丟包的。它主要有幾個問題：它在移動網絡環境多流共存狀況下，表現不好。
在有TCP流並存的狀況下會過分退讓從而致使WebRTC流飢餓在多WebRTC流併發的狀況下，新加入的WebRTC流會損害已有流的通訊質量。 SCReam是基於窗口和麪向字節。缺點是見SCREAM-CPP-implementaion，有線網絡不如GCC。NADA是基於延遲和損失，目前還是實驗代碼。FRACTal是FEC探測帶寬，缺點是魯棒性仍須要提升，移動和無線網絡待驗證。QUIC是Quick UDP，默認擁塞控制算法沒法保證低延時，可提供私有擁塞算法。
兩套實現方案：現有WebRTC已切換到綠色部分基於延時的發端擁塞方案，上下兩套算法經過SDP參數控制。
這是幾個主流的瀏覽器的實踐情況。Edge仍是老的算法。OpenWebRTC主要推薦的是SCReam算法。
咱們的應用策略對於不一樣的瀏覽器、不一樣的版本能力是不同的，提供WebRTC解決方案，必需要清楚。咱們在基本的WebRTC通話場景，經過SDK參數交換使用的擁塞控制方案。不一樣瀏覽器裏面，必需要管理好這些擁塞控制算法。咱們提供私有的擁塞控制算法，主要是基於咱們已有的經驗積累，包括剛纔我對各類算法的解讀，包括優缺點的優化方法，同時咱們也會在運營層面上對比不一樣的算法。
FEC算法有不少種，第一個是Inband FEC，在語音的編碼器裏面，生成一部分冗餘信息。它的缺點是以犧牲語音質量爲前提的，雖然能夠保證流量是穩定的，可是它的質量是很差的。
異或，這個是WebRTC裏面一個主要的實現方法。
Reed-Solomon的糾錯率比較高一點。交織編碼，在WebRTC裏面也有使用。它的目的不是糾錯，而是把丟包給散化。還有一個Fountain，這個技術也很是老了，近兩年在實施領域，可能在廣播裏面應用比較多。它是無碼率的註冊編碼，特別適合多場景使用。它增長了流量和延時，可是相對來講FEC機制增長的延時量是比較穩定的，適合信道特徵穩定的場景。
WebRTC提供了異或和交織編碼這兩種。 WebRTC中使用的XOR FEC，異或是經過分組的原碼實現的。我提了4個數據包生成三個冗餘包。若是收到數據包123，數據包123丟失了，收到4567。123是數據包，4也是數據包，冗餘包是567，經過47，把數據包給否了。
須要損失程度和亂序相關的反饋，才能正確選擇KFecMaskRandom仍是KFecMaskBursty。
這個是WebRTC中FLEXFEC，仍是剛纔的異或關係。一種是非交織，一種是交織的。非交織的好比說1234進行異或生產一個數據包。5678生成一個數據包。
對於交織的狀況，可能就是159，而後生成一個縱向的冗餘包。如今還有二維的，橫向的也生一個冗餘包，縱向也生成一個冗餘包，它的糾錯能力不是那麼強，這是WebRTC裏面的事情。
還有一種是FEC和交織搭配的使用。數據包123四、1234，寫入一個矩陣，而後讀的時候是按列取的，這樣就實現了交織。
交織目標是爲了把差錯離散化，再用FEC技術恢復。交織深度M越大，離散度越大，抗突發丟包能力越強，延時越大。
怎麼設計一套好的FEC算法？
一、抗丟包算法要歸入擁塞控制算法，必須是網絡自適應的，很是重要，是前提。
二、保證抗丟包能力的前提下如何減小冗餘流量。
三、如何最大化發揮各類FEC機制的優勢，場景反饋（連續丟包次數，丟包特性）。
四、FEC算法，分組大小的選擇，對流量、延時，抗丟包性能的影響均要考慮到。
五、動態冗餘率機制，收斂速度。
六、FEC效果評價。
七、一對多場景，須要對每路接收定製化FEC保護方案。
收端要作好各類反饋，收端收到數據包的時候，要作一些成功率的計算，都反饋到策略中心，來作相應的統計、控制。
NACK算法關鍵點：
一、結合音頻/視頻的Jitter buffer狀態決策請求。
二、發端/收端延時控制。
三、其它不少精細化控制細節。
四、重傳效果的評估。
五、運營、數據監控。
結合糾錯和同傳的機制。上面對比了一下ARQ和FEC的能力。ARQ引入了突發抖動，較難處理。突發丟包處理能力好，流量效率高。引入延時不固定，但能夠設置限制。
FEC抖動變化小，大小丟包均能處理好，但要犧牲帶寬突發丟包處理很差。引入延時相對固定。
WebRTC RetEQ算法裏面的關鍵點：
一、延時估計算法。
二、播放延時估計算法。
三、自適應決策邏輯。
四、語音變速算法。
五、VAD、CNG數據算法。
關於流量。
一、下降傳輸包頭：傳輸層包頭。
二、增長組包時長，20毫秒調整到60或者80毫秒，減小包頭負載。
三、下降內核碼率。1：VAD、DTX2codec層面優化碼率。
四、下降冗餘。
關於延遲
網絡延時：處理延時，排隊延時，傳輸延時和傳播延時。
設備延時：採集、播放設備。
播放延時，是數據包到達時和播放時間之間的延時，抗抖延時。
編解碼和處理延時：編解碼和各類先後處理算法延時。
運營方法
第一部分是專業的實驗室，保證了咱們測試數據的準確性和可靠性，以及可追訴性，爲系統正式上線運營提供了保障。
QOE的影響因素是很是複雜的，目前咱們僅關注客觀質量，設計了一套評估體系。咱們在線上系統運營的時候，能夠提供一個簡單的指標，衡量咱們的算法究竟是好仍是壞，直到後續的優化方向，作一些板塊監控。甚至具體到算法調優層面，能夠作一些聚類，劃定一些分析樣本，作進一步的有針對性的優化。
問題分析工具：還原通話過程技術參數，快速問題還原，分析、診斷，也爲進一步優化提供豐富案例。
咱們經過ABTest運營進行工做方法效果驗證。安卓平臺FEC優化版本新策略（奇數房間）質量明顯優於老策略（偶數房間）。好的系統和算法是要經過運營數據來驗證和不斷迭代的。
咱們雲語音質量的數據到底怎麼樣？2分如下佔比小於3%。10%的通話中斷了，10%到15%的用戶對質量不滿意，這個數據能夠作一下對比。
咱們的優化是永無止境的課題。WebRTC從M56到前兩天發佈的M66版本，WebRTC解決了1000多個Bug。
Q/A
Q：我想問一下，好比說在接入請求的時候，可能會有一些效率，你的軟件、你的網絡，還有一些其餘硬件的緣由。我想了解一下，您這個優化的時候，都是會遇到什麼樣的問題點？怎麼避免這些問題？問一下，好比說你硬件會有一些傳輸的效率，還有你的軟件，或者各個系統之間的一個集成交互的時候，這些憂患點能不能分享一下？
A：我剛纔講到的，系統集成層面上，若是僅僅用瀏覽器，除了在後臺作優化以外，沒有太多的優化方法。可能更多的是優化你的流程層面的。若是你有從WebRTC內部層面作優化，那就太多了。音視頻全部的領域均可以作，這個範圍太大了。我講的僅僅是網絡傳輸這一個層面，有回升、有效率等等，太多方面了。