作者：毛玉傑，聲網 WebRTC 專家
有人說 2017 年是 WebRTC 的轉折之年，2018 年將是 WebRTC 的爆發之年。去年，WebRTC 1.0 標準草案出爐，並將於今年正式釋出。與此同時，越來越多的瀏覽器和廠商都開始對它進行廣泛的支援，WebRTC 即將成為網際網路的基礎設施了。
根據《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 背後的故事。
回溯歷史：為什麼需要 WebRTC
說到 WebRTC，我們不得不提到 Gobal IP Solutions，簡稱 GIPS。這是一家 1990 年成立於瑞典斯德哥爾摩的 VoIP 軟體開發商，提供了可以說是世界上最好的語音引擎。 Skype、騰訊 QQ、WebEx、Vidyo 等都使用了它的音訊處理引擎，包含了受專利保護的回聲消除演算法，適應網路抖動和丟包的低延遲演算法，以及先進的音訊編解碼器。
Google 在 Gtalk 中也使用了 GIPS 的授權。Google 在 2011 年收購了 GIPS，並將其原始碼開源，加上在 2010 年收購的 On2 獲取到的 VPx 系列視訊編解碼器，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 介面，無需安裝任何外掛，即可實現音視訊互通。
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，所有瀏覽器之間無外掛化的音視訊互通已經成為一種可能。
越來越多的終端裝置上，無需藉助任何外掛或者 native 應用，通過開啟網頁連結，即可進行高質量的音視訊通話，應用開發者也無需關注音視訊引擎實現細節，大大節約了開發成本。
廣泛的適用場景
WebRTC 適用的場景可以說是非常廣泛，很多行業結合實時通訊都可以創造出非常有意思的場景，傳統的實時通訊應用場景主要是在視訊會議、視訊面試、VoIP 通話、呼叫中心，產品如 WebEx、Skype 等。
當下比較火的場景主要集中在社交、遊戲、體育、電視、相親類的直播，以及互動連麥、線上教育、線上醫療、金融證券線上開戶、智慧硬體（如無人機）、智慧家居裝置如攝像頭監控以及智慧語音裝置。
當然 WebRTC 除了提供音視訊傳輸功能，還有一個容易被忽略的功能就是資料傳輸。利用點對點的傳輸機制，一些開發者創造出了諸如 Webtorrent 以及 PeerCDN 這樣的不經過伺服器的資料傳輸網路服務。所以 WebRTC 非常適合用來打造實時通訊的應用。
而直播作為當下的熱點應用，肯定少不了對於 WebRTC 的使用，而這又要提到 rtmp。
從 RTMP 到 WebRTC
從應用角度來講，受到使用者使用習慣的改變，越來越多的直播產品都開始加入視訊互通的功能。同時，像視訊會議、視訊核保一類的應用方式也在不斷增加。這影響著技術選型的變遷。
RTMP(Real Time Messaging Protocol) 實時訊息傳送協議是 Adobe Systems 公司為 Flash 播放器和伺服器之間音訊、視訊和資料傳輸開發的開放協議。隨著直播興起，很多人都將它用在直播上。
在協議方面，rtmp 完全可以滿足直播產品的需求，但由於其相對延時較高，不能滿足視訊互通的產品需求。於是大家很自然地將目光投向 UDP、QUIC（基於 UDP）一類延時更低的網路協議。
在技術框架方面，由於自研一套符合視訊互通要求的通訊系統相對複雜，不僅涉及網路傳輸、前端開發、移動端開發，還要解決音視訊編解碼中複雜的演算法優化，對開發者的技術棧要求很高，所以越來越多的人選擇 WebRTC。
目前來看，WebRTC 已經獲得了越來越多瀏覽器廠商及相關技術廠商的支援，應用的前景將會更加廣闊。
但是受限於 WebRTC 自身的一些缺憾，一般開發者都不是直接完全使用 WebRTC，而是根據實際場景基於 WebRTC 進行二次開發。WebRTC 本身並不是萬能鑰匙，不可能一套程式碼以及介面可以解決所有問題。
如何做二次改造？
WebRTC 是一個非常優秀的專案，但如果直接拿來使用也存在以下問題。
第一，WebRTC 使用的是對點對傳輸，雖然節約了伺服器資源的開銷，但實際使用時也帶來了傳輸質量的問題，比如跨國以及跨運營商網路之間的傳輸質量往往很難保證，雖然 webRTC 有優秀的端對端質量控制演算法，但在錯綜複雜的網路條件下，表現也很難讓人滿意。
第二，WebRTC 在移動端的表現也很難讓人滿意。早期由於缺少對於 H.264 編解碼器的支援，使得移動端很長一段時間只能使用 VP8 軟體編解碼，導致在中低端手機上的表現較差，加上安卓自身碎片化的屬性，如果不針對不同機型做適配，很難有統一的使用者體驗。
第三，WebRTC 是為 1 對 1 通訊場景設計的，如果要實現多人的場景，還是需要藉助服務端方案。即使當前有很多開源的 webRTC 伺服器實現，一個流媒體中轉伺服器或者混流伺服器的部署以及維護也是非常複雜的。
第四，在 Web 端需要面臨不同瀏覽器之間的相容性問題。雖然使用 AdapterJS 可以解決不同瀏覽器之間的介面適配問題，但除此之外依然要面臨不同瀏覽器行為不一致的問題。可以說如果 WebRTC 如果直接拿過來商用的話，幾乎是不太可能的，當下普遍的解決方案是自研，根據自身的業務場景進行二次定製開發，或者更簡單一點使用第三方 SDK。
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。
另一方面，各瀏覽器也在持續不斷地修復問題，對不同硬體裝置以及系統平臺進行適配，保證 WebRTC 能穩定執行於除主流機型、系統版本以外，更多的裝置上。
如果你也正在開發 WebRTC 應用，遇到疑問，歡迎訪問 RTC 開發者社群，發帖與更多同行交流，或分享你的成果。