了不起的WebRTC：生態日趨完善，或將實時音視頻技術白菜化

08-10

來自專欄即時通訊技術分享17 人贊了文章

本文原文由聲網WebRTC技術專家毛玉傑分享。

1、前言

有人說 2017 年是 WebRTC 的轉折之年，2018 年將是 WebRTC 的爆發之年，這並非沒有根據。就在去年（2017年），WebRTC 1.0 標準草案出爐（實際上WebRTC標準草案的早期版本早在2011年就已經發布，WebRTC並非一夜之間就出現的技術），並將於今年正式發布。與此同時，越來越多的瀏覽器和廠商都開始對它進行廣泛的支持，WebRTC 即將成為互聯網的基礎設施了，或許門檻如此之高的實時音視頻技術終有白菜化的那一天。

補充：WebRTC標準草案的版本演進歷史，請點擊進入。

學習交流：

- 即時通訊開發交流3群：185926912[推薦]

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》

（本文同步發佈於：http://www.52im.net/thread-1631-1-1.html）

2、相關文章

《開源實時音視頻技術WebRTC的現狀》
《簡述開源實時音視頻技術WebRTC的優缺點》
《訪談WebRTC標準之父：WebRTC的過去、現在和未來》
《良心分享：WebRTC 零基礎開發者教程（中文）[附件下載]》
《WebRTC實時音視頻技術的整體架構介紹》
《新手入門：到底什麼是WebRTC伺服器，以及它是如何聯接通話的？》
《WebRTC實時音視頻技術基礎：基本架構和協議棧》
《[觀點] WebRTC應該選擇H.264視頻編碼的四大理由》
《基於開源WebRTC開發實時音視頻靠譜嗎？第3方SDK有哪些？》

《開源實時音視頻技術WebRTC中RTP/RTCP數據傳輸協議的應用》
《實時通信RTC技術棧之：視頻編解碼》
《開源實時音視頻技術WebRTC在Windows下的簡明編譯教程》
《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》

3、實時通信技術的廣闊前景

根據騰訊全球合作夥伴大會上發布的《2017 年微信數據報告》顯示，截止到 2017 年 9 月，微信日成功通話次數 2.05 次，月人均通話時長 139 分鐘，月人均通話次數 19 次。通過這些數據我們可以看到，微信視頻通話的出現，已潛移默化地改變了人與人通信的方式。

而回望三大運營商的數據，語音通話量在 2015 年首次出現了負增長，可以看到互聯網 OTT 應用對傳統語音通話業務的衝擊有多強烈。正是由於這些日益完善的基礎設施，更快的智能手機，更快的網路，更豐富的使用場景，實時通信的需求越來越強烈。

從 2015 開始不斷湧現出的互動直播、狼人殺、抓娃娃、直播答題、線上 KTV 等創新，將常見的線下場景轉至線上，也足以作為實時音視頻通信風頭正勁的有力佐證。

越來越多的創業者都在思考如何將線下互動的場景搬到線上，從而打造下一個風靡全民爆款的應用。

說到實時通信，不得不提到 WebRTC，WebRTC 全名為 Web Real Time Communication，從 Web 這個詞就可以看出，最初這項技術是為瀏覽器量身打造用以實時音視頻能力而準備的。

但其實 WebRTC 在不同場景下包含不同的含義，它既可以代表 Google 開源的 WebRTC 項目，又可以代表 W3C 工作組制定的 WebRTC 標準，也可以代表瀏覽器中的 WebRTC 介面，我們將他們統稱為 WebRTC 技術。當前具有實時音視頻能力的應用或者服務，或多或少都使用了 WebRTC 技術，當然所有的這些背後都離不開 Google 開源的 WebRTC 項目，下面我們扒一扒 WebRTC 背後的故事。

4、WebRTC是什麼來頭？

說到 WebRTC，我們不得不提到 Gobal IP Solutions，簡稱 GIPS。這是一家 1990 年成立於瑞典斯德哥爾摩的 VoIP 軟體開發商，提供了可以說是世界上最好的語音引擎。相關介紹詳見《訪談WebRTC標準之父：WebRTC的過去、現在和未來》。

Skype、騰訊 QQ、WebEx、Vidyo 等都使用了它的音頻處理引擎，包含了受專利保護的回聲消除演算法，適應網路抖動和丟包的低延遲演算法，以及先進的音頻編解碼器。

Google 在 Gtalk 中也使用了 GIPS 的授權。Google 在 2011 年收購了 GIPS，並將其源代碼開源，加上在 2010 年收購的 On2 獲取到的 VPx 系列視頻編解碼器（詳見《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》），WebRTC 開源項目應運而生，即 GIPS 音視頻引擎 + 替換掉 H.264 的 VPx 視頻編解碼器。

在此之後，Google 又將在 Gtalk 中用於 P2P 打洞的開源項目 libjingle 融合進了 WebRTC。所以目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在內的所有平台的 API，保證了 API 在所有平台的一致性。

基於這些先進技術，使用 WebRTC 的為我們帶來的好處主要有以下幾個方面：

免費的使用 GIPS 先進的音視頻引擎，在此之前都需要付費授權；

由於音視頻傳輸是基於點對點傳輸的，所以實現簡單的 1 對 1 通話場景，需要較少的伺服器資源，藉助免費的 STUN/TURN 伺服器可以大大節約成本開銷；

開發 Web 版本的應用非常方便，使用簡單的 JS 介面，無需安裝任何插件，即可實現音視頻互通。

5、WebRTC 標準掀起的影響

2017 年 11 月 2 日，在經歷了 6 年的時間之後，W3C WebRTC 1.0 草案正式定稿。同樣也是在 2017 年，Microsoft Edge 與 Apple Safari 也紛紛宣稱了在其最新的版本里支持 WebRTC 1.0 標準 API。

雖然不同瀏覽器廠商在某些實現細節方面有所差別，比如 Safari 只支持 H.264，不同的 SDP 描述格式等等，但除了 IE 之外，所有主流瀏覽器 Google Chrome、Mozilla Firefox、Apple Safari、Microsoft Edge 都已經支持 WebRTC 1.0，所有瀏覽器之間無插件化的音視頻互通已經成為一種可能。

即時通訊網註：為什麼蘋果等商業公司堅持H.264標準？這其實是以蘋果為代表的商業公司或聯盟和谷歌之間的音視頻編碼標準之爭，詳見《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》，但業界普遍認為至少目前看來H.264標準（下一代被稱為H.265）各方面要優於VP8（下一代是VP9），具體請見《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》。

越來越多的終端設備上，無需藉助任何插件或者 native 應用，通過打開網頁鏈接，即可進行高質量的音視頻通話，應用開發者也無需關注音視頻引擎實現細節，大大節約了開發成本。

6、WebRTC廣泛的適用場景

WebRTC 適用的場景可以說是非常廣泛，很多行業結合實時通信都可以創造出非常有意思的場景，傳統的實時通信應用場景主要是在視頻會議、視頻面試、VoIP 通話、呼叫中心，產品如 WebEx、Skype 等。

當下比較火的場景主要集中在社交、遊戲、體育、電視、相親類的直播，以及互動連麥、在線教育、在線醫療、金融證券在線開戶、智能硬體（如無人機）、智能家居設備如攝像頭監控以及智能語音設備。

當然 WebRTC 除了提供音視頻傳輸功能，還有一個容易被忽略的功能就是數據傳輸。利用點對點的傳輸機制，一些開發者創造出了諸如 Webtorrent 以及 PeerCDN 這樣的不經過伺服器的數據傳輸網路服務。所以 WebRTC 非常適合用來打造實時通信的應用。

而直播作為當下的熱點應用，肯定少不了對於 WebRTC 的使用，而這又要提到 rtmp。

7、從 RTMP 到 WebRTC

從應用角度來講，受到用戶使用習慣的改變，越來越多的直播產品都開始加入視頻互通的功能。同時，像視頻會議、視頻核保一類的應用方式也在不斷增加。這影響著技術選型的變遷。

RTMP(Real Time Messaging Protocol) 實時消息傳送協議是 Adobe Systems 公司為 Flash 播放器和伺服器之間音頻、視頻和數據傳輸開發的開放協議。隨著直播興起，很多人都將它用在直播上。

在協議方面，rtmp 完全可以滿足直播產品的需求，但由於其相對延時較高，不能滿足視頻互通的產品需求。於是大家很自然地將目光投向 UDP、QUIC（基於 UDP）一類延時更低的網路協議。

在技術框架方面，由於自研一套符合視頻互通要求的通信系統相對複雜，不僅涉及網路傳輸、前端開發、移動端開發，還要解決音視頻編解碼中複雜的演算法優化，對開發者的技術棧要求很高，所以越來越多的人選擇 WebRTC。

目前來看，WebRTC 已經獲得了越來越多瀏覽器廠商及相關技術廠商的支持，應用的前景將會更加廣闊。

但是受限於 WebRTC 自身的一些缺憾，一般開發者都不是直接完全使用 WebRTC，而是根據實際場景基於 WebRTC 進行二次開發。WebRTC 本身並不是萬能鑰匙，不可能一套代碼以及介面可以解決所有問題。

更多關於RTMP的知識，請見《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》、《基於RTMP協議的流媒體技術的原理與應用（技術論文）[附件下載]》。

8、WebRTC很優秀，但當前並非完美

WebRTC 是一個非常優秀的項目，直接拿來使用也存在以下問題，我們簡單總結一下：

第一：WebRTC 使用的是對點對傳輸，雖然節約了伺服器資源的開銷，但實際使用時也帶來了傳輸質量的問題，比如跨國以及跨運營商網路之間的傳輸質量往往很難保證，雖然 webRTC 有優秀的端對端質量控制演算法，但在錯綜複雜的網路條件下，表現也很難讓人滿意；

第二：WebRTC 在移動端的表現也很難讓人滿意。早期由於缺少對於 H.264 編解碼器的支持，使得移動端很長一段時間只能使用 VP8 軟體編解碼，導致在中低端手機上的表現較差，加上安卓自身碎片化的屬性，如果不針對不同機型做適配，很難有統一的用戶體驗；

第三：WebRTC 是為 1 對 1 通信場景設計的，如果要實現多人的場景，還是需要藉助服務端方案。即使當前有很多開源的 webRTC 伺服器實現，一個流媒體中轉伺服器或者混流伺服器的部署以及維護也是非常複雜的；

第四：在 Web 端需要面臨不同瀏覽器之間的兼容性問題。雖然使用 AdapterJS 可以解決不同瀏覽器之間的介面適配問題，但除此之外依然要面臨不同瀏覽器行為不一致的問題。可以說如果 WebRTC 如果直接拿過來商用的話，幾乎是不太可能的，當下普遍的解決方案是自研，根據自身的業務場景進行二次定製開發，或者更簡單一點使用第三方 SDK。

不可否認，WebRTC確實很優秀，但目前來說也並非完美，更多這方面的分析和總結請參見《網頁端實時音視頻技術WebRTC：看起來很美，但離生產應用還有多少坑要填？》、《簡述開源實時音視頻技術WebRTC的優缺點》。

9、展望WebRTC

未來在實時通信領域，WebRTC 依然是非常重要的一塊拼圖。

無論是 Web 還是 Native，都非常依賴 WebRTC 提供的音視頻引擎，尤其是在 Web 端，幾乎所有瀏覽器廠商的實現都是基於 Google WebRTC 項目。隨著 WebRTC 1.0 標準的定稿，各大瀏覽器的 WebRTC 介面已經基本得到統一。

一直以來，WebRTC 都缺少測試工具。在去年年底，Google 推出了 KITE 開源項目，用於幫助開發者檢測 WebRTC 應用在不同瀏覽器的互通性。對於標準化社區來講，下一步工作主要會圍繞提供一組更完備的測試套件，不僅可以幫助開發者測試 WebRTC 應用在 Web 端、Native 端的互通性與體驗，還有助於保證各廠商瀏覽器 WebRTC 介面功能的一致性，並逐步完善 WebRTC 缺失的功能。

在相關技術方面，QUIC 也進入更多人的視野。對於 WebRTC 來講，QUIC 可以加速數據通道的連接（至少原理上可行），還可以完全替代 SCTP。但問題是，目前支持 QUIC 的瀏覽器只有 Chrome 和 Opera。（有關QUIC協議的基本介紹和應用案例，請見《技術掃盲：新一代基於UDP的低延時網路傳輸層協議——QUIC詳解》、《讓互聯網更快：新一代QUIC協議在騰訊的技術實踐分享》）

另一方面，各瀏覽器也在持續不斷地修復問題，對不同硬體設備以及系統平台進行適配，保證 WebRTC 能穩定運行於除主流機型、系統版本以外，更多的設備上。

附錄：更多實時音視頻技術資料

《即時通訊音視頻開發（一）：視頻編解碼之理論概述》
《即時通訊音視頻開發（二）：視頻編解碼之數字視頻介紹》
《即時通訊音視頻開發（三）：視頻編解碼之編碼基礎》
《即時通訊音視頻開發（四）：視頻編解碼之預測技術介紹》
《即時通訊音視頻開發（五）：認識主流視頻編碼技術H.264》
《即時通訊音視頻開發（六）：如何開始音頻編解碼技術的學習》

《即時通訊音視頻開發（七）：音頻基礎及編碼原理入門》
《即時通訊音視頻開發（八）：常見的實時語音通訊編碼標準》
《即時通訊音視頻開發（九）：實時語音通訊的迴音及迴音消除概述》
《即時通訊音視頻開發（十）：實時語音通訊的迴音消除技術詳解》
《即時通訊音視頻開發（十一）：實時語音通訊丟包補償技術詳解》
《即時通訊音視頻開發（十二）：多人實時音視頻聊天架構探討》
《即時通訊音視頻開發（十三）：實時視頻編碼H.264的特點與優勢》
《即時通訊音視頻開發（十四）：實時音視頻數據傳輸協議介紹》
《即時通訊音視頻開發（十五）：聊聊P2P與實時音視頻的應用情況》
《即時通訊音視頻開發（十六）：移動端實時音視頻開發的幾個建議》

《即時通訊音視頻開發（十七）：視頻編碼H.264、VP8的前世今生》
《實時語音聊天中的音頻處理與編碼壓縮技術簡述》
《網易視頻雲技術分享：音頻處理與壓縮技術快速入門》
《學習RFC3550：RTP/RTCP實時傳輸協議基礎知識》
《基於RTMP數據傳輸協議的實時流媒體技術研究（論文全文）》
《聲網架構師談實時音視頻雲的實現難點(視頻採訪)》
《淺談開發實時視頻直播平台的技術要點》
《還在靠「喂喂喂」測試實時語音通話質量？本文教你科學的評測方法！》
《實現延遲低於500毫秒的1080P實時音視頻直播的實踐分享》
《移動端實時視頻直播技術實踐：如何做到實時秒開、流暢不卡》

《如何用最簡單的方法測試你的實時音視頻方案》
《技術揭秘：支持百萬級粉絲互動的Facebook實時視頻直播》
《簡述實時音視頻聊天中端到端加密（E2EE）的工作原理》
《移動端實時音視頻直播技術詳解（一）：開篇》
《移動端實時音視頻直播技術詳解（二）：採集》
《移動端實時音視頻直播技術詳解（三）：處理》
《移動端實時音視頻直播技術詳解（四）：編碼和封裝》
《移動端實時音視頻直播技術詳解（五）：推流和傳輸》
《移動端實時音視頻直播技術詳解（六）：延遲優化》
《理論聯繫實際：實現一個簡單地基於HTML5的實時視頻直播》
《IM實時音視頻聊天時的回聲消除技術詳解》
《淺談實時音視頻直播中直接影響用戶體驗的幾項關鍵技術指標》
《如何優化傳輸機制來實現實時音視頻的超低延遲？》
《首次披露：快手是如何做到百萬觀眾同場看直播仍能秒開且不卡頓的？》
《Android直播入門實踐：動手搭建一套簡單的直播系統》
《網易雲信實時視頻直播在TCP數據傳輸層的一些優化思路》
《實時音視頻聊天技術分享：面向不可靠網路的抗丟包編解碼器》
《P2P技術如何將實時視頻直播帶寬降低75%？》
《專訪微信視頻技術負責人：微信實時視頻聊天技術的演進》
《騰訊音視頻實驗室：使用AI黑科技實現超低碼率的高清實時視頻聊天》
《微信團隊分享：微信每日億次實時音視頻聊天背後的技術解密》
《近期大熱的實時直播答題系統的實現思路與技術難點分享》
《福利貼：最全實時音視頻開發要用到的開源工程匯總》
《七牛雲技術分享：使用QUIC協議實現實時視頻直播0卡頓！》
《實時音視頻聊天中超低延遲架構的思考與技術實踐》
《理解實時音視頻聊天中的延時問題一篇就夠》
《實時視頻直播客戶端技術盤點：Native、HTML5、WebRTC、微信小程序》
《寫給小白的實時音視頻技術入門提綱》
>> 更多同類文章 ……

（本文同步發佈於：http://www.52im.net/thread-1631-1-1.html）