根據(jù)騰訊全球合作伙伴大會上發(fā)布的《2017 年微信數(shù)據(jù)報告》顯示，截止到 2017 年 9 月，微信日成功通話次數(shù) 2.05 次，月人均通話時長 139 分鐘，月人均通話次數(shù) 19 次。通過這些數(shù)據(jù)我們可以看到，微信視頻通話的出現(xiàn)，已潛移默化地改變了人與人通信的方式。
而回望三大運營商的數(shù)據(jù)，語音通話量在 2015 年首次出現(xiàn)了負增長，可以看到互聯(lián)網(wǎng) OTT 應用對傳統(tǒng)語音通話業(yè)務的沖擊有多強烈。正是由于這些日益完善的基礎(chǔ)設施，更快的智能手機，更快的網(wǎng)絡，更豐富的使用場景，實時通信的需求越來越強烈。
從 2015 開始不斷涌現(xiàn)出的互動直播、狼人殺、抓娃娃、直播答題、線上 KTV 等創(chuàng)新，將常見的線下場景轉(zhuǎn)至線上，也足以作為實時音視頻通信風頭正勁的有力佐證。
越來越多的創(chuàng)業(yè)者都在思考如何將線下互動的場景搬到線上，從而打造下一個風靡全民爆款的應用。
說到實時通信，不得不提到 WebRTC，WebRTC 全名為 Web Real Time Communication，從 Web 這個詞就可以看出，最初這項技術(shù)是為瀏覽器量身打造用以實時音視頻能力而準備的。
但其實 WebRTC 在不同場景下包含不同的含義，它既可以代表 Google 開源的 WebRTC 項目，又可以代表 W3C 工作組制定的 WebRTC 標準，也可以代表瀏覽器中的 WebRTC 接口，我們將他們統(tǒng)稱為 WebRTC 技術(shù)。當前具有實時音視頻能力的應用或者服務，或多或少都使用了 WebRTC 技術(shù)，當然所有的這些背后都離不開 Google 開源的 WebRTC 項目，下面我們扒一扒 WebRTC 背后的故事。
回溯歷史：為什么需要 WebRTC
說到 WebRTC，我們不得不提到 Gobal IP Solutions，簡稱 GIPS。這是一家 1990 年成立于瑞典斯德哥爾摩的 VoIP 軟件開發(fā)商，提供了可以說是世界上最好的語音引擎。
Skype、騰訊 QQ、WebEx、Vidyo 等都使用了它的音頻處理引擎，包含了受專利保護的回聲消除算法，適應網(wǎng)絡抖動和丟包的低延遲算法，以及先進的音頻編解碼器。
Google 在 Gtalk 中也使用了 GIPS 的授權(quán)。Google 在 2011 年收購了 GIPS，并將其源代碼開源，加上在 2010 年收購的 On2 獲取到的 VPx 系列視頻編解碼器，WebRTC 開源項目應運而生，即 GIPS 音視頻引擎 + 替換掉 H.264 的 VPx 視頻編解碼器。
在此之后，Google 又將在 Gtalk 中用于 P2P 打洞的開源項目 libjingle 融合進了 WebRTC。所以目前 WebRTC 提供了在 Web、iOS、Android、Mac、Windows、Linux 在內(nèi)的所有平臺的 API，保證了 API 在所有平臺的一致性。使用 WebRTC 的好處主要有以下幾個方面：
免費的使用 GIPS 先進的音視頻引擎，在此之前都需要付費授權(quán)。
由于音視頻傳輸是基于點對點傳輸?shù)模詫崿F(xiàn)簡單的 1 對 1 通話場景，需要較少的服務器資源，借助免費的 STUN/TURN 服務器可以大大節(jié)約成本開銷。
開發(fā) Web 版本的應用非常方便，使用簡單的 JS 接口，無需安裝任何插件，即可實現(xiàn)音視頻互通。
WebRTC 標準掀起的影響
2017 年 11 月 2 日，在經(jīng)歷了 6 年的時間之后，W3C WebRTC 1.0 草案正式定稿。同樣也是在 2017 年，Microsoft Edge 與 Apple Safari 也紛紛宣稱了在其最新的版本里支持 WebRTC 1.0 標準 API。
雖然不同瀏覽器廠商在某些實現(xiàn)細節(jié)方面有所差別，比如 Safari 只支持 H.264，不同的 SDP 描述格式等等，但除了 IE 之外，所有主流瀏覽器 Google Chrome、Mozilla Firefox、Apple Safari、Microsoft Edge 都已經(jīng)支持 WebRTC 1.0，所有瀏覽器之間無插件化的音視頻互通已經(jīng)成為一種可能。
越來越多的終端設備上，無需借助任何插件或者 native 應用，通過打開網(wǎng)頁鏈接，即可進行高質(zhì)量的音視頻通話，應用開發(fā)者也無需關(guān)注音視頻引擎實現(xiàn)細節(jié)，大大節(jié)約了開發(fā)成本。
廣泛的適用場景
WebRTC 適用的場景可以說是非常廣泛，很多行業(yè)結(jié)合實時通信都可以創(chuàng)造出非常有意思的場景，傳統(tǒng)的實時通信應用場景主要是在視頻會議、視頻面試、VoIP 通話、呼叫中心，產(chǎn)品如 WebEx、Skype 等。
當下比較火的場景主要集中在社交、游戲、體育、電視、相親類的直播，以及互動連麥、在線教育、在線醫(yī)療、金融證券在線開戶、智能硬件（如無人機）、智能家居設備如攝像頭監(jiān)控以及智能語音設備。
當然 WebRTC 除了提供音視頻傳輸功能，還有一個容易被忽略的功能就是數(shù)據(jù)傳輸。利用點對點的傳輸機制，一些開發(fā)者創(chuàng)造出了諸如 Webtorrent 以及 PeerCDN 這樣的不經(jīng)過服務器的數(shù)據(jù)傳輸網(wǎng)絡服務。所以 WebRTC 非常適合用來打造實時通信的應用。
而直播作為當下的熱點應用，肯定少不了對于 WebRTC 的使用，而這又要提到 rtmp。
從 RTMP 到 WebRTC
從應用角度來講，受到用戶使用習慣的改變，越來越多的直播產(chǎn)品都開始加入視頻互通的功能。同時，像視頻會議、視頻核保一類的應用方式也在不斷增加。這影響著技術(shù)選型的變遷。
RTMP（Real Time Messaging Protocol） 實時消息傳送協(xié)議是 Adobe Systems 公司為 Flash 播放器和服務器之間音頻、視頻和數(shù)據(jù)傳輸開發(fā)的開放協(xié)議。隨著直播興起，很多人都將它用在直播上。
在協(xié)議方面，rtmp 完全可以滿足直播產(chǎn)品的需求，但由于其相對延時較高，不能滿足視頻互通的產(chǎn)品需求。于是大家很自然地將目光投向 UDP、QUIC（基于 UDP）一類延時更低的網(wǎng)絡協(xié)議。
在技術(shù)框架方面，由于自研一套符合視頻互通要求的通信系統(tǒng)相對復雜，不僅涉及網(wǎng)絡傳輸、前端開發(fā)、移動端開發(fā)，還要解決音視頻編解碼中復雜的算法優(yōu)化，對開發(fā)者的技術(shù)棧要求很高，所以越來越多的人選擇 WebRTC。
目前來看，WebRTC 已經(jīng)獲得了越來越多瀏覽器廠商及相關(guān)技術(shù)廠商的支持，應用的前景將會更加廣闊。
但是受限于 WebRTC 自身的一些缺憾，一般開發(fā)者都不是直接完全使用 WebRTC，而是根據(jù)實際場景基于 WebRTC 進行二次開發(fā)。WebRTC 本身并不是萬能鑰匙，不可能一套代碼以及接口可以解決所有問題。
如何做二次改造？
WebRTC 是一個非常優(yōu)秀的項目，但如果直接拿來使用也存在以下問題。
第一，WebRTC 使用的是對點對傳輸，雖然節(jié)約了服務器資源的開銷，但實際使用時也帶來了傳輸質(zhì)量的問題，比如跨國以及跨運營商網(wǎng)絡之間的傳輸質(zhì)量往往很難保證，雖然 webRTC 有優(yōu)秀的端對端質(zhì)量控制算法，但在錯綜復雜的網(wǎng)絡條件下，表現(xiàn)也很難讓人滿意。
第二，WebRTC 在移動端的表現(xiàn)也很難讓人滿意。早期由于缺少對于 H.264 編解碼器的支持，使得移動端很長一段時間只能使用 VP8 軟件編解碼，導致在中低端手機上的表現(xiàn)較差，加上安卓自身碎片化的屬性，如果不針對不同機型做適配，很難有統(tǒng)一的用戶體驗。
第三，WebRTC 是為 1 對 1 通信場景設計的，如果要實現(xiàn)多人的場景，還是需要借助服務端方案。即使當前有很多開源的 webRTC 服務器實現(xiàn)，一個流媒體中轉(zhuǎn)服務器或者混流服務器的部署以及維護也是非常復雜的。
第四，在 Web 端需要面臨不同瀏覽器之間的兼容性問題。雖然使用 AdapterJS 可以解決不同瀏覽器之間的接口適配問題，但除此之外依然要面臨不同瀏覽器行為不一致的問題�？梢哉f如果 WebRTC 如果直接拿過來商用的話，幾乎是不太可能的，當下普遍的解決方案是自研，根據(jù)自身的業(yè)務場景進行二次定制開發(fā)，或者更簡單一點使用第三方 SDK。
WebRTC 的前景
未來在實時通信領(lǐng)域，WebRTC 依然是非常重要的一塊拼圖。
無論是 Web 還是 Native，都非常依賴 WebRTC 提供的音視頻引擎，尤其是在 Web 端，幾乎所有瀏覽器廠商的實現(xiàn)都是基于 Google WebRTC 項目。隨著 WebRTC 1.0 標準的定稿，各大瀏覽器的 WebRTC 接口已經(jīng)基本得到統(tǒng)一。
一直以來，WebRTC 都缺少測試工具。在去年年底，Google 推出了 KITE 開源項目，用于幫助開發(fā)者檢測 WebRTC 應用在不同瀏覽器的互通性。對于標準化社區(qū)來講，下一步工作主要會圍繞提供一組更完備的測試套件，不僅可以幫助開發(fā)者測試 WebRTC 應用在 Web 端、Native 端的互通性與體驗，還有助于保證各廠商瀏覽器 WebRTC 接口功能的一致性，并逐步完善 WebRTC 缺失的功能。
在相關(guān)技術(shù)方面，QUIC 也進入更多人的視野。對于 WebRTC 來講，QUIC 可以加速數(shù)據(jù)通道的連接（至少原理上可行），還可以完全替代 SCTP。但問題是，目前支持 QUIC 的瀏覽器只有 Chrome 和 Opera。
另一方面，各瀏覽器也在持續(xù)不斷地修復問題，對不同硬件設備以及系統(tǒng)平臺進行適配，保證 WebRTC 能穩(wěn)定運行于除主流機型、系統(tǒng)版本以外，更多的設備上。
