WebRtc（網頁即時通信技術）知識點總結

前言

WebRTC，名稱源自網頁實時通訊（Web Real-Time Communication）的縮寫，簡而言之它是一個支持網頁瀏覽器進行實時語音對話或視頻對話的技術。而且還支持跨平臺：windows，linux，mac，android，iOS。

實現原理

P2P鏈接模式

通常咱們傳統的鏈接方式，都是以服務器爲中介的模式：

相似http協議：客戶端<——>服務端（固然這裏服務端返回的箭頭僅僅表明返回請求數據）。

進行即時通信時，進行文字、圖片、錄音等傳輸的時候：客戶端A——服務器——客戶端B。

 

而點對點的鏈接偏偏數據通道一旦造成，中間是不通過服務端的，數據直接從一個客戶端流向另外一個客戶端：

客戶端A——客戶端B ... 客戶端A——客戶端C ...（能夠無數個客戶端之間互聯）

這個過程就像音視頻通話的應用場景，咱們服務端確實是不必去獲取二者通訊的數據，並且這樣作有一個最大的一個優勢就是，大大的減輕了服務端的壓力。

而WebRTC就是這樣一個基於P2P的音視頻通訊技術。

客戶端A與B創建p2p鏈接的過程

1.A和B鏈接上服務端，創建一個TCP長鏈接（任意協議均可以，WebSocket/MQTT/Socket原生/XMPP），爲了省事，直接採用WebSocket，這樣一個信令通道就有了。

2.A從服務器得到ice server同時生成包含session description（SDP）的offer，發送給Socket服務端。

3.Socket服務端把A的offer和candidate轉發給B，B會保存下A這些信息。

4.而後B發送包含本身session description的answer(由於它收到的是offer，因此返回的是answer，可是內容都是SDP)和ice candidate給Socket服務端。

5.Socket服務端把B的answer和ice candidate給A，A保存下B的這些信息。

 

WebRTC的服務器

WebRTC至少有兩件事必需要用到服務器：

一、客戶端之間交換創建通訊的元數據（信令）必須經過服務器。

  咱們在A和B須要創建P2P鏈接的時候，至少要服務器來協調，來控制鏈接開始創建。而鏈接斷開的時候，也須要服務器來告知另外一端P2P鏈接已斷開

二、爲了穿越NAT和防火牆。

若是客戶端A想給客戶端B發送數據，則數據來到客戶端B所在的路由器下，會被NAT阻攔，這樣B就沒法收到A的數據了 。

 webrtc是經過 ICE 這套框架來處理複雜的網絡環境,
若是想啓用這個功能,你必須讓你的應用程序傳 服務器的URL：
  ICE試着找最好的路徑來讓客戶端創建鏈接,他會嘗試全部可能的選項,而後選擇最合適的方案,
  ICE首先嚐試P2P鏈接,若是失敗就會經過Turn服務器進行轉接。

 

信令的做用

用來控制通訊開啓或者關閉的鏈接控制消息

發生錯誤時用來彼此告知的消息

媒體流元數據，好比像解碼器、解碼器的配置、帶寬、媒體類型等等

用來創建安全鏈接的關鍵數據

外界所看到的的網絡上的數據，好比IP地址、端口等

信令的類型

Offer：創建點對點的鏈接時，發起端（A客戶端）須要發送的信令

Answer：創建點對點的鏈接時，被叫端（B客戶端）須要發送的信令

Bye：點對點的鏈接斷開時，發送的信令

 

會話描述協議（Session Description Protocal，簡稱SDP）

信令的主要內容的格式都遵循會話描述協議

 

1） 會話的名稱和目的
2） 會話存活時間
3） 包含在會話中的媒體信息，包括：
媒體類型(video, audio, etc)
傳輸協議(RTP/UDP/IP, H.320, etc)
媒體格式(H.261 video, MPEG video, etc)
多播或遠端（單播）地址和端口
4） 爲接收媒體而需的信息(addresses, ports, formats and so on)
5） 使用的帶寬信息
6） 可信賴的接洽信息

一個SDP的信令的內容大體上以下：

 

實時傳輸控制協議(Real-time ControlProtocol，RTCP)

RTP/RTCP協議是流媒體通訊的基石。RTP協議定義流媒體數據在互聯網上傳輸的數據包格式，而RTCP協議則負責可靠傳輸、流量控制和擁塞控制等服務質量保證。在WebRTC項目中，RTP/RTCP模塊做爲傳輸模塊的一部分，負責對發送端採集到的媒體數據進行進行封包，而後交給上層網絡模塊發送；在接收端RTP/RTCP模塊收到上層模塊的數據包後，進行解包操做，最後把負載發送到解碼模塊。所以，RTP/RTCP 模塊在WebRTC通訊中發揮很是重要的做用。

   Sdp協議內規定的視頻傳輸控制協議就是rtcp