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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

JavaScript是如何工作的： Shadow DOM 的內(nèi)部結(jié)構(gòu)+如何編寫?yīng)毩⒌慕M件！

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

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

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

點(diǎn)對(duì)點(diǎn)通信 (Peer-To-Peer communication)

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

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

WebRTC APIs

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

是否同意進(jìn)行通信

彼此知道對(duì)方的地址

繞過安全和防火墻保護(hù)

實(shí)時(shí)傳輸所有多媒體通信

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

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

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

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

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

這就是 NAT (STUN) 的會(huì)話遍歷實(shí)用程序和圍繞 NAT (TURN)服務(wù)器使用中繼進(jìn)行遍歷的原因。為了讓W(xué)ebRTC 技術(shù)能夠正常工作，首先會(huì)向 STUN 服務(wù)器請(qǐng)求你的公開IP地址?？梢园阉胂蟪赡愕挠?jì)算機(jī)向遠(yuǎn)程服務(wù)器進(jìn)行查詢，該服務(wù)器詢問它接收查詢的IP地址，然后遠(yuǎn)程服務(wù)器用它看到的 IP 地址進(jìn)行響應(yīng)。

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

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

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

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

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

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

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

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

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

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

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

外部世界不知道或無法訪問這些“通道”，因此需要一個(gè)惟一的標(biāo)識(shí)符來訪問它們。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

丟包隱藏

回聲抵消

帶寬自適應(yīng)

動(dòng)態(tài)抖動(dòng)緩沖

自動(dòng)增益控制

噪聲抑制與抑制

圖像清洗

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

應(yīng)用場景：

游戲

遠(yuǎn)程桌面應(yīng)用程序

實(shí)時(shí)文本聊天

Web文件傳輸

API充分利用了 RTCPeerConnection 強(qiáng)大和靈活的點(diǎn)對(duì)點(diǎn)通信

利用　RTCPeerConnection 會(huì)話。

*　多通道同步通道。

可靠和不可靠的傳遞語義（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);
};

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

實(shí)際應(yīng)用中，WebRTC 需要服務(wù)器，無論多簡單，下面四步是必須的：

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

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

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

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

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

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

信令

NAT/防火墻穿透

中繼服務(wù)器，防止端到端的通信失敗

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

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

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

實(shí)時(shí)通信應(yīng)用或插件會(huì)在許多方面忽視了安全性：

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

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

惡意軟件或病毒可能入侵了正常的插件或應(yīng)用。

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

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

*　所有WebRTC組件都必須進(jìn)行加密，包括信令機(jī)制。

*　WebRTC　不是一個(gè)插件:它的組件運(yùn)行在瀏覽器沙盒中，而不是在一個(gè)多帶帶的進(jìn)程中，組件不需要多帶帶安裝，并且在瀏覽器更新時(shí)都會(huì)更新。

攝像頭和麥克風(fēng)的訪問必須經(jīng)過明確準(zhǔn)許，當(dāng)攝像頭和麥克風(fēng)運(yùn)行時(shí)，界面上會(huì)清楚的顯示出來。

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

原文：

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

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

你的點(diǎn)贊是我持續(xù)分享好東西的動(dòng)力，歡迎點(diǎn)贊！