在以前的文章中，咱們描述了目前直播經常使用的協議--RTMP。並也說明了爲何目前主流直播平臺沒有采用RTP和基於它的WebRTC。可是咱們也要意識到WebRTC在實時音視頻上的普遍應用，好比視屏會議，屏幕共享等場景。而且目前基於WebRTC進行深度定製的直播平臺也愈來愈多，因此咱們也來聊一聊WebRTC。ios
什麼是WebRTCgit
WebRTC是Web Real-Time Communication，即網頁實時通訊的縮寫，是RTC協議的一種Web實現。項目由Google開源，並和IETF和W3C制定了行業標準，目前已成爲下一代視頻通話的標準。
github
瀏覽器自己不支持相互之間之間直接創建通訊，通常都是經過服務器進行中轉。這樣的問題在於雙方的通訊須要經過兩段信道，使得通訊的效率受到了更多的限制。因此如何創建瀏覽器之間的點對點傳輸，一直困擾着開發者，而這就是WebRTC產生的緣由。web
WebRTC容許網絡應用在不借助中間媒介的狀況下，創建點對點的鏈接，從而實現音視頻流和其餘數據的傳輸。WebRTC這個項目使得瀏覽器能爲實時通訊（RTC）提供簡單的JavaScript接口。實現方式是經過一系列的信令，創建瀏覽器之間的信道。這個信道能夠發送任何數據而無需通過服務器。瀏覽器
固然WebRTC的內容不只僅包含上面這些，還包含媒體、加密、傳輸等在內的多項標準和協議。經過提供的原生JavaScript API，在不依賴其餘插件的狀況下，擁有P2P音視頻和數據分享的能力。安全
固然上面所說的不借助中間媒介是指點對點通訊時不須要第三方進行轉發。而若是須要依賴WebRTC框架，仍須要另外的服務器來傳輸一些其餘的信息，好比雙方的基本信息，在沒創建鏈接以前得到對方的IP，協議版本等。服務器
WebRTC的設計微信
WebRTC的架構圖咱們能夠在官網（地址見文末）中查到，以下圖：
網絡
咱們能夠看到整個架構主要分爲幾個部分：session
Web API：提供給Web開發者的API層。供開發者開發基於視頻和音頻等的實時通訊應用。標準有W3C聯盟指定
WebRTC C++ API：提供給瀏覽器廠商的API層，供瀏覽器廠商實現WebRTC標準的Web API，其中主要是抽象的對數字信號過程進行處理。
會話層：一個抽象的會話層，提供會話創建和管理功能，該層協議由應用開發者自定義實現。
傳輸層：主要包含兩個部分，一個RTP協議棧，另外一個是STUN/TURN/ICE層，主要經過STUN和ICE組件來創建不一樣類型網絡間的鏈接。
Engine：音視頻引擎，包含一系列多媒體處理的框架，包含從視頻採集卡到網絡傳輸等整個解決方案。音頻引擎負責音頻採集和傳輸，具備降噪、回聲消除等功能。視頻引擎負責網絡抖動優化，互聯網傳輸編解碼優化。這個是WebRTC中極具價值的技術之一，是由Google收購GIPS公司開源的，在整個VoIP界，都算是技術領先的。
瀏覽器設備廠商自行實現的硬件接口：包含音頻捕捉模塊和視頻捕捉模塊。以及網絡IO接口。
基於上面的理解，咱們將架構進行進一步簡化來梳理WebRTC的流程：
整個流程是：最底層是硬件設備，上面是音頻捕獲模塊和視頻捕獲模塊。中間部分爲音視頻引擎。在音視頻引擎之上是 一套 C++ API，在 C++ 的 API 之上是提供給瀏覽器的Javascript API。這個就是整個WebRTC的主要流程。
WebRTC的協議棧
在 爲何直播系統不用RTP協議 中，咱們簡單說了主流音視頻傳輸協議在網絡協議中的位置：
咱們在這張圖能夠看到WebRTC主要是基於RTP以及它的伴生協議RTCP。這裏咱們看一下WebRTC主要涉及到的網絡協議棧：
這裏分爲兩部分，一部分是左半邊的WebRTC框架中依賴的信令服務器使用的協議，這個咱們以後再講。這裏咱們主要關注右半邊WebRTC核心的協議棧，包含如下幾個部分：
UDP基礎：WebRTC傳輸層協議主要依靠UDP，這個是關鍵，和其餘基於TCP協議的傳輸協議相比，傳輸效率更高，成本也更低。這裏WebRTC使用的UDP拓展協議RTP和它的伴生協議RTCP。
ICE，STUN，TURN：也是傳輸層協議，主要是用於內網穿透，解決獲取與綁定外網映射地址以及keep alive機制。
DTLS：會話層協議，主要是用於保證數據傳輸的安全。
SCTP和SRTP：用於在UDP上提供不一樣流的多路複用、擁塞和流量控制，以及部分可靠的交付和其餘服務。
WebRTC的現狀
WebRTC從發展初期，由於其強大的功能和先進的設計理念。獲得不少瀏覽器廠商的支持，即便是蘋果也在2017年宣佈Safari 11支持WebRTC。因此目前咱們從下圖能夠看到目前主流的瀏覽器基本上都支持WebRTC。
圖片來自：https://caniuse.com/#search=webrtc
WebRTC瀏覽器兼容狀況
WebRTC的使用範圍
經過上面的瞭解，不少人都認爲WebRTC就應該在瀏覽器端使用，可是現實狀況反而是相反的，在瀏覽器端開發是最簡單的，由於提供了很是簡單的JavaScript API。可是卻受到JavaScript和瀏覽器的限制，並且若是應用場景足夠豐富，那麼對於瀏覽器的兼容性也須要考慮在內。同時瀏覽器在長時間直播或者會議上可能會有問題，而且功能也較弱，好比分辨率控制、多路語音混音都作不了。固然還有其餘問題，好比Chrome同時給6個客戶端發視頻流就很消耗資源了，因此你若是有超過10個用戶收看的話，Chrome很容易崩潰。
那麼WebRTC的最佳使用範圍是哪裏呢？咱們從上面架構圖能夠看到WebRTC提供了兩層API，底層是C++寫的Native庫，上層是JavaScript封裝。因此咱們徹底能夠忽略上層的JavaScript限制，直接使用底層的Native庫，這樣咱們能夠開發跨平臺的APP，而且能夠擁有更高的權限和能力。並且Google在開發WebRTC時已考慮用在app，底層C++庫的API已作得很完善了。因此對於WebRTC的最佳使用是基於WebRTC Native庫來實現各類平臺的APP，以達到最佳的體檢。
總結
今天咱們主要簡單瞭解一下WebRTC，包括WebRTC是什麼，他的設計理念以及目前的現狀。經過這些，咱們能夠了解如今音視頻和直播領域依賴的技術背後到底是什麼。在之後的文章中，咱們會繼續深刻了解WebRTC系統的設計，和其餘組件的運用。以及其餘相關的知識。
WebRTC 架構：
https://webrtc.github.io/webrtc-org/architecture/
本文分享自微信公衆號 - 雨夜隨筆（yuye_suibi）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。