WebRTC入門與提高1：WebRTC基礎入門

1 WebRTC入門

本章目的：

1. 了解什么WebRTC
2. 掌握WebRTC通話原理
3. 學完該課程的收獲

1.1 什么是WebRTC

WebRTC（Web Real-Time Communication）是 Google於2010以6829萬美元從 Global IP Solutions 公司購買，並於2011年將其開源，旨在建立一個互聯網瀏覽器間的實時通信的平台，讓 WebRTC技術成為 H5標准之一。我們看官網（https://webrtc.org）的介紹

從官網上的描述我們可以知道，WebRTC是一個免費的開放項目，它通過簡單的API為瀏覽器和移動應用程序提供實時通信（RTC）功能。

1.2 WebRTC框架

上圖的框架對於不同的開發人員關注點不同：

（1）紫色部分是Web應用開發者API層

（2）藍色實線部分是面向瀏覽器廠商的API層

（3）藍色虛線部分瀏覽器廠商可以自定義實現

特別是圖中的 PeerConnection 為 Web 開發人員提供了一個抽象，從復雜的內部結構中抽象出來。我們只需要關注PeerConnection這個對象即可以開發音視頻通話應用內。

WebRTC架構組件介紹

Your Web App
Web開發者開發的程序，Web開發者可以基於集成WebRTC的瀏覽器提供的web API開發基於視頻、音頻的實時通信應用。

Web API

面向第三方開發者的WebRTC標准API（Javascript），使開發者能夠容易地開發出類似於網絡視頻聊天的web應用，最新的標准化進程可以查看這里。

WebRTC Native C++ API

本地C++ API層，使瀏覽器廠商容易實現WebRTC標准的Web API，抽象地對數字信號過程進行處理。

Transport / Session

傳輸/會話層

會話層組件采用了libjingle庫的部分組件實現，無須使用xmpp/jingle協議

VoiceEngine

音頻引擎是包含一系列音頻多媒體處理的框架。

PS：VoiceEngine是WebRTC極具價值的技術之一，是Google收購GIPS公司后開源的。在VoIP上，技術業界領先。

Opus：支持從6 kbit/s到510 kbit/s的恆定和可變比特率編碼，幀大小從2.5 ms到60 ms，各種采樣率從8 kHz（4 kHz帶寬）到48 kHz（20 kHz帶寬，可復制人類聽覺系統的整個聽力范圍）。由IETF RFC 6176定義。

NetEQ模塊是Webrtc語音引擎中的核心模塊 ，一種動態抖動緩沖和錯誤隱藏算法，用於隱藏網絡抖動和數據包丟失的負面影響。保持盡可能低的延遲，同時保持最高的語音質量。

VideoEngine

WebRTC視頻處理引擎

VideoEngine是包含一系列視頻處理的整體框架，從攝像頭采集視頻到視頻信息網絡傳輸再到視頻顯示整個完整過程的解決方案。

VP8 視頻圖像編解碼器，是WebRTC視頻引擎的默認的編解碼器

VP8適合實時通信應用場景，因為它主要是針對低延時而設計的編解碼器。

1.3 WebRTC發展前景

WebRTC雖然冠以“web”之名，但並不受限於傳統互聯網應用或瀏覽器的終端運行環境。實際上無論終端運行環境是瀏覽器、桌面應用、移動設備（Android或iOS）還是IoT設備，只要IP連接可到達且符合WebRTC規范就可以互通。這一點釋放了大量智能終端（或運行在智能終端上的app）的實時通信能力，打開了許多對於實時交互性要求較高的應用場景的想象空間，譬如在線教育、視頻會議、視頻社交、遠程協助、遠程操控等等都是其合適的應用領域。

全球領先的技術研究和咨詢公司Technavio最近發布了題為“全球網絡實時通訊（WebRTC）市場，2017-2021”的報告。報告顯示，2017-2021年期間，全球網絡實時通信（WebRTC）市場將以34.37％的年均復合增長率增長，增長十分迅速。增長主要來自北美、歐洲及亞太地區。

1.4 國內方案廠商

聲網、即構科技、環信、融雲等公司都在基於WebRTC二次開發自己的音視頻通話方案。

聲網 https://www.agora.io/cn/

即構科技 https://www.zego.im/

1.5 WebRTC通話原理

首先思考的問題：兩個不同網絡環境的（具備攝像頭/麥克風多媒體設備的）瀏覽器，要實現點對點 的實時音視頻對話，難點在哪里？

1. 媒體協商

彼此要了解對方支持的媒體格式

比如：Peer-A端可支持VP8、H264多種編碼格式，而Peer-B端支持VP9、H264，要保證二端都正確的編解碼，最簡單的辦法就是取它們的交集H264

注：有一個專門的協議 ，稱為Session Description Protocol (SDP)，可用於描述上述這類信息，在WebRTC中，參與視頻通訊的雙方必須先交換SDP信息，這樣雙方才能知根知底，而交換SDP的過程，也稱為"媒體協商"。

2. 網絡協商

彼此要了解對方的網絡情況，這樣才有可能找到一條相互通訊的鏈路

先說結論：(1)獲取外網IP地址映射；（2）通過信令服務器（signal server）交換"網絡信息"

理想的網絡情況是每個瀏覽器的電腦都是私有公網IP，可以直接進行點對點連接。

實際情況是：我們的電腦和電腦之前或大或小都是在某個局域網中，需要NAT（Network Address Translation，網絡地址轉換），顯示情況如下圖：

 

在解決WebRTC使用過程中的上述問題的時候，我們需要用到STUN和TURN。

STUN
STUN（Session Traversal Utilities for NAT，NAT會話穿越應用程序）是一種網絡協議，它允許位於NAT（或多重NAT）后的客戶端找出自己的公網地址，查出自己位於哪種類型的NAT之后以及NAT為某一個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處於NAT路由器之后的主機之間創建UDP通信。該協議由RFC 5389定義。

在遇到上述情況的時候，我們可以建立一個STUN服務器，這個服務器做什么用的呢？主要是給無法在公網環境下的視頻通話設備分配公網IP用的。這樣兩台電腦就可以在公網IP中進行通話。

使用一句話說明STUN做的事情就是：告訴我你的公網IP地址+端口是什么。搭建STUN服務器很簡單，媒體流傳輸是按照P2P的方式。

那么問題來了，STUN並不是每次都能成功的為需要NAT的通話設備分配IP地址的，P2P在傳輸媒體流時，使用的本地帶寬，在多人視頻通話的過程中，通話質量的好壞往往需要根據使用者本地的帶寬確定。那么怎么辦？TURN可以很好的解決這個問題。

TURN

TURN的全稱為Traversal Using Relays around NAT，是STUN/RFC5389的一個拓展，主要添加了Relay功能。如果終端在NAT之后， 那么在特定的情景下，有可能使得終端無法和其對等端（peer）進行直接的通信，這時就需要公網的服務器作為一個中繼， 對來往的數據進行轉發。這個轉發的協議就被定義為TURN。

在上圖的基礎上，再架設幾台TURN服務器：

在STUN分配公網IP失敗后，可以通過TURN服務器請求公網IP地址作為中繼地址。這種方式的帶寬由服務器端承擔，在多人視頻聊天的時候，本地帶寬壓力較小，並且，根據Google的說明，TURN協議可以使用在所有的環境中。（單向數據200kbps 一對一通話）

以上是WebRTC中經常用到的2個協議，STUN和TURN服務器我們使用coturn開源項目來搭建。

補充：ICE跟STUN和TURN不一樣，ICE不是一種協議，而是一個框架（Framework），它整合了STUN和TURN。coturn開源項目集成了STUN和TURN的功能。

在WebRTC中用來描述 網絡信息的術語叫candidate。

即是：

1. 媒體協商 sdp
2. 網絡協商 candidate

 

3. 媒體協商+網絡協商數據的交換通道

從上面1/2點我們知道了2個客戶端協商媒體信息和網絡信息，那怎么去交換？是不是需要一個中間商去做交換？所以我們需要一個信令服務器（Signal server）轉發彼此的媒體信息和網絡信息。

如上圖，我們在基於WebRTC API開發應用（APP）時，可以將彼此的APP連接到信令服務器（Signal Server，一般搭建在公網，或者兩端都可以訪問到的局域網），借助信令服務器，就可以實現上面提到的SDP媒體信息及Candidate網絡信息交換。

信令服務器不只是交互 媒體信息sdp和網絡信息candidate，比如：

（1）房間管理

（2）人員進出房間

WebRTC APIs

MediaStream —  MediaStream用來表示一個媒體數據流（通過getUserMedia接口獲取），允許你訪問輸入設備，如麥克風和 Web攝像機,該 API 允許從其中任意一個獲取媒體流。

1. RTCPeerConnection — RTCPeerConnection 對象允許用戶在兩個瀏覽器之間直接通訊 ，你可以通過網絡將捕獲的音頻和視頻流實時發送到另一個 WebRTC 端點。使用這些 Api，你可以在本地機器和遠程對等點之間創建連接。它提供了連接到遠程對等點、維護和監視連接以及在不再需要連接時關閉連接的方法。

4. 一對一通話

在一對一通話場景中，每個 Peer均創建有一個 PeerConnection 對象，由一方主動發 Offer SDP，另一方則應答 AnswerSDP，最后雙方交換 ICE Candidate 從而完成通話鏈路的建立。但是在中國的網絡環境中，據一些統計數據顯示，至少1半的網絡是無法直接穿透打通，這種情況下只能借助TURN服務器中轉。

5. NAT知識補充

具體NAT打洞的知識在本課程不做進一步的講解，這里提供些鏈接給大家做參考：

P2P技術詳解(一)：NAT詳解——詳細原理、P2P簡介 https://www.cnblogs.com/mlgjb/p/8243646.htm

P2P技術詳解(二)：P2P中的NAT穿越(打洞)方案詳解 https://www.jianshu.com/p/9bfbcbee0abb

P2P技術詳解(三)：P2P技術之STUN、TURN、ICE詳解 https://www.jianshu.com/p/258e7d8be2ba

詳解P2P技術中的NAT穿透原理 https://www.jianshu.com/p/f71707892eb2

1.6 課程收獲

1. WebRTC工作原理
2. WebRTC API的使用
3. WebRTC 一對一視頻通話開發
4. AppRTC開源項目搭建方法
5. 常用的WebRTC開源方案
   1. from:https://zhuanlan.zhihu.com/p/93107411