本文引用自Hussein Nasser的兩個(gè)視頻分享，原文內(nèi)容由盧冰聰翻譯整理，即時(shí)通訊網(wǎng)收錄時(shí)有大量修訂和重新排版。

1、內(nèi)容概述

本文是專為學(xué)習(xí)開源實(shí)時(shí)音視頻工程WebRTC的入門者編寫的速成指南。

本文主要分享了WebRTC的基本概念、關(guān)鍵技術(shù)術(shù)語（包括NAT、STUN、TURN、ICE、SDP 和信令），著重講解了WebRTC是如何實(shí)現(xiàn)P2P通信以及WebRTC信令的作用，同時(shí)討論了WebRTC在技術(shù)上的優(yōu)勢和劣勢，最后還提供了一個(gè)簡單的WebRTC Demo代碼。

?

學(xué)習(xí)交流：

- 移動(dòng)端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動(dòng)端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點(diǎn)此）

（本文已同步發(fā)布于：http://www.52im.net/thread-4184-1-1.html）

2、什么是WebRTC？

WebRTC（全稱 Web Real-Time Communication），即網(wǎng)頁實(shí)時(shí)通信。 是一個(gè)支持網(wǎng)頁瀏覽器進(jìn)行實(shí)時(shí)語音對(duì)話或視頻對(duì)話的技術(shù)方案。從前端技術(shù)開發(fā)的視角來看，是一組可調(diào)用的API標(biāo)準(zhǔn)。這個(gè)技術(shù)可以使很多不同的應(yīng)用，如視頻會(huì)議、文件傳輸、聊天和桌面共享等都不需要額外的插件。

在WebRTC發(fā)布之前，開發(fā)實(shí)時(shí)音視頻交互應(yīng)用的成本是非常昂貴，需要考慮的技術(shù)問題很多，如音視頻的編解碼問題，數(shù)據(jù)傳輸問題，延時(shí)、丟包、抖動(dòng)、回音的處理和消除等，如果要兼容瀏覽器端的實(shí)時(shí)音視頻通信，還需要額外安裝插件。

2010年5月：Google以6820萬美元收購VoIP軟件開發(fā)商Global IP Solutions的GIPS引擎，并改為名為“WebRTC”（見《了不起的WebRTC：生態(tài)日趨完善，或?qū)?shí)時(shí)音視頻技術(shù)白菜化》）。旨在建立一個(gè)互聯(lián)網(wǎng)瀏覽器間的實(shí)時(shí)通信的平臺(tái)，讓 WebRTC技術(shù)成為 H5標(biāo)準(zhǔn)之一。

2012年1月：谷歌已經(jīng)把這款軟件集成到Chrome瀏覽器中，Opera初步集成WebRTC。

2013年 6月：Mozilla Firefox發(fā)布22.0版本正式集成及支持WebRTC。

2017年11月：W3C WebRTC 1.0 草案正式定稿。

2021年1月：WebRTC 被 W3C 和 IETF 發(fā)布為正式標(biāo)準(zhǔn)（見《WebRTC 1.0: Real-Time Communication Between Browsers》）。

截止目前，WebRTC 是完全開源免費(fèi)的，其使用 RTP 協(xié)議來傳輸音視頻，并支持 Chrome、Mozilla、Opera、Microsoft Edge、安卓瀏覽器等瀏覽器。

（本節(jié)內(nèi)容引用自《實(shí)時(shí)音視頻入門學(xué)習(xí)：開源工程WebRTC的技術(shù)原理和使用淺析》一文）

3、為什么需要WebRTC？

3.1我們?yōu)楹我?WebRTC？

建立它的理由是人們需要用一種標(biāo)準(zhǔn)的、低延遲的方式來傳遞媒體數(shù)據(jù)（視頻&音頻）。

所謂“標(biāo)準(zhǔn)的”意味著我們需要簡單易使用的 API。而所謂“低延遲的”意味著需要一種合適的協(xié)議，UDP 顯然是一個(gè)好的選擇，因?yàn)?UDP 沒有過多的應(yīng)答過程（Acknowledgment）。但我們需要的協(xié)議要比 UDP 更好，要能支持 P2P 的通信。因?yàn)橐坏┮蕾嚪?wù)器來傳遞內(nèi)容就會(huì)因?yàn)榉聪虼砘蛘叽┩敢腩~外的延遲，用戶需要進(jìn)行終止、觀察、處理、轉(zhuǎn)化流等操作，這些都會(huì)造成額外消耗。對(duì)于視頻傳輸、特別是直播、會(huì)話等場景，用戶希望內(nèi)容到達(dá)得越快越好，所以 P2P 是最快的路徑。

此外，WebRTC 也旨在實(shí)現(xiàn)瀏覽器之間豐富的溝通。瀏覽器已經(jīng)發(fā)展了很長時(shí)間，它“擁有”大量的優(yōu)質(zhì)資源，它可以訪問攝像頭和麥克風(fēng)，這些特性都值得被開發(fā)利用。用戶不需要寫自己的應(yīng)用，而是基于 WebRTC 的標(biāo)準(zhǔn) API 便可以輕松使用。不僅是瀏覽器，在移動(dòng)設(shè)備和 IoT 設(shè)備通信時(shí)也同樣。

3.2在 WebRTC 中究竟發(fā)生了哪些事呢？

舉個(gè)例子：A 想要與 B 進(jìn)行通信，但 A 與 B 之間“互不相識(shí)”。所以 A 首先需要找到所有 Public（不是 B）能連接到它的途徑，檢查 A 是否有一個(gè)公共 IP 能被 Public 識(shí)別或使用，如果沒有檢查 A 的路由器是否允許公開端口轉(zhuǎn)發(fā)規(guī)則、是否在路由上有公共代表等等。B 也做了以上同樣的事。

此外：A 和 B 還會(huì)收集自身所支持的加密方式、安全參數(shù)、視頻編解碼器等等大量的信息，注意這些信息還沒有被送到對(duì)端，在這個(gè)階段只是廣泛地收集。所有這些信息，構(gòu)成了“SDP”。

接下來：A 和 B 會(huì)通過其他方式（可以是 WhatsApp、QR、Tweet、WebSockets、HTTP Fetch…）發(fā)出會(huì)話信息，這種方式具體是什么 WebRTC 并不關(guān)心，只要能從 A 到 B（B 到 A）就可以。

這種工作方式表面上是有些“愚蠢的”，部分人可能會(huì)認(rèn)為“既然我已經(jīng)有了 A 和 B 之間通信的線路，那還要 WebRTC 做什么呢？”但認(rèn)真思考一下就可以發(fā)現(xiàn)，WebRTC 只要首次通信雙方交換了 SDP，后面就會(huì)實(shí)現(xiàn)真正的 P2P 通信，不再需要 WhatsApp、QR 等等中間途徑，不會(huì)有比這更快的通信路徑。因此最終 A 通過最優(yōu)路徑連接到了 B，這就是 WebRTC 的工作流程。

更詳細(xì)的闡釋這個(gè)例子如下：

如上圖所示：假設(shè) A 找到了 A1、A2、A3 三種方式可以訪問它，同時(shí)還找到了安全參數(shù)、媒體選項(xiàng)等信息。同時(shí)，B 也做了一樣的工作。接下來，他們通過一些方式（例如 WhatsApp）交換了以上信息。然后 A 找到 B2 是可用的最佳路徑，而 B 也發(fā)現(xiàn) A1 是可用的最佳路徑，那么二者將通過這條路徑直接連接彼此。

本質(zhì)上 WebRTC 就是這樣工作的：

4、WebRTC 的關(guān)鍵技術(shù)和概念

4.1概述

接下來我們將對(duì) WebRTC 的各項(xiàng)關(guān)鍵技術(shù)和概念進(jìn)行初始理解，對(duì)細(xì)節(jié)內(nèi)容進(jìn)行講述。

首先我們來了解 NAT 的細(xì)節(jié)（學(xué)習(xí) WebRTC 是如何進(jìn)行正確的網(wǎng)絡(luò)地址轉(zhuǎn)換），其次了解為什么我們需要 STUN 和 TURN，此外還會(huì)介紹 ICE、SDP 以及信令交換的相關(guān)內(nèi)容。

4.2NAT（Network Address Translation）

如果你有一個(gè)公開的 Public IP 地址，連接過程將不會(huì)有什么問題。因?yàn)槟銜?huì)像 Web 服務(wù)器一樣一直監(jiān)聽端口，把端口和 IP 都提供給對(duì)方后，你和它就可以直接進(jìn)行連接了。但在大多數(shù)情況下，用戶都是隱藏在公共網(wǎng)絡(luò)之后的，無法直接連接。

如下圖所示的示例中：路由器有一個(gè) Public IP?5.5.5.5，也有一個(gè) Private IP?10.0.0.1（也被稱為 gateway），你的機(jī)器只有一個(gè) Private IP?10.0.0.2，但你想要訪問 IP 為?4.4.4.4:80?的機(jī)器，要如何實(shí)現(xiàn)呢？

首先：你的機(jī)器會(huì)構(gòu)建一個(gè)數(shù)據(jù)包，聲明想向 4.4.4.4:80 發(fā)出 GET 請(qǐng)求，10.0.0.2 是源 IP 地址。接下來：你的機(jī)器會(huì)通過子網(wǎng)掩碼判斷是否可以直接與 4.4.4.4:80 進(jìn)行連接，運(yùn)算結(jié)果會(huì)顯示 4.4.4.4:80 并不在你所在的子網(wǎng)中，因此無法直接進(jìn)行通信。所以下一步就需要將請(qǐng)求發(fā)送給路由器，借助 gateway 進(jìn)行通信。路由器會(huì)替換源 IP 地址和端口為 Public IP 和一個(gè)隨機(jī)端口，但在此之前會(huì)創(chuàng)建 NAT 表，來記錄三者之間的對(duì)應(yīng)關(guān)系。這樣對(duì)端就能收到你的GET請(qǐng)求，并進(jìn)行后續(xù)處理了（如下圖所示）。

在這之后：服務(wù)器 4.4.4.4:80 將向你的機(jī)器發(fā)送回復(fù)，工作原理和上述相同，根據(jù) NAT 表查詢對(duì)應(yīng)地址完成通信（如下圖所示）。

NAT 的轉(zhuǎn)換方式主要有以下幾種：

1）一對(duì)一 NAT（完全圓錐型 NAT）：One to One NAT（Full-cone NAT） 路由器上要發(fā)送到外部 IP:port 的數(shù)據(jù)包總是可以映射到內(nèi)部 IP:port ，無一例外。舉例說明，所有發(fā)送到 5.5.5.5:3333 的數(shù)據(jù)包總是會(huì)被自動(dòng)轉(zhuǎn)發(fā)到 10.0.0.2:8992，無論這個(gè)包是來自 4.4.4.4:80 或者其他任何地址。

2）IP 受限型 NAT：Address restricted NAT 出于安全考慮，部分路由器會(huì)地址限制，考慮之前是否與該地址進(jìn)行過通信。即路由器上要發(fā)送到外部 IP:port 的數(shù)據(jù)包可以映射到內(nèi)部 IP:port，前提是數(shù)據(jù)包的源地址與 NAT 表相符，無所謂端口是什么。舉例說明，發(fā)送到 5.5.5.5:3333 的數(shù)據(jù)包中，只有源 IP 是 4.4.4.4 或其他表中有過記錄的 IP 才會(huì)被自動(dòng)轉(zhuǎn)發(fā)到 10.0.0.2:8992，即使這個(gè) IP 之前并不是和 3333 端口進(jìn)行的通信。

3）端口受限型 NAT：Port restricted NAT 與前者相比，增加了端口限制，即路由器上要發(fā)送到外部 IP:port 的數(shù)據(jù)包可以映射到內(nèi)部 IP:port，前提是數(shù)據(jù)包的源 IP 和 Port 都要與 NAT 表相符。舉例說明，發(fā)送到 5.5.5.5:3333 的數(shù)據(jù)包中，只有來自 4.4.4.4:80 或其他表中有過記錄的 IP: Port 才會(huì)被自動(dòng)轉(zhuǎn)發(fā)到 10.0.0.2:8992，即使這個(gè) IP: Port 之前并不是和 3333 端口進(jìn)行的通信。

4）對(duì)稱 NAT：Symmetric NAT 該方式是限制最多的一種，即必須匹配完整的 IP:port，區(qū)別在于發(fā)送到 5.5.5.5:3333 的數(shù)據(jù)包中，只有來自 4.4.4.4:80 的才會(huì)被自動(dòng)轉(zhuǎn)發(fā)到 10.0.0.2:8992，其他的包均無法通過。這種方式無法在 WebRTC 中使用，因?yàn)?WebRTC 需要 STUN 服務(wù)器。一旦 STUN 服務(wù)器建立了一個(gè) Public 代表，Symmetric NAT 要求只能與一個(gè)特定的對(duì)端通信，這種限制不適合 WebRTC。

在默認(rèn)情況下：WebRTC 可以支持前三種 NAT 方式，對(duì)最后一種并不友好。實(shí)際上 90% 以上的通信就是通過前三種方式完成的，最后一種作者個(gè)人認(rèn)為沒有使用的價(jià)值。

如果你對(duì)P2P技術(shù)感興趣，可以繼續(xù)深入閱讀以下幾篇：

《P2P技術(shù)詳解(一)：NAT詳解——詳細(xì)原理、P2P簡介》

《P2P技術(shù)詳解(二)：P2P中的NAT穿越(打洞)方案詳解(基本原理篇)》

《P2P技術(shù)詳解(三)：P2P中的NAT穿越(打洞)方案詳解(進(jìn)階分析篇)》

《通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理》

4.3STUN（Session Traversal Utilities for NAT）

STUN 是可以賦予一個(gè)應(yīng)用程序所需要的 Public IP 和 Port，適用于 Full-cone、Address restricted 和 Port restricted NAT，無法用于 Symmetric NAT。

STUN 服務(wù)器通常在 3478 端口上運(yùn)行，TLS 端口為 5349。

STUN 是非常輕量級(jí)的，用戶可以使用 docker 建立一個(gè) STUN 服務(wù)器。

STUN 服務(wù)器的目的就是讓用戶找到自己的 Public 表示，并通過這個(gè) Public 表示與其他用戶進(jìn)行通信。如果我們使用的是像大約 1996 年或 2000 年早期時(shí)那樣的 Public IP 地址，通信也將非常簡單。但就現(xiàn)在而言，我們必須使用 STUN 服務(wù)器。

STUN 服務(wù)器的工作流程如下圖所示：

首先創(chuàng)建一個(gè)數(shù)據(jù)包進(jìn)行 STUN 請(qǐng)求：STUN 服務(wù)器的地址為 9.9.9.9:3478，同樣在路由器創(chuàng)建了 NAT 表并進(jìn)行了地址轉(zhuǎn)換，然后數(shù)據(jù)包被送到了 STUN 服務(wù)器。

服務(wù)器收到請(qǐng)求后：為 10.0.0.2 的機(jī)器構(gòu)建了一個(gè) Public 表示 5.5.5.5:3333，并把這個(gè)信息打包進(jìn)一個(gè)數(shù)據(jù)包進(jìn)行反饋。

上述是一個(gè) STUN 請(qǐng)求的詳細(xì)過程，以下圖為例，STUN 在整個(gè)通信過程中進(jìn)行了以下工作：首先給予 10.0.0.2 的機(jī)器一個(gè) Public 表示 5.5.5.5:3333，同時(shí)給予 192.168.1.2 的機(jī)器一個(gè) Public 表示 7.7.7.7:4444。隨后二者都使用獲得的 Public 表示進(jìn)行連接。

值得注意的是：這二者之前并沒有進(jìn)行過通信。如果是 Full-cone NAT，那么沒有問題可以連接。如果是 Address restricted NAT，第一個(gè)請(qǐng)求連接的請(qǐng)求將會(huì)失敗。在這種情況下，用戶需要通過服務(wù)器建立至少一個(gè)通信請(qǐng)求，先讓兩個(gè)地址都能保存在兩端的路由器中，這樣再次通過 Public 表示進(jìn)行連接請(qǐng)求時(shí)就能找到匹配的地址，繼而可以完成連接。Port restricted NAT 工作原理與之類似。

以下是部分 Google 提供的公共服務(wù)器，感興趣的可以參考：

stun1.l.google.com:19302

stun2.l.google.com:19302

stun3.l.google.com:19302

stun4.l.google.com:19302

stun.stunprotocol.org:3478

4.4 TURN（Traversal Using Relays around NAT）

在應(yīng)用 Symmetric NAT 的情況下，必須使用 TURN。

所有的通信內(nèi)容都要經(jīng)過 TURN 服務(wù)器的轉(zhuǎn)發(fā)，所以 TURN 服務(wù)器的維護(hù)成本比較高，這也是為什么幾乎沒有人免費(fèi)提供這種服務(wù)器供用戶使用。

下圖是一個(gè) TURN 服務(wù)器工作流程的示例，二者之間并不是直接的 P2P 通信，所有的信息都經(jīng)過了 TURN 服務(wù)器進(jìn)行轉(zhuǎn)發(fā)。

這里有一個(gè)開源庫也可以幫助大家創(chuàng)建屬于自己的 TURN 服務(wù)器，地址是：https://github.com/coturn/coturn。

4.5ICE（Interactive Connectivity Establishment）

在建立了很多 STUN 和 TURN 服務(wù)器后，從 A 到 B 之間的路徑有了非常多的選擇，為了更好的處理這些路徑，人們提出了 ICE。

ICE 會(huì)收集所有可用的通信路徑作為“候選人”（ICE Candidates），有可能是本地 IP 地址、STUN 和 TURN 服務(wù)器提供的地址等等。收集到的所有地址都將放入 SDP 中，再送到對(duì)端，對(duì)端通過解析 SDP 來了解我方提供的重要信息。

因此，ICE 是 WebRTC 中非常關(guān)鍵的組成部分。

最后：如果想更多地了解STUN、TURN、ICE，可以閱讀：《P2P技術(shù)詳解(四)：P2P技術(shù)之STUN、TURN、ICE詳解》。

4.6SDP（Session Description Protocol）

SDP 是一種用于表述 ICE Candidates 的格式，它描述了網(wǎng)絡(luò)選項(xiàng)、媒體選項(xiàng)、安全選項(xiàng)和其他很多信息，開發(fā)者甚至可以自定義 SDP 內(nèi)容。

實(shí)際上 SDP 并不是一種協(xié)議，只是一種數(shù)據(jù)格式，但 SDP 是 WebRTC 中最重要的幾個(gè)概念之一。它的設(shè)計(jì)目的是將用戶產(chǎn)生的 SDP 送至其他端，送的方式并不關(guān)心。

4.7Signaling（信令交換）

Signaling 過程是將用戶產(chǎn)生的 SDP 通過某種方式傳遞給想要通信的那方。

如上所述，以何種方式傳遞并不重要。很多人通過?WebSocket 或者 socket.io?來傳遞 SDP 信息，這個(gè)過程就是 Signal SDP。

盡管要找到所有的 ICE candidate 是耗費(fèi)時(shí)間的，但一旦完成了這個(gè)過程，下一步就是創(chuàng)建一個(gè) SDP，進(jìn)而生成一個(gè) QR code 并把 QR code 公布到 twitter 上，其他人掃描了這個(gè)二維碼就可以獲取相應(yīng)的 SDP。

這個(gè)過程是通過 twitter、QR code、Whatsapp、WebSockets、還是 HTTP 請(qǐng)求都不重要，因?yàn)閷?shí)際上就是將一個(gè)長字符串傳遞給其他人罷了。

簡而言之，Signaling 就是將 SDP 信息傳遞給另外一方。

4.8小結(jié)一下

一個(gè)典型的WebRTC通信流程是這樣的：

• 1）A 想要和B建立連接；

• 2）A 創(chuàng)建了一個(gè) offer，它尋找所有的 ICE candidate、安全選項(xiàng)、音視頻選項(xiàng)等并創(chuàng)建 SDP（簡單來說這個(gè) offer 就是 SDP）；

• 3）A 將 SDP 信令傳遞給 B（Signaling）；

• 4）B 根據(jù) A 的 offer 進(jìn)行設(shè)置，并創(chuàng)建應(yīng)答（answer）；

• 5）B 將 Answer 信令傳遞給 A（Signaling）；

• 6）連接建立。

5、WebRTC 的信令（Signal）

5.1什么是信令

信令是配置、控制、以及結(jié)束用戶間通信會(huì)話的過程。端到端通信（即P2P）需要信令來建立。

兩端想要通信，主要需要三個(gè)信令步驟：

• 1）分享會(huì)話控制信息；

• 2）交換IP地址和端口等網(wǎng)絡(luò)信息；

• 3）交換用戶的編解碼器以及媒體格式。

5.2為什么通信需要信令

那么為什么通信需要信令呢：

• 1）會(huì)話控制信息會(huì)控制端到端連接的所有建連、斷連、以及發(fā)送信息；

• 2）IP 以及端口信息用于找到用戶網(wǎng)絡(luò)層位置；

• 3）編解碼器以及多媒體格式用于確定用戶間建立的分辨率以及多媒體設(shè)置；

• 4）這些所有的設(shè)置都根據(jù) SDP 協(xié)議（Session Description Protocal）來進(jìn)行交換。

5.3為什么 WebRTC 需要信令

如果兩個(gè)用戶希望P2P通信，那兩端之間則需要一個(gè)額外的服務(wù)器來交換初始數(shù)據(jù)設(shè)置 WebRTC 連接，這個(gè)服務(wù)器就叫做信令服務(wù)器。

信令過程結(jié)束后，所有多媒體數(shù)據(jù)都會(huì)經(jīng)過 RTCPeerconnection 端到端交換。

知識(shí)要點(diǎn)：

• 1）信令服務(wù)器只是幫助 WebRTC 交換元數(shù)據(jù)來建立連接，并不真的對(duì) WebRTC 過程影響；

• 2）信令服務(wù)器可以由任意的服務(wù)器技術(shù)搭建，如?WebSocket、socket.io、SIP 等；

• 3）RTCPeerConnection 是 WebRTC 使用的 API 來建立用戶間連接并通信。

5.4如何讓用戶實(shí)現(xiàn)P2P通信

用戶間想要獲取各自的公網(wǎng) IP 地址，因?yàn)?NAT 和防火墻導(dǎo)致兩個(gè)用戶直接通信是很困難的，因此需要通過 ICE框架配合 STUN和 TURN協(xié)議來解決這些問題，實(shí)現(xiàn)端到端連接。

STUN的作用：如果一個(gè)用戶在 NAT 背后有一個(gè)局域網(wǎng) IP 地址，那從這個(gè)局域網(wǎng)外很難聯(lián)系到這個(gè)用戶，那這個(gè)用戶就可以通過 STUN 服務(wù)器來獲取他的公網(wǎng) IP，就可以讓其他公網(wǎng)的用戶來穿透 NAT 連接到他。

TURN的作用：STUN 使用的方法在面對(duì)對(duì)稱型 NAT 時(shí)就會(huì)失效，這時(shí)就需要使用 TURN 協(xié)議。但是 TURN 的問題在于，STUN 在連接建立完成后就不再被需要，而 TURN 則在整個(gè)會(huì)話過程中都需要存在。

5.5WebRTC 的信令是必須的嗎

WebRTC 可以讓用戶直接P2P通信，但是卻沒有辦法讓其中一個(gè)用戶找到另一個(gè)用戶（如 IP 地址等）。因此用戶也可以使用 SDP 請(qǐng)求和 SDP 答復(fù)，只需要有一個(gè)信令服務(wù)器就可以了。

5.6SDP 請(qǐng)求和答復(fù)

在兩端希望直接通信之前，他們必須都要有一個(gè)連接到一個(gè)信令服務(wù)器，這樣就可以兩端分享 SDP 信息。

SDP 請(qǐng)求和答復(fù)包括用戶有關(guān)音頻、視頻、編碼器等信息。一個(gè)用戶發(fā)送一個(gè)初始的 SDP 請(qǐng)求來創(chuàng)建多媒體通信會(huì)話，對(duì)端收到后可以選擇創(chuàng)建一個(gè) SDP 答復(fù)來接受或拒絕這個(gè) SDP 請(qǐng)求。

6、WebRTC 的架構(gòu)原理

下圖是一個(gè)簡單的 WebRTC 連接架構(gòu)原理圖：

在連接階段，用戶使用信令服務(wù)器間接通信建立連接，在連接建立結(jié)束后，兩用戶直接通過音視頻信道通信。

下圖是一個(gè)詳細(xì)版本的 WebRTC 連接架構(gòu)原理圖：

如上圖所示：可以看到兩個(gè)用戶希望建立 WebRTC 連接，兩端直接建立連接前都可以連接到同一個(gè)信令服務(wù)器，并通過該服務(wù)器交換 SDP 信息。在 SDP 請(qǐng)求和答復(fù)交換結(jié)束后，兩用戶都可以獲取各自的 IP 地址和音視頻配置等信息。之后就需要用 TURN 或者 STUN 服務(wù)器來穿透 NAT，達(dá)到用戶間的直接 WebRTC 連接。

7、WebRTC 的優(yōu)缺點(diǎn)

7.1優(yōu)點(diǎn)

1）P2P 通信是非常棒的：對(duì)于高帶寬內(nèi)容可以有降低的延遲。P2P 是最快的路徑，不需要經(jīng)過其他的第三方進(jìn)行通信。即使通互聯(lián)網(wǎng)傳輸要經(jīng)過大量的路由器，但如果內(nèi)容已經(jīng)被加密了所有的路由器都不會(huì)查看內(nèi)容，它們會(huì)直接傳遞數(shù)據(jù)包，所以 P2P 是非常好的通信方式。對(duì)于高帶寬內(nèi)容，它們通過 UDP 直接被“送入”和“推出”，通過 P2P UDP 傳遞這些內(nèi)容（特別是視頻內(nèi)容），用戶將收獲最好的性能。

2）標(biāo)準(zhǔn)可用的 API：WebRTC 有一套非常標(biāo)準(zhǔn)、非常優(yōu)雅的 API，可以直接在瀏覽器中應(yīng)用，不需要安裝其他的包、也不需要用多余的開發(fā)工具。

7.2缺點(diǎn)

1）需要維護(hù) STUN 和 TURN 服務(wù)器：在某些情況下 P2P 不能工作，你仍需要一個(gè) TURN 服務(wù)器。但維護(hù) STUN 和 TURN 服務(wù)器需要耗費(fèi)大量的人力物力，特別是 TURN 服務(wù)器。因?yàn)槟闶紫纫ㄥX維護(hù)一個(gè) Public IP，并且必須維護(hù)這個(gè)服務(wù)器使其可以正常啟動(dòng)和運(yùn)行。作者個(gè)人認(rèn)為與其花費(fèi)這種代價(jià)，不如自己建立一個(gè)擁有全部控制權(quán)的服務(wù)器，進(jìn)行反向代理。

2）在參與者過多的情況下P2P 會(huì)崩潰：假設(shè)有 100 個(gè)人想要相互交流，你會(huì)創(chuàng)建 P2P 連接嗎？那會(huì)是幾百乘幾百的連接量，因?yàn)槊總€(gè)人都需要連接到其他任何一個(gè)用戶，這將是非常大規(guī)模的。但如果你有一個(gè)集中式服務(wù)器，每個(gè)用戶只需要和這個(gè)服務(wù)器建立一個(gè)連接，你可以通過這個(gè)服務(wù)器控制所有的流量，這明顯是一種更好的方式。所以 WebRTC 有時(shí)候無法用在游戲上，你沒辦法利用 WebRTC 來創(chuàng)建一個(gè)多用戶游戲，當(dāng)然 3 個(gè)用戶是可以的，但幾百個(gè)用戶作者認(rèn)為是無法實(shí)現(xiàn)的。

8、WebSocket 和 WebRTC 的區(qū)別

8.1設(shè)計(jì)初衷不同

瀏覽器通信有主要兩種傳輸信道：HTTP 和 WebSockets。WebSocket 的作用就是用于實(shí)現(xiàn)瀏覽器的雙向機(jī)制通信。

對(duì)于HTTP：主要用于獲取網(wǎng)頁內(nèi)容，文字或圖片等，是一種客戶服務(wù)類型協(xié)議，其中瀏覽器是客戶端，而網(wǎng)頁服務(wù)器是服務(wù)端；

而對(duì)于 WebSocket：瀏覽器通過一個(gè) WebSocket 連接到網(wǎng)頁服務(wù)器，與 HTTP 相同也是一個(gè)C/S類型協(xié)議。但是 HTTP 是一個(gè)單向的信道，而 WebSocket 是雙向的，意味著服務(wù)器和客戶端之間的連接可以一直保持到兩者主動(dòng)斷開。

WebSocket 主要用于實(shí)時(shí)網(wǎng)頁應(yīng)用和IM聊天應(yīng)用等。

而 WebRTC 相較于 WebSocket 的特點(diǎn)在于：

• 1）WebRTC 是為高質(zhì)量音視頻實(shí)時(shí)通信設(shè)計(jì)的；

• 2）WebRTC 提供的瀏覽器端到端通信遠(yuǎn)比 WebSocket 提供的服務(wù)延遲更低。

8.2實(shí)現(xiàn)上的區(qū)別

主要是兩點(diǎn)：

• 1）WebRTC 使用 UDP 協(xié)議，而 WebSocket 使用 TCP 協(xié)議；

• 2）WebRTC 可以同時(shí)提供高質(zhì)量且低延遲的推流。

8.3WebRTC 其實(shí)也使用了 WebSocketk

WebRTC 其實(shí)也使用了 WebSocket，不過是用于搭建 WebRTC的信令機(jī)制，但是在連接建立結(jié)束后，由于 WebRTC 是端到端連接，因此也不再需要額外服務(wù)器。

9、一個(gè)簡單的 WebRTC Demo

為了配合本文內(nèi)容的理解，這里準(zhǔn)備了一個(gè)簡單的WebRTC Demo代碼（下載地址點(diǎn)此）。

這個(gè) Demo 程序可以實(shí)現(xiàn)：

• 1）在兩個(gè)瀏覽器間進(jìn)行通信（瀏覽器 A 和瀏覽器 B）；

• 2）A 創(chuàng)建一個(gè) offer（SDP），并設(shè)置它為本地描述；

• 3）B 接收一個(gè) offer 并設(shè)置它為遠(yuǎn)端描述；

• 4）B 創(chuàng)建一個(gè) answer 并設(shè)置它為本地描述，并將其傳遞給 A；

• 5）A 接收 answer 并設(shè)置它為遠(yuǎn)端描述；

• 6）建立連接、建立數(shù)據(jù)通道、交換數(shù)據(jù)。

10、參考資料

[1]?Get started with WebRTC

[2]?零基礎(chǔ)，史上最通俗視頻編碼技術(shù)入門

[3]?零基礎(chǔ)入門：實(shí)時(shí)音視頻技術(shù)基礎(chǔ)知識(shí)全面盤點(diǎn)

[4]?良心分享：WebRTC 零基礎(chǔ)開發(fā)者教程（中文）[附件下載]

[5]?WebRTC實(shí)時(shí)音視頻技術(shù)的整體架構(gòu)介紹

[6]?新手入門：到底什么是WebRTC服務(wù)器，以及它是如何聯(lián)接通話的？

[7]?WebRTC實(shí)時(shí)音視頻技術(shù)基礎(chǔ)：基本架構(gòu)和協(xié)議棧

[8]?開源實(shí)時(shí)音視頻技術(shù)WebRTC在Windows下的簡明編譯教程

[9]?零基礎(chǔ)入門：基于開源WebRTC，從0到1實(shí)現(xiàn)實(shí)時(shí)音視頻聊天功能

[10]?實(shí)時(shí)音視頻入門學(xué)習(xí)：開源工程WebRTC的技術(shù)原理和使用淺析

[11]?WebSocket從入門到精通，半小時(shí)就夠！

[12]?搞懂現(xiàn)代Web端即時(shí)通訊技術(shù)一文就夠：WebSocket、socket.io、SSE

[13]?NAT詳解——詳細(xì)原理、P2P簡介

[14]?P2P技術(shù)之STUN、TURN、ICE詳解

[15]?通俗易懂：快速理解P2P技術(shù)中的NAT穿透原理

（本文已同步發(fā)布于：http://www.52im.net/thread-4184-1-1.html）