摘要：為了使連接起作用，對等方必須獲取元數(shù)據(jù)的本地媒體條件例如，分辨率和編解碼器功能，并收集應用程序主機的可能網(wǎng)絡(luò)地址，用于來回傳遞這些關(guān)鍵信息的信令機制并未內(nèi)置到中。所有特定于多媒體的元數(shù)據(jù)都使用協(xié)議傳遞。

這是專門探索 JavaScript 及其所構(gòu)建的組件的系列文章的第 18 篇。

想閱讀更多優(yōu)質(zhì)文章請猛戳GitHub博客,一年百來篇優(yōu)質(zhì)文章等著你！

如果你錯過了前面的章節(jié)，可以在這里找到它們：

JavaScript 是如何工作的：引擎，運行時和調(diào)用堆棧的概述！

JavaScript 是如何工作的：深入V8引擎&編寫優(yōu)化代碼的5個技巧！

JavaScript 是如何工作的：內(nèi)存管理+如何處理4個常見的內(nèi)存泄漏！

JavaScript 是如何工作的：事件循環(huán)和異步編程的崛起+ 5種使用 async/await 更好地編碼方式！

JavaScript 是如何工作的：深入探索 websocket 和HTTP/2與SSE +如何選擇正確的路徑！

JavaScript 是如何工作的：與 WebAssembly比較 及其使用場景！

JavaScript 是如何工作的：Web Workers的構(gòu)建塊+ 5個使用他們的場景!

JavaScript 是如何工作的：Service Worker 的生命周期及使用場景!

JavaScript 是如何工作的：Web 推送通知的機制!

JavaScript是如何工作的：使用 MutationObserver 跟蹤 DOM 的變化!

JavaScript是如何工作的：渲染引擎和優(yōu)化其性能的技巧!

JavaScript是如何工作的：深入網(wǎng)絡(luò)層 + 如何優(yōu)化性能和安全!

JavaScript是如何工作的：CSS 和 JS 動畫底層原理及如何優(yōu)化它們的性能！

JavaScript的如何工作的：解析、抽象語法樹（AST）+ 提升編譯速度5個技巧!

JavaScript是如何工作的：深入類和繼承內(nèi)部原理+Babel和 TypeScript 之間轉(zhuǎn)換!

JavaScript是如何工作的：存儲引擎+如何選擇合適的存儲API!

JavaScript是如何工作的： Shadow DOM 的內(nèi)部結(jié)構(gòu)+如何編寫獨立的組件！

WebRTC，名稱源自網(wǎng)頁即時通信（英語：Web Real-Time Communication）的縮寫，是一個支持網(wǎng)頁瀏覽器進行實時語音對話或視頻對話的API。

在此之前，P2P技術(shù)(如桌面聊天應用程序)可以做一些網(wǎng)絡(luò)做不到的事情，WebRTC 填補了 Web 這一關(guān)鍵空白點。

WebRTC 是一項實時通信技術(shù)，它允許瀏覽器或者 app 之間可以不借助中間媒介的情況下，建立瀏覽器之間點對點的連接，實現(xiàn)視頻流和音頻流或者其他任意數(shù)據(jù)的傳輸。本文中討論這一點,還支討論以下主題，以便讓你全面了解 WebRTC 的內(nèi)部結(jié)構(gòu):

點對點通信 (Peer-To-Peer communication)

防火墻和NAT穿透 (Firewalls and NAT Traversal)

信令、會話和協(xié)議 (Signaling, Sessions, and Protocols)

WebRTC APIs

為了通過 Web 瀏覽器與另一個對等點進行通信，每個 Web 瀏覽器必須經(jīng)過以下步驟:

是否同意進行通信

彼此知道對方的地址

繞過安全和防火墻保護

實時傳輸所有多媒體通信

基于瀏覽器的點對點通信相關(guān)的最大挑戰(zhàn)之一是知道如何定位和建立與另一個 Web 瀏覽器的網(wǎng)絡(luò)套接字連接，以便雙向傳輸數(shù)據(jù)。

當 Web 應用程序需要一些數(shù)據(jù)或資源時，它從某個服務器獲取數(shù)據(jù)或資源，僅此而已。但是，如果想創(chuàng)建點對點視頻聊天，通過直接連接到其他人的瀏覽器——你不知道對方地址，因為另一個瀏覽器不是已知的 Web服務器。因此，為了建立點對點連接，還需要做更多的工作。

NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）是1994年提出的。當在專用網(wǎng)內(nèi)部的一些主機本來已經(jīng)分配到了本地 IP 地址 (即僅在本專用網(wǎng)內(nèi)使用的專用地址)，但現(xiàn)在又想和因特網(wǎng)上的主機通信（并不需要加密）時，可使用 NAT 方法。

NAT（Network Address Translation，網(wǎng)絡(luò)地址轉(zhuǎn)換）簡單來說就是為了解決 IPV4 下的IP地址匱乏而出現(xiàn)的一種技術(shù)。
舉例，就是通常我們處在一個路由器之下，而路由器分配給我們的地址通常為191.168.0.21 、191.168.0.22如果有n個設(shè)備，可能分配到192.168.0.n，而這個IP地址顯然只是一個內(nèi)網(wǎng)的IP地址，這樣一個路由器的公網(wǎng)地址對應了 n 個內(nèi)網(wǎng)的地址，通過這種使用少量的公有 IP 地址代表較多的私有 IP 地址的方式，將有助于減緩可用的IP地址空間的枯竭。

NAT技術(shù)會保護內(nèi)網(wǎng)地址的安全性，所以這就會引發(fā)個問題，就是當我采用P2P之中連接方式的時候，NAT會阻止外網(wǎng)地址的訪問，這時我們就得采用 NAT 穿透了。

這就是 NAT (STUN) 的會話遍歷實用程序和圍繞 NAT (TURN)服務器使用中繼進行遍歷的原因。為了讓WebRTC 技術(shù)能夠正常工作，首先會向 STUN 服務器請求你的公開IP地址。可以把它想象成你的計算機向遠程服務器進行查詢，該服務器詢問它接收查詢的IP地址，然后遠程服務器用它看到的 IP 地址進行響應。

假設(shè)這個過程有效，并且你接收到你面向公眾的 IP 地址和端口，那么你就能夠告訴其他對等方如何直接連接到你。這些對等點還可以使用 STUN 或 TURN 服務器做同樣的事情，并可以告訴你用什么地址與它們聯(lián)系。

STUN（Simple Traversal of UDP over NATs，NAT 的UDP簡單穿越）是一種網(wǎng)絡(luò)協(xié)議，它允許位于NAT（或多重NAT）后的客戶端找出自己的公網(wǎng)地址，查出自己位于哪種類型的NAT之后以及NAT為某一個本地端口所綁定的Internet端端口。這些信息被用來在兩個同時處于NAT 路由器之后的主機之間建立UDP通信。該協(xié)議由RFC 3489定義。目前RFC 3489協(xié)議已被RFC 5389協(xié)議所取代，新的協(xié)議中，將STUN定義為一個協(xié)助穿越NAT的工具，并不獨立提供穿越的解決方案。它還有升級版本RFC 7350，目前正在完善中。
TURN的全稱為Traversal Using Relay NAT，即通過Relay方式穿透 NAT，TURN 應用模型通過分配TURNServer的地址和端口作為客戶端對外的接受地址和端口，即私網(wǎng)用戶發(fā)出的報文都要經(jīng)過TURNServer進行Relay轉(zhuǎn)發(fā)，這種方式應用模型除了具有STUN方式的優(yōu)點外，還解決了STUN應用無法穿透對稱NAT（SymmetricNAT）以及類似的Firewall設(shè)備的缺陷

上述網(wǎng)絡(luò)信息發(fā)現(xiàn)過程是較大的信令主題的一部分，其基于 WebRTC 情況下的 JavaScript 會話建立協(xié)議（JSEP）標準。 信令涉及網(wǎng)絡(luò)發(fā)現(xiàn)和 NAT 穿透，會話創(chuàng)建和管理，通信安全性，媒體能力元數(shù)據(jù)和協(xié)調(diào)以及錯誤處理。

為了使連接起作用，對等方必須獲取元數(shù)據(jù)的本地媒體條件（例如，分辨率和編解碼器功能），并收集應用程序主機的可能網(wǎng)絡(luò)地址，用于來回傳遞這些關(guān)鍵信息的信令機制并未內(nèi)置到 WebRTC API 中。

信令不是由 WebRTC 標準指定的，也不是由其 Api 實現(xiàn)的，這樣可以保持技術(shù)和協(xié)議的靈活性。信令和處理它的服務器由 WebRTC 應用程序開發(fā)人員處理。

假設(shè) WebRTC 瀏覽器的應用程序能夠使用 STUN 確定其面向公共的IP地址，下一步是實際地與對等方協(xié)商并建立網(wǎng)絡(luò)會話連接。

初始會話協(xié)商和建立使用專門用于多媒體通信的信令/通信協(xié)議進行，該協(xié)議還負責管理會話的管理和終止規(guī)則。

其中一個協(xié)議是會話啟動協(xié)議(稱為SIP)。請注意，由于WebRTC信令的靈活性，SIP不是唯一可以使用的信令協(xié)議。所選的信令協(xié)議還必須與一個稱為會話描述協(xié)議(SDP)的應用層協(xié)議一起工作，該協(xié)議在WebRTC的情況下使用。所有特定于多媒體的元數(shù)據(jù)都使用SDP協(xié)議傳遞。

嘗試與另一個對等體通信的任何對等體（即，WebRTC-利用應用程序）生成一組交互式連接建立協(xié)議（ICE）候選者。 候選者代表要使用的IP地址，端口和傳輸協(xié)議的給定組合。 請注意，單臺計算機可能具有多個網(wǎng)絡(luò)接口（無線，有線等），因此可以為每個接口分配多個IP地址。

這是一個來自MDN的圖表，描述了這種交換。

每個對等點首先建立它所描述的面向公共的IP地址。然后動態(tài)創(chuàng)建信令數(shù)據(jù)“通道”來檢測對等點，并支持對等協(xié)商和會話建立。

外部世界不知道或無法訪問這些“通道”，因此需要一個惟一的標識符來訪問它們。

請注意，由 于WebRTC 的靈活性，以及該標準沒有指定信令流程這一事實，考慮到所使用的技術(shù)，“通道”的概念和使用可能略有不同，事實上，有些協(xié)議不需要“通道”機制進行通信。

這里假設(shè)在本文的實現(xiàn)中使用了“通道”。

一旦兩個或更多個對等體連接到相同的“信道”，則對等點能夠通信并協(xié)商會話信息，此過程有點類似于發(fā)布/訂閱模式。 基本上，發(fā)起對等體使用諸如會話發(fā)起協(xié)議 SIP 和 SDP 之類的信令協(xié)議發(fā)送“offer(請求)”，發(fā)起者等待從連接到給定“信道”的任何接收器接收“answer(應答)”。

一旦收到答復，就會發(fā)生以下過程，確定并協(xié)商每個對等點收集的最佳交互連接建立協(xié)議（ICE）候選者。 一旦選擇了最佳 ICE 候選者，基本上所有所需的元數(shù)據(jù)，網(wǎng)絡(luò)路由（IP地址和端口）以及用于為每個對等體通信的媒體信息達成一致。 然后，完全建立并激活對等點之間的網(wǎng)絡(luò)套接字會話。 接下來，由每個對等體創(chuàng)建本地數(shù)據(jù)流和數(shù)據(jù)信道端點，并且最終使用所采用的任何雙向通信技術(shù)以雙向方式傳輸多媒體數(shù)據(jù)。

如果商定最佳 ICE 候選方案的過程失敗(有時確實由于使用了防火墻和 NAT 技術(shù)而發(fā)生這種情況)，那么可以使用 TURN 服務器作為中繼。這個過程基本上使用一個充當中介的服務器，它在對等點之間中繼任何傳輸?shù)臄?shù)據(jù)。請注意，這不是真正的對等通信，在這種通信中，對等點直接雙向地向彼此傳輸數(shù)據(jù)。

當使用 TURN 回退進行通信時，每個對等方不再需要知道如何相互聯(lián)系和傳輸數(shù)據(jù)。 相反，它們需要知道公共 TURN 服務器在通信會話期間發(fā)送和接收實時多媒體數(shù)據(jù)。

重要的是要明白，這絕對是一個失敗的安全措施和最后的手段。TURN 服務器需要非常健壯，具有廣泛的帶寬和處理能力，并處理潛在的大量數(shù)據(jù)。因此，使用 TURN 服務器顯然會帶來額外的成本和復雜性。

SIP（Session Initiation Protocol，會話初始協(xié)議）是由IETF（Internet Engineering Task
Force，因特網(wǎng)工程任務組）制定的多媒體通信協(xié)議。它是一個基于文本的應用層控制協(xié)議，用于創(chuàng)建、修改和釋放一個或多個參與者的會話。廣泛應用于CS（Circuit
Switched，電路交換）、NGN（Next Generation Network，下一代網(wǎng)絡(luò)）以及IMS（IP Multimedia Subsystem，IP多媒體子系統(tǒng)）的網(wǎng)絡(luò)中，可以支持并應用于語音、視頻、數(shù)據(jù)等多媒體業(yè)務，同時也可以應用于Presence（呈現(xiàn)）、Instant Message（即時消息）等特色業(yè)務。可以說，有IP網(wǎng)絡(luò)的地方就有SIP協(xié)議的存在。

SDP 完全是一種會話描述格式（對應的RFC2327） ― 它不屬于傳輸協(xié)議 ― 它只使用不同的適當?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議（SAP）、會話初始協(xié)議（SIP）、實時流協(xié)議（RTSP）、MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議（HTTP）。SDP協(xié)議是也是基于文本的協(xié)議，這樣就能保證協(xié)議的可擴展性比較強，這樣就使其具有廣泛的應用范圍。SDP 不支持會話內(nèi)容或媒體編碼的協(xié)商，所以在流媒體中只用來描述媒體信息。媒體協(xié)商這一塊要用RTSP來實現(xiàn)．

MediaStream —? MediaStream用來表示一個媒體數(shù)據(jù)流，允許你訪問輸入設(shè)備，如麥克風和 Web攝像機,該 API 允許從其中任意一個獲取媒體流。

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

RTCDataChannel — 表示一個在兩個節(jié)點之間的雙向的數(shù)據(jù)通道，每個數(shù)據(jù)通道都與RTCPeerConnection 相關(guān)聯(lián)。

MediaStream API 代表媒體流的同步。比如，從攝像頭和麥克風獲取的媒體流具有同步視頻和音頻軌道。

MediaDevices.getUserMedia() 會提示用戶給予使用媒體輸入的許可，媒體輸入會產(chǎn)生一個MediaStream，里面包含了請求的媒體類型的軌道。此流可以包含一個視頻軌道（來自硬件或者虛擬視頻源，比如相機、視頻采集設(shè)備和屏幕共享服務等等）、一個音頻軌道（同樣來自硬件或虛擬音頻源，比如麥克風、A/D轉(zhuǎn)換器等等），也可能是其它軌道類型。

它返回一個 Promise 對象，成功后會 resolve 回調(diào)一個 MediaStream 對象。若用戶拒絕了使用權(quán)限，或者需要的媒體源不可用，promise 會 reject 回調(diào)一個 PermissionDeniedError 或者 NotFoundError 。

可以通過 navigator 對象訪問 MediaDevice 單例，如下所示：

通常你可以使用 navigator.mediaDevices 來獲取 MediaDevices ，例如：

 navigator.mediaDevices.getUserMedia(constraints)
.then(function(stream) {
  /* 使用這個stream stream */
})
.catch(function(err) {
  /* 處理error */
});

請注意，constraints 參數(shù)是一個包含了video 和 audio兩個成員的MediaStreamConstraints 對象，用于說明請求的媒體類型。必須至少一個類型或者兩個同時可以被指定。如果瀏覽器無法找到指定的媒體類型或者無法滿足相對應的參數(shù)要求，那么返回的Promise對象就會處于rejected［失敗］狀態(tài)，NotFoundError作為rejected［失敗］回調(diào)的參數(shù)。

從版本25開始，基于 Chromium 的瀏覽器允許將來自 getUserMedia() 的音頻數(shù)據(jù)傳遞給音頻或視頻元素（但請注意，默認情況下，媒體元素將被靜音）。

getUserMedia 還可以用作 Web 音頻 API 的輸入節(jié)點:

function gotStream(stream) {
    window.AudioContext = window.AudioContext || window.webkitAudioContext;
    var audioContext = new AudioContext();
    // Create an AudioNode from the stream
    var mediaStreamSource = audioContext.createMediaStreamSource(stream);
    // Connect it to destination to hear yourself
    // or any other node for processing!
    mediaStreamSource.connect(audioContext.destination);
}

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

getUserMedia() 是一個可能涉及重大隱私問題的 API，規(guī)范將其用于用戶通知和權(quán)限管理的非常特定的需求。getUserMedia() 在打開任何媒體收集輸入(如網(wǎng)絡(luò)攝像頭或麥克風)之前，必須始終獲得用戶許可。瀏覽器可能提供每個域一次的權(quán)限特性，但它們必須至少在第一次請求，如果用戶選擇這樣做，則必須特別授予正在進行的權(quán)限。

同樣重要的是關(guān)于通知的規(guī)則。瀏覽器需要顯示一個指示器，該指示器顯示正在使用的攝像機或麥克風，超出可能存在的任何硬件指示器。它們還必須顯示一個指示符，表明已授予使用設(shè)備進行輸入的權(quán)限，即使該設(shè)備目前沒有進行主動記錄

RTCPeerConnection 它代表了本地端機器與遠端機器的一條連接。該接口提供了創(chuàng)建，保持，監(jiān)控，關(guān)閉連接的方法的實現(xiàn)。的作用是在瀏覽器之間建立數(shù)據(jù)的“點對點”（peer to peer）通信.

下面是 WebRTC 架構(gòu)圖，展示了 RTCPeerConnection 的作用:

從 JavaScript 的角度來看，從這個圖中要理解的主要事情是 RTCPeerConnection 為 Web 開發(fā)人員提供了一個抽象，從復雜的內(nèi)部結(jié)構(gòu)中抽象出來。使用WebRTC的編解碼器和協(xié)議做了大量的工作，方便了開發(fā)者，使實時通信成為可能，甚至在不可靠的網(wǎng)絡(luò)：

丟包隱藏

回聲抵消

帶寬自適應

動態(tài)抖動緩沖

自動增益控制

噪聲抑制與抑制

圖像清洗

除了視頻和音頻，webRTC 還可以傳輸其他數(shù)據(jù)，RTCDataChannel API支持對等交換任意數(shù)據(jù)。

應用場景：

游戲

遠程桌面應用程序

實時文本聊天

Web文件傳輸

API充分利用了 RTCPeerConnection 強大和靈活的點對點通信

利用　RTCPeerConnection 會話。

*　多通道同步通道。

可靠和不可靠的傳遞語義（delivery semantics）。

內(nèi)置安全（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);
};

通信直接在瀏覽器之間進行，因此即使需要中繼（TURN）服務器，RTCDataChannel 也可以比 WebSocket快得多。

實際應用中，WebRTC 需要服務器，無論多簡單，下面四步是必須的：

用戶通過交換名字之類的信息發(fā)現(xiàn)對方。

WebRTC 客戶端應用交換網(wǎng)絡(luò)信息。

客戶端交換媒體信息包括視頻格式和分辨率。

WebRTC 客戶端穿透 NAT 網(wǎng)關(guān)和服務器。

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

用戶發(fā)現(xiàn)和通信

信令

NAT/防火墻穿透

中繼服務器，防止端到端的通信失敗

可以說基于 STUN 和TURN協(xié)議的 ICE 框架，使得 RTCPeerConnection 處理 NAT 穿透和其他網(wǎng)絡(luò)難題成為可能。

?ICE 框架用于端到端的連接，比如說兩個視頻聊天客戶端。起初，ICE 嘗試通過 UDP 直接連接兩端，這樣可以保證低延遲。在這個過程中，STUN 服務器有一個簡單的任務：使 NAT 后邊的端能找到它的公網(wǎng)地址和端口（谷歌有多個STUN服務器，其中一個用在了apprtc.appspot.com例子）。

?如果 UDP 傳輸失敗，ICE 會嘗試 TCP：首先是 HTTP，然后才會選擇 HTTPS。如果直接連接失敗，通常因為企業(yè)的 NAT 穿透和防火墻，此時 ICE 使用中繼（Relay）服務器。換句話說，ICE 首先使用STUN 和 UDP 直接連接兩端，失敗之后返回中繼服務器。‘finding cadidates’ 就是尋找網(wǎng)絡(luò)接口和端口的過程。

實時通信應用或插件會在許多方面忽視了安全性：

瀏覽器之間、瀏覽器與服務器之間的音視頻或其他數(shù)據(jù)沒有加密。

應用在用戶沒有察覺的情況下錄制和分發(fā)音視頻。

惡意軟件或病毒可能入侵了正常的插件或應用。

WebRTC 的許多特性可以避免這些問題：

WebRTC 采用類似 DTLS 和 SRTP 的安全協(xié)議。

*　所有WebRTC組件都必須進行加密，包括信令機制。

*　WebRTC　不是一個插件:它的組件運行在瀏覽器沙盒中，而不是在一個多帶帶的進程中，組件不需要多帶帶安裝，并且在瀏覽器更新時都會更新。

攝像頭和麥克風的訪問必須經(jīng)過明確準許，當攝像頭和麥克風運行時，界面上會清楚的顯示出來。

WebRTC是一種非常有趣和強大的技術(shù)，用于在瀏覽器之間進行某種形式的實時流。

原文：

https://blog.sessionstack.com...

代碼部署后可能存在的BUG沒法實時知道，事后為了解決這些BUG，花了大量的時間進行l(wèi)og 調(diào)試，這邊順便給大家推薦一個好用的BUG監(jiān)控工具 Fundebug。

你的點贊是我持續(xù)分享好東西的動力，歡迎點贊！