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 可以解決不同瀏覽器之間的接口適配問題，但除此之外依然要面臨不同瀏覽器行為不一致的問題?？梢哉f如果 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）