摘要：本質上允許網頁程序創建點對點通信，我們將會在隨后的章節中進行介紹。信令涉及網絡檢索和穿透，會話創建及管理，通信安全，媒體功能元數據和調制及錯誤處理。這樣就會完全建立及激活節點間的網絡套接字會話。

原文請查閱這里，略有刪減，本文采用知識共享署名 4.0 國際許可協議共享，BY Troland。

這是 JavaScript 工作原理第十八章。

何為 WebRTC ？首先，字面上已經給出了關于這一技術的大量信息，RTC 即為實時通信技術。

WebRTC 填補了網頁開發平臺中的一個重要空白。在以往，只有諸如桌面聊天程序這樣的 P2P 技術才能夠實現實時通訊而網頁不行。但是 WebRTC 的出現改變了這一狀況。

WebRTC 本質上允許網頁程序創建點對點通信，我們將會在隨后的章節中進行介紹。我們將討論如下主題，以便向開發者全面介紹 WebRTC 的內部構造：

點對點通信

防火墻和 NAT 穿透

信令，會話及協議

WebRTC 接口

每個用戶的網頁瀏覽器必須按照如下步驟以實現通過網頁瀏覽器進行的點對點通信：

同意開始進行通信

知道如何定位另一個點

繞過安全和防火墻限制

實時傳輸所有多媒體通信信息

眾所周知，基于瀏覽器的點對點通信的最大挑戰之一即如何定位和建立與另一個網頁瀏覽器進行通信的網絡套接字以進行雙向數據傳輸。我們將會克服建立與此種網絡連接相關的困難。

每當網頁程序需要數據或者靜態資源，會直接從相應的服務器獲取，僅此而已。但是，如果若想要通過直接連接用戶的瀏覽器來建立點對點的視頻聊天就不可能，因為其它瀏覽器并不是一個已知的網頁服務器，所以用戶不知道需要建立視頻聊天的 IP 地址。所以，需要更多的技術以建立 p2p 連接。

一般電腦是不會被分配一個靜態公共 IP 地址的。原因是電腦是位于防火墻和網絡訪問轉換設備(NAT) 后面的。

一個 NAT 設備會把防火墻內的私有 IP 地址轉換為一個公共 IP 地址。對于安全和有限的可用公共 IP 地址來說，NAT 設備是必須的。這也是為什么開發者的網頁程序不能夠把當前設備看成擁有一個靜態公共 IP 地址的原因。

讓我們來了解下 NAT 設備的工作原理。當開發者處于一個企業網中然后加入了 WIFI，那么電腦將會被分配一個只存在于 NAT 后面的 IP 地址。假設是 172.0.23.4。然而，對于外部而言，用戶的 IP 地址會是類似 164.53.27.98 這樣的。那么，外部會把所有請求看作來自 164.53.27.98 而 NAT 設備會保證來自于目標用戶電腦的請求的響應數據返回到相應的內部 172.0.23.4 IP 地址的電腦。這得歸功于映射表。注意到除了 IP 地址，網絡通信還需要通信端口。

隨著 NAT 設備參與其中，瀏覽器需要知道進行通信的目標瀏覽器對應的機器 IP 地址。

這個就需要用到 NAT 會話穿透程序(STUN)和 NAT 穿透中繼轉發服務器。為使用 WebRTC 技術，開發者需要請求 STUN 服務器以獲得其公共 IP 地址。這就好像你的電腦請求遠程服務器，詢問遠程服務器發起查詢的客戶端 IP 地址。遠程服務器會返回對應的客戶端 IP 地址。

假設這一過程進展順利，那么開發者將會獲得一個公共 IP 地址和端口，這樣就可以告知其它點如何直接和你進行通信。同理，這些點也可以請求 STUN 或 TURN 服務器以獲得公共 IP 地址然后告知其通信地址。

前述網絡信息檢索過程只是更大的信令話題的一部分，在 WebRTC 中，它是基于 JavaScript 會話構建協議(JSEP)標準的。信令涉及網絡檢索和 NAT 穿透，會話創建及管理，通信安全，媒體功能元數據和調制及錯誤處理。

為了讓通信順利進行，節點必須確定元數據本地媒體環境(比如分辨率和編碼能力等)和收集可用的程序主機網絡地址。WebRTC 接口里面沒有集成反復傳輸這一重要信息的信令機制。

WebRTC 標準并沒有規定信令且沒有在接口中實現是為了能夠更加靈活地使用其它技術和協議。信令和處理信令的服務器是由 WebRTC 程序開發者控制的。

假設開發者基于瀏覽器的 WebRTC 程序使用之前所說的 STUN 服務器獲取其公共 IP 地址，那么，下一步即和其它點進行協商和建立網絡會話連接。

使用任意一個專門應用于多媒體通信的信令/通信協議初始化會話協商和通信連接。該協議負責管理會話和中斷的規則。

會話初始協議(SIP) 是協議之一。多虧了 WebRTC 信令的靈活性，SIP 并不是唯一可供使用的信令協議。所選的通信協議必須和被稱為會話描述協議(SDP)的應用層協議兼容，SDP 被應用于 WebRTC。所有的多媒體指定元數據都是通過 SDP 協議進行數據傳輸的。

任意試圖和其它點進行通信的點(比如 WebRTC 程序)都會生成交互式連接建立協議(ICE)候選集。候選集表示一個可供使用的 IP 地址，端口及傳輸協議的集合。注意，一臺電腦可以擁有多個網絡接口(有線和無線等)，因此可以擁有多個 IP 地址，每個接口分配一個 IP 地址。

以下為 MDN 上描繪這一通信交換的圖示：

每個節點首先獲取之前所說的公共 IP 地址。之后動態創建「信道」信令數據來檢索其它節點并且支持點對點協商及創建會話。

這些「信道」不能夠被外部檢索和訪問到且只能通過唯一標識符來訪問。

需要注意的是由于 WebRTC 的靈活性且事實上信令創建程序并沒有在標準中指定，使用的技術不同，「信道」的概念和使用會有些許異同。事實上，一些協議并不要求「通道」機制來進行通信。

本篇文章將會假設存在「信道」。

一旦兩個或者更多的點連接到相同的「信道」上，節點就可以進行通信和協商會話信息。這一過程和發布/訂閱模式有些許類似。大體上，初始點使用諸如會話初始協議(SIP)和 SDP 的信號協議發出一個「offer」的包。發起者等待連接到指定「通道」的接收者的「answer」應答。

一旦接收到應答，會開始選擇和協商由各個節點生成的最優交互連接建立協調候選(ICE)集。一旦選定了最優 ICE 候選集，特別是確認了所有節點通信所要求的元數據，網絡路由(IP 地址和端口)及媒體信息。這樣就會完全建立及激活節點間的網絡套接字會話。緊接著，每個節點創建本地數據流和數據通道端點，然后，最后使用任意雙向通信技術來傳輸多媒體數據。

如果確認最優 ICE 候選的過程失敗了，這樣的情況經常發生于使用的防火墻和 NAT 技術，后備使用 TURN 服務器作為中繼轉發服務器。這一過程主要是使用一臺服務器作為中間媒介，然后在節點間轉發傳輸數據。請注意這不是真正的點對點通信，因為真正的點對點通信是節點之間直接進行雙向數據傳輸。

每當使用 TURN 作為后備通信的時候，每個節點將不必知道如何連接并傳輸數據給對方節點。相反，節點只需要知道在會話通信期間實時發送和接收多媒體數據的公共 TURN 服務器。

需要重點理解的是這僅僅只是一個失敗保護和最后手段。TURN 服務器需要相當健壯，擁有昂貴帶寬和強大的處理能力及處理潛在的大量數據。因此，使用 TURN 服務器會明顯增加額外的開銷和復雜度。

WebRTC 中包含三種主要接口：

媒體捕捉和流－允許開發者訪問諸如麥克風和網絡攝像機的輸入設備。該接口允許開發者獲取麥克風或者網絡攝像機媒體流。

RTCPeerConnection－開發者實時傳輸獲取的視頻和音頻流到另一個 WebRTC 端點。開發者使用這些接口連接本地機器和遠程節點。該接口提供創建到遠程節點的連接，維護和監視連接及關閉不再活躍的連接的方法。

RTCDataChannel－該接口允許開發者傳輸任意數據。每個數據通道都和 RTCPeerConnection 有關。

我們將分別介紹這三類接口。

媒體捕捉和流接口經常被稱為媒體流接口或者流接口，該接口支持音頻或者視頻數據流數據，處理音視頻流的方法，與數據類型相關的約束，異步獲取數據時的成功和錯誤回調及 API 調用過程中觸發的事件。

MediaDevices 的 getUserMedia() 方法提示用戶授權允許使用媒體輸入設備，創建一個包含指定媒體類型軌道的媒體流。該媒體流，可包括諸如視頻軌道(由諸如攝像機，視頻錄制設備，屏幕共享服務等硬件或者虛擬視頻源所創建)，音頻軌道(與視頻類似，由諸如麥克風，A/D 轉換器等的物理或者虛擬音頻源所創建)且有可能是其它類型軌道。

該方法返回一個 Promise 并解析為 MediaStream 對象。當用戶拒絕授權或者沒有可用的匹配媒體資源，promise 會分別返回 PermissionDeniedError 或者 NotFoundError。

可以通過 navigator 對象訪問 MediaDevice 單例：

navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
 /* 使用流 */
})
.catch(function(err) {
 /* 處理錯誤 */
});

注意這里需要傳入 constraints 對象以指定返回的媒體流類型。開發者可以進行各種配置，包括使用的攝像頭(前置或后置)，幀頻率，分辨率等等。

從版本 25 起，基于 Chromium 的瀏覽器已經允許通過 getUserMedia() 獲取的音頻數據賦值給音頻或者視頻元素(但需要注意的是媒體元素默認值為空)。

可以把 getUserMedia作為網頁音頻接口的輸入節點：

function gotStream(stream) {
    window.AudioContext = window.AudioContext || window.webkitAudioContext;
    var audioContext = new AudioContext();
    // 從流創建音頻節點
    var mediaStreamSource = audioContext.createMediaStreamSource(stream);
    // 把它和目標節點進行連接讓自己傾聽或由其它節點處理
    mediaStreamSource.connect(audioContext.destination);
}

navigator.getUserMedia({audio:true}, gotStream);

由于該接口可能導致明顯的隱私問題，規范在通知用戶和權限管理方面對 getUserMedia() 方法有非常明確的規定。在打開諸如用戶網頁攝像頭或者麥克風的媒體輸入設備的時候getUserMedia() 必須總是獲取用戶的授權。

瀏覽器可能提供每個域名授權一次的權限功能，但必須至少第一次詢問授權，然后用戶必須指定授權的權限。

通知中的規則同樣重要。除了可能存在其它硬件指示器，瀏覽器還必須顯示一個窗口顯示使用中的攝像頭或者麥克風。即使當時設備沒有進行錄制，瀏覽器必須顯示一個提示窗口提示已授權使用哪個設備作為輸入設備。

RTCPeerConnection 表示一個本地電腦和遠程節點之間的 WebRTC 連接。它提供了連接遠程節點，維護和監視連接及關閉不再活躍的連接的方法。

如下為一張 WebRTC 圖表展示 了 RTCPeerConnection 的角色：

從 JavaScript 方面看 ，圖中需要理解的主要方面即 RTCPeerConnection 把復雜的底層內部結構的復雜度抽象為一個接口給開發者。WebRTC 所使用的編碼和協議為即使在不穩定的網絡環境下仍然能夠創建一個盡可能實時的通信而做了大量的工作：

包丟失恢復

回音消除

網絡自適應

視頻抖動緩沖

自動增益控制

噪聲減少和壓制

圖像「清潔」

不僅僅是音視頻，WebRTC 還支持實時傳輸其它類型的數據。

RTCDataChannel 接口允許點對點交換任意數據。

該接口有許多用途，包括：

游戲

實時文本聊天

文件傳輸

分布式網絡

該接口有幾項功能，充分利用 RTCPeerConnection 并創建強大和靈活的點對點通信：

使用RTCPeerConnection 創建會話

包含優先級的多個并發通道

可靠和不可靠消息傳遞語義

內置安全(DTLS)和消息堵塞控制

語法和已有的 WebSocket 類似，包含有 send() 方法和 message 事件：

var peerConnection = new webkitRTCPeerConnection(servers,
    {optional: [{RtpDataChannels: true}]}
);

peerConnection.ondatachannel = function(event) {
    receiveChannel = event.channel;
    receiveChannel.onmessage = function(event){
        document.querySelector("#receiver").innerHTML = event.data;
    };
};

sendChannel = peerConnection.createDataChannel("sendDataChannel", {reliable: false});

document.querySelector("button#send").onclick = function (){
    var data = document.querySelector("textarea#send").value;
    sendChannel.send(data);
};

由于通信是直接在瀏覽器之間進行的，所以 RTCDataChannel 會比 WebSocket 更快即使是使用中繼轉發服務器(TURN)。

在實際應用中，WebRTC 需要服務器，但這很簡單，因此會發生如下步驟：

用戶各自檢索節點然后交換諸如名字的詳情。

WebRTC 客戶端程序(點)交換網絡信息。

點交換諸如視頻格式和分辨率的媒體信息。

WebRTC 客戶端程序穿透 NAT 網關 和防火墻。

換句話說，WebRTC 需要四種類型的服務端功能：

用戶檢索和通信

發信號

NAT/防火墻穿透

中繼轉發服務器以防點對點通信失敗

ICE 使用 STUN 協議及其擴展 TURN 協議來創建 RTCPeerConnection 連接來處理 NAT 穿透和其它網絡變化。

如前所述，ICE 是用來連接諸如兩個視頻聊天客戶的節點協議。一開始，ICE 會試圖使用最低的可能的網絡延遲即使用 UDP 來直接連接節點。在這一過程中，STUN 服務器只有一個任務:讓位于 NAT 之后的節點能夠找到其公共地址和端口。開發者可以查看一下可用的 STUN 服務器(Google 也有一堆) 名單。

若 UDP 失敗，ICE 嘗試 TCP，先 HTTP 后 HTTPS。如果直接連接失敗-特殊情況下，由于企業 NAT 穿透和防火墻-ICE 使用中間(轉發) TURN 服務器。換句話說，ICE 首先通過 UDP 使用 STUN 服務器來直接連接節點，若失敗則后備使用 TURN 中繼轉發服務器。「檢索連接候選者」指的是檢索網絡接口和端口的過程。

實時通信程序或者插件可能造成幾種安全問題。例如：

未加密媒體或者數據有可能會在瀏覽器之間或者瀏覽器和服務器之間被竊取。

程序有可能在未經用戶授權同意的情況下記錄和分發音視頻。

可疑軟件或者病毒有可能會隨著表面上無害的插件或者程序一起安裝。

WebRTC 有幾種方法用來解決如上問題：

WebRTC 實現使用諸如 DTLS 和 SRTP 的安全協議。

包括信令機制在內的所有 WebRTC 組件都是強制加密的。

WebRTC 不是一個插件：其組件運行于瀏覽器沙箱之中且不是在一個多帶帶的進程之中，不需要多帶帶安裝組件且隨著瀏覽器升級而更新。

攝像頭和麥克風必須顯式授權且當攝像頭或者麥克風運行時，必須在用戶窗口中有所顯示。

對于需要實現一些瀏覽器之間實時通信流功能的產品而言，WebRTC 是一個令人難以置信和強大的技術。

參考資料：

https://www.html5rocks.com/en...

https://www.innoarchitech.com...