做者:毛玉傑,聲網 WebRTC 專家前端
有人說 2017 年是 WebRTC 的轉折之年,2018 年將是 WebRTC 的爆發之年。去年,WebRTC 1.0 標準草案出爐,並將於今年正式發佈。與此同時,愈來愈多的瀏覽器和廠商都開始對它進行普遍的支持,WebRTC 即將成爲互聯網的基礎設施了。web
根據《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,咱們不得不提到 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 的好處主要有如下幾個方面:工具
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(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 依然是很是重要的一塊拼圖。
不管是 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 開發者社區,發帖與更多同行交流,或分享你的成果。