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