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

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

想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等著你！

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

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

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

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

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

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

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

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

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

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

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

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

JavaScript是如何工作的：深入網絡層 + 如何優化性能和安全!

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

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

JavaScript是如何工作的：深入類和繼承內部原理+Babel和 TypeScript 之間轉換!

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

JavaScript是如何工作的： Shadow DOM 的內部結構+如何編寫獨立的組件！

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

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

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

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

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

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

WebRTC APIs

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

是否同意進行通信

彼此知道對方的地址

繞過安全和防火墻保護

實時傳輸所有多媒體通信

基于瀏覽器的點對點通信相關的最大挑戰之一是知道如何定位和建立與另一個 Web 瀏覽器的網絡套接字連接，以便雙向傳輸數據。

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

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

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

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

這就是 NAT (STUN) 的會話遍歷實用程序和圍繞 NAT (TURN)服務器使用中繼進行遍歷的原因。為了讓WebRTC 技術能夠正常工作，首先會向 STUN 服務器請求你的公開IP地址?？梢园阉胂蟪赡愕挠嬎銠C向遠程服務器進行查詢，該服務器詢問它接收查詢的IP地址，然后遠程服務器用它看到的 IP 地址進行響應。

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

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

上述網絡信息發現過程是較大的信令主題的一部分，其基于 WebRTC 情況下的 JavaScript 會話建立協議（JSEP）標準。 信令涉及網絡發現和 NAT 穿透，會話創建和管理，通信安全性，媒體能力元數據和協調以及錯誤處理。

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

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

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

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

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

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

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

每個對等點首先建立它所描述的面向公共的IP地址。然后動態創建信令數據“通道”來檢測對等點，并支持對等協商和會話建立。

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

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

這里假設在本文的實現中使用了“通道”。

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

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

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

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

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

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

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

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

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

RTCDataChannel — 表示一個在兩個節點之間的雙向的數據通道，每個數據通道都與RTCPeerConnection 相關聯。

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

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

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

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

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

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

請注意，constraints 參數是一個包含了video 和 audio兩個成員的MediaStreamConstraints 對象，用于說明請求的媒體類型。必須至少一個類型或者兩個同時可以被指定。如果瀏覽器無法找到指定的媒體類型或者無法滿足相對應的參數要求，那么返回的Promise對象就會處于rejected［失?。轄顟B，NotFoundError作為rejected［失?。莼卣{的參數。

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

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

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，規范將其用于用戶通知和權限管理的非常特定的需求。getUserMedia() 在打開任何媒體收集輸入(如網絡攝像頭或麥克風)之前，必須始終獲得用戶許可。瀏覽器可能提供每個域一次的權限特性，但它們必須至少在第一次請求，如果用戶選擇這樣做，則必須特別授予正在進行的權限。

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

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

下面是 WebRTC 架構圖，展示了 RTCPeerConnection 的作用:

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

丟包隱藏

回聲抵消

帶寬自適應

動態抖動緩沖

自動增益控制

噪聲抑制與抑制

圖像清洗

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

應用場景：

游戲

遠程桌面應用程序

實時文本聊天

Web文件傳輸

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

利用　RTCPeerConnection 會話。

*　多通道同步通道。

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

內置安全（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 需要服務器，無論多簡單，下面四步是必須的：

用戶通過交換名字之類的信息發現對方。

WebRTC 客戶端應用交換網絡信息。

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

WebRTC 客戶端穿透 NAT 網關和服務器。

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

用戶發現和通信

信令

NAT/防火墻穿透

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

可以說基于 STUN 和TURN協議的 ICE 框架，使得 RTCPeerConnection 處理 NAT 穿透和其他網絡難題成為可能。

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

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

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

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

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

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

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

WebRTC 采用類似 DTLS 和 SRTP 的安全協議。

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

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

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

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

原文：

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

代碼部署后可能存在的BUG沒法實時知道，事后為了解決這些BUG，花了大量的時間進行log 調試，這邊順便給大家推薦一個好用的BUG監控工具 Fundebug。

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