WebRTC 架構優化及實踐

內容來源：2018 年 1 月 13 日，聲網Agora.io音樂工匠高澤華在「架構師修煉之道——極光開發者沙龍JIGUANG MEETUP」中，進行的《WebRTC架構優化及實踐》演講分享。IT 大咖說（微信id：itdakashuo）做爲獨家視頻合做方，經主辦方和講者審閱受權發佈。

閱讀字數：2500 | 5分鐘閱讀

獲取嘉賓演講視頻及PPT： suo.im/597g90

摘要

目前幾乎全部主流瀏覽器都支持了 WebRTC，包括 Firefox、Chrome、Opera、Edge。WebRTC 1.0 的標準化進程也處於很是高級的階段。愈來愈多的公司正在使用 WebRTC 而且將其加到本身的應用程序中。那麼，企業在構建 WebRTC 應用時，應當注意什麼？本次演講將爲你解讀：標準的 WebRTC 系統的典型架構是怎樣的， WebRTC 的坑與優化實踐、瀏覽器適配及平臺兼容性實戰等。

WebRTC是什麼？

WebRTC首先是一種標準，目前WebRTC 1.0的w3c標準現已推出，2.0版本也在推動過程當中（演講時間爲止）。其次是一種協議，開發者能夠經過follow這個協議來實現和WebRTC的互通。另外它仍是一款引擎，由於它前身就是處理音視頻的GIPS引擎。另外在這套引擎下還有大量的音視頻算法，因此WebRTC也能夠說是算法。

WebRTC的前世此生

上文提到WebRTC的前身是GIPS，而GIPS的發展其實分爲兩個階段，第一階段爲Global IP Sound，第二個階段爲Global IP Solution。它在Global IP Sound 階段是做爲音頻通訊引擎用於各類嵌入式系統設備中，主要負責回聲消除、降噪、編解碼等基礎功能。

以後繼音頻服務又加入了video服務，也就是Global IP Solution階段，後來在和客戶的溝通中他們不斷的加入IP通訊的協議、RTP協議等，以實現和網絡鏈接的能力。可是因爲商業上的不合理和銷售策略的失敗，最終仍是被google以6千多萬美圓的價格給收購。

而從技術的演進來說，GIPS到WebRTC，實際上是對Engine層作了封裝，順便還添加了原先GIPS缺失的網絡模塊。通常要提供音視頻服務必需要有服務器，爲了不這種模式，WebRTC採用了P2P的通訊模式。

如何使用WebRTC

我的以爲如今99%以上和實時通訊相關的app愈來愈離不開WebRTC，即便應用的代碼框架不相同，但WebRTC仍是有不少經典算法值得借鑑。

一般咱們能夠將WebRTC做爲學習和移植算法的入門代碼，或者抽象出它的音視頻引擎，還能夠用做PaaS或者SaaS服務。

雖然WebRTC有各類不一樣應用，可是因爲目標不一樣，因此在結合WebRTC自己能力上會有不一樣的側重點，須要針對性的查看相應的代碼，找出其中有缺陷的部分並作出突破。好比要作SaaS和PaaS服務就要準備服務器相關的工做。

使用WebRTC 提供SaaS

WebRTC確實能夠用來作SaaS服務，可是須要先考慮要作的是什麼類型的SaaS服務。好比對於不是基於Web的音視頻通訊服務，就還要考慮額客戶端進行互通。

而不一樣的行業對此的要求也不同，像呼叫中心和教育類的一般會直接使用web進行服務。不過WebRTC在多瀏覽器上的兼容性並很差，視頻編解碼的支持也有所不一樣。

使用的時候咱們要根據服務質量要求和用戶特色靈活使用p2p，好比在大部分用戶都處於WiFi環境的狀況下p2p多是更好的選擇，而對於4g網絡p2p效果會差一些。

若用戶對服務質量要求比較高，我的建議應先着手創建服務器，並部署運維監控負載均衡等能力，讓後端服務器出現的問題對用戶無感知。

應用這些措施應對純web端的SaaS服務其實還有所不足，有不少細節問題仍需處理。好比用戶外接了音頻設備，或者某款瀏覽器的音頻通訊產品在本機上沒有適配好，從而產生回聲等各類問題。

又由於底層不是本身作的，所以只能提醒用戶在使用服務的時候先測試一遍，或者給出一些其餘建議。

使用WebRTC提供PaaS

所謂PaaS就是提供一個平臺給廠商使用，不一樣於SaaS它在上層應用上並無作的過於精細，其主要目標仍是爲了提供更穩定更高效的通訊服務。

在SaaS服務中，咱們能夠分析用戶行爲，針對用戶的使用場景進行優化。可是Paas服務中，用戶千差萬別，可能會涉及IoT、教育、遊戲等個各類不一樣領域，原有的WebRTC引擎確定不夠用。

所以在包含SaaS的各類基礎服務以外，還須要抽象出一套API，而後再針對各個移動設備作適配，還要根據應用場景提供多種增值功能，提供針對場景的特殊優化和包裁剪等。

如何借鑑WebRTC開發AV engine

因爲WebRTC本質上更接近於音視頻引擎，因此若是當AV SDK用，會更便捷。

固然前提是使用者有至關的經驗，可以根據具體的場景定製化參數。

音頻部分在WebRTC中一共封裝了4個模塊，ANM（網絡模塊）、APM、ACM（編解碼模塊）、ADM，對應的video也有一樣的4個模塊，因此總共是8個模塊。我的認爲WebRTC的重點就在於這8個模塊自己和它們之間的參數配置。

可是這也帶來了相應的缺點，咱們要作面向移動端的功能實例優化、性能實例優化以及一些特殊優化，這也使得調試的次數愈來愈多。

如何學習WebRTC算法

只有在學習了WebRTC的算法以後，才能從不一樣的層面給客戶解釋清楚爲何要採用當前方案以及爲何不用其餘方案。WebRTC的精髓在於底層的引擎部分，不過要想對這部分有深刻的理解，首先就要對其中的算法有必定的研究。

前面提到過WebRTC中有8個模塊和2大引擎，其中音頻模塊包括APM、ACM和ADM，視頻模塊包括VNM、VPM、VCM。

APM

APM中涵蓋AGC、ANS、DE和回聲消除的算法NLP。接下咱們逐步看下這裏面到底都是些什麼。

一般的回聲消除有兩種算法，一種是自適應濾波，一種是NLP。在WebRTC以前其實自適應濾波已經作的足夠好了，目前這方面的研究基本上已經停滯，可能在多通道和立體聲的回聲消除上還有必定的研究價值。NLP則不同，它還有不少細節值得探討，這是由於每一個聲腔的聲音設計不一樣，形成了非線性部分的差別。

WebRTC中有兩個回聲消除模塊分別是AEC和ANS，AEC的NLP算法考慮到了很是多的細節，若是想要研究它的算法，能夠好好的看下它的專利說明。

DE是延時估計模塊，如今幾乎全部的延時估計模塊的都用的這一套算法。AGC主要任務是將非噪聲部分調高，噪聲部分調低，這裏的重點就在於如何區分噪聲，等於一個降噪的問題。

WebRTC中的AGC是和VAD放在一塊兒的，VAD採用的是GMM模型，經過統計學的方式來判斷當前是不是Voice，而後在結合到AGC上，全部雖然AGC中的參數仍然要調整，可是算法仍是不錯的，能夠直接拿來用。

ACM

WebRTC的編解碼器有ILBC、ISAC 、Opus，ILBC是窄帶編碼器、ISAC是寬帶編碼器、Opus是全帶的音頻和語音統一的編碼器。在CPU性能較強且可以接受高帶寬的狀況下Opus能夠作的很是好。

ANM

ANM作的是帶寬估計和擁塞控制，因爲如今帶寬較大，因此音頻方面的帶寬估計已經不多有人在作了，視頻方面仍是比較常見。比較有意思的是音頻的帶寬估計被寫入到了ISAC的代碼中。

咱們知道丟包通常分爲兩種，隨機丟包和bond丟包，擁塞就屬於bond丟包的範疇，好比連續丟失多個包或沒法發包都算做擁塞。

ANM中的PLC是一種拉伸快進和慢放的算法，好比要在100毫秒的包中存放200毫秒的數據的時候，PLC就會將包給慢放以實現200毫秒的效果，經過這種方式來應對網絡丟包。PLC的優點在於變速不變調。

視頻

相對音頻模塊，視頻部分能夠挖掘的空間還不少，容易作出差別化。

視頻對網絡的要求會更高，直播和通訊是常見的場景。直播的時候關注的是清晰度，而通訊方面更注重流暢度。側重點的不一樣，帶來了更多的參數調整。好比結合編解碼器考慮抗丟包、結合降噪考慮編解碼等，以及硬件的適配。