大家好，很高興又見面了，我是“web 前端分享”，由我帶著大家一起關注前端前沿、深入前端底層技術，大家一起進步，也歡迎大家關注、點贊、收藏、轉發！
上一篇文章《WebRTC已成為HTML5標準？是時候開始學習了？》釋出後反響不錯，特定再出一文詳細論述WebRTC、SDP、STUN、TURN等諸多內容，創作不易，拒絕轉發到其他平臺，萬望理解！
1。前言
1。1 什麼是 WebRTC？
下圖展示了不同協議出現的時間線：
各傳輸協議時間線
在計算機網路中，協議是一組規則，用於管理資料在裝置之間的交換方式。 協議定義了通訊的規則、語法、語義和同步以及可能的錯誤恢復方法，本文中討論的 WebRTC 協議定義了應用層軟體如何相互互動。
WebRTC（Web Real-Time Communication）也被稱為網路實時通訊，是由 Google、Mozilla 和其他公司推動的一個開源專案，它透過 Javascript API 實現無外掛的實時通訊，建立瀏覽器之間點對點（Peer-to-Peer）的連線。
1。2 WebRTC 的優點？
WebRTC 的優點可以歸納為以下幾個方面：
開源、免費，開發者不需要承擔高昂的專利費用
基於瀏覽器，不需要安裝外掛，只要呼叫 API 就可以實現音影片互動
被納入了 HTML5 標準，主流瀏覽器全面支援 WebRTC
不僅支援 Web 之間的音影片通訊，還支援 Android 以及 IOS 端，由於該專案是開源的，我們也可以透過編譯 C++程式碼，從而達到全平臺的互通
在 WebRTC 誕生之前，開發實時音影片應用的成本是非常高，需要考慮的技術問題很多，如音影片的編解碼，
資料傳輸延時、丟包、網路抖動、迴音處理和消除
等，如果要相容瀏覽器端的實時音影片通訊，還需要額外安裝外掛。可喜的是，本文的主角 WebRTC 在 2021 年 1 月被 W3C 和 IETF 釋出為正式標準，而且得到了大多數主流瀏覽器的支援。
CanIUse 中 WebRTC 的瀏覽器支援情況
WebRTC 專案的願景：實時通訊 web 化，讓 WebRTC 成為網際網路音影片實時通訊的規範，讓開發者基於此規範快速開發出安全、可靠的應用。WebRTC 必須在 HTTPS 環境下執行，你可以在https：//appr。tc/、https：//snapdrop。net/體驗WebRTC應用，或者在https：//nashaofu。github。io/webrtc-demo/，https：//webrtc。github。io/samples/檢視WebRTC示例。
2。瞭解SDP和Offer-Answer模型
2。1 什麼是RTP/RTCP？
大多數人已經瞭解 TCP 和 UDP 等傳輸協議，當您要保證傳輸資料準確（例如：郵件）時，TCP 協議更好，而 UDP則更加偏向傳輸速度（例如：YouTube 影片）。
實時傳輸協議 （
Real-time Transport Protocol，RTP
） 又是一種用於透過 IP 網路傳送音訊和影片的網路協議。 RTP 廣泛用於涉及流媒體的通訊和娛樂系統，例如電話、影片電話會議、電視服務等。 作為一種電信標準，WebRTC 正在使用 RTP 傳輸實時資料。
RTP 控制協議 （
RTP Control Protocol
，即RTCP） 是實時傳輸協議 （RTP） 的兄弟協議。 RTCP 為 RTP 會話提供額外統計和控制資訊。 使用 RTCP您可以獲得有關資料傳輸成功的資料，例如“傳輸過程中發生了多少資料包丟失”、“資料包延遲是多少”或“影片通話的解析度是多少”等等。
RTP 和 RTCP 資料包的傳輸發生在媒體通道上，而WebRTC 負責媒體通道上的媒體傳輸。作為應用程式開發人員，您的責任是管理信令通道。 所以你通常不知道這些概念，而且大多數時候你不需要它們，但在開始 SDP 和 Offer-Answer 模型之前有必要先了解下 RTP/RTCP 。
2。2 什麼是SDP（Session Description Protocol）？
現實生活中，如果您想讓人們聯絡到您，您會分享您的聯絡資訊，比如電子郵件、電話號碼、Instagram 帳戶、家庭住址等。 分享此類資訊的最簡單方法是向他們提供您的名片，而為了能夠找到對方，
網際網路數字名片
可能包含以下資訊：
主叫方和被叫方IP 地址
支援哪些媒體型別（音訊、影片、螢幕共享等）
當前啟用或禁用了哪些媒體型別（影片開/關保持/取消保持等）
對方都支援哪些編解碼器型別
網際網路數字名片
在電信領域，稱這種數字名片為會話描述協議 （SDP）， SDP 包含對等點相互交談所需的資訊。WebRTC 也使用 SDP 作為通訊標準來發起呼叫， SDP 只是一個可以被端點解析和操作的文字。
例如，如果使用者想要保持通話，您可以透過將 SDP 作為應用程式進行操作來禁用/啟用影片和音訊流。 或者您的系統需要特定的影片編解碼器，比方說 H。264，您可以刪除除 H。264 之外的任何其他編解碼器。
這就是 SDP 的強大之處，它很容易根據您的要求進行操作
下面是一個 SDP 示例，可能包含以下資訊：
o=alice 2890844526 2890844526 IN IP4 10。48。1。2//O=表示呼叫的發起者、會話ID和發起者的IP地址t=0 0//t= 表示會話結束時間。如果為 0，則表示會話不受時間限制m=audio 49170 UDP/TLS/RTP/SAVPF 111 0// m=表示media line，是session中可以存在的媒體屬性。 在這種情況下，它表示音訊媒體線。 此行還包含將在會話中使用的傳輸協議 （UDP/TLS/RTP/SAVPF）。 最後，此行包含將在會話中使用的編解碼器有效載荷編號 （111， 0）c=IN IP4 217。345。789。123// c=表示連線資訊，比如你要呼叫的遠端裝置的IP地址a=sendrecva=rtpmap：111 opus/48000/2a=rtpmap：0 PCMU/8000//a= 表示屬性線。 它定義會話和媒體行屬性。 在第一行中，a=sendrcv 屬性表示裝置願意傳送和接收音訊媒體，他還 可以有其他值，如 recvonly、sendonly 或 inactive用於不同的場景，如保持或影片關閉// Rtpmap 屬性指示音訊編解碼器編號的對映。 在這種情況下，111 對映到具有 48，000 bps 頻寬的 Opus，而 0 對映到具有 8，000 bps 頻寬的 PCMU 編解碼器， 標準 SDP 中可以有更多的屬性行。m=video 51372 UDP/TLS/RTP/SAVPF 98 100//m= 也表示媒體行，在這種情況下，它表示影片媒體線。同樣，它包含傳輸協議和編解碼器有效負載編號。a=sendrecva=rtpmap：98 VP9/90000a=rtpmap：100 H264/90000//a= 表示屬性行。 在第一行中，a=sendrcv 屬性表示裝置願意傳送和接收影片媒體//rtpmap 值，98 對映到具有 90，000 bps 頻寬的 VP9 影片編解碼器，100 對映到具有 90，000 bps 頻寬的 H。264 影片編解碼器
SDP的更多屬性配置可以閱讀文末資料，這裡不再展開。
2。3 什麼是Offer-Answer模型？
到目前為止，解釋了“WebRTC 如何在媒體通道中傳輸資料？”（RTP/RTCP）和“如何在信令通道中根據需要指定會話屬性？”（SDP）。 接下來回答“應用程式應該如何相互傳輸會話屬性 （SDP）？”。
你可能有一張華麗的名片，但如果你不把它送給任何人，它就毫無用處， 此規則也適用於 SDP。 我們需要在對等點之間交換 SDP 以發起呼叫。 Offer-Answer 模型是在 WebRTC 中用作電信標準的 SDP 交換過程，交換方式由申請時決定。 應用程式可以透過 HTTP/HTTPS 請求、Web 套接字、推送通知等方式傳送它。這完全取決於應用程式。
Offer-Answer模型
Offer-Answer模型顧名思義，在這個模型中有一個 Offerer 和一個 Answerer。 提供者是啟動信令過程的人，例如開始撥出電話或傳送通話事件的人，包括保持和關閉影片開關。 回答者是回答傳入提議的人， 例如接聽來電或向通話中事件傳送合適的資料。
Offer-Answer 模型有 4 個基本步驟；
Offerer 建立一個 Offer SDP 並將其傳送到遠端節點。
應答者收到提議者的 SDP，並自行設定。
Answerer 建立一個 Answer SDP 並將其傳送給 offerer
提供者收到應答者的 SDP，並自行設定。
之後，如果一切正常，呼叫開始。
2。4 WebRTC的Offer-Answer模型交換流程
下圖顯示了 WebRTC 上使用 Offer-Answer 模型的 SDP（
Session Description Protocol，即會話描述協議
） 交換過程：
WebRTC 信令流程
接下來一一說明這些步驟：
Peer-1 獲取使用者媒體，然後從 WebRTC 建立一個 PeerConnection 物件
建立PeerConnection後，應用程式需要呼叫WebRTC的createOffer介面
WebRTC 建立一個Offer SDP ，並且可以根據需要操作 SDP
應用程式應將 Offer SDP 設定回 WebRTC
應用程式應向 Peer-2 傳送Offer SDP
Peer-2 上的應用程式收到Offer SDP， Peer-2 應該獲取使用者媒體並建立 PeerConnection 物件（如果目前尚未建立）
Peer-2 上的應用程式將Offer SDP 設定給 WebRTC
Peer-2 上的應用程式使用 WebRTC 的 createAnswer API 生成應答 SDP
WebRTC 建立一個應答 SDP 並將其提供給應用程式，應用程式可以根據需要操作SDP
應用程式應將 Answer SDP 設定給 WebRTC
Peer-2 上的應用程式應將應答 SDP 傳送給 Peer-1
Peer-1 上的應用程式設定應答 SDP
如果一切正常，RTP 媒體流將透過 WebRTC 在媒體通道上啟動。
上面可能有很多步驟，但其中大部分都是重複性任務。
WebRTC 交換 offer 與網路引數之後，就會嘗試直接使用對方的 IP 地址與埠進行直連，這個過程會根據雙方網路情況，使用的不同的方式建立連線，後文 NAT（Network Address Translation，即網路地址轉換）打洞就是介紹這部分內容。
3。什麼是信令伺服器？什麼是STUN？什麼是TURN？
A 與 B 在建立 WebRTC 連線過程中，需要互相知道對方的 IP 與通訊埠。那麼 A 與 B 要如何知道對方的 IP 與埠呢？答案就是透過信令伺服器。 信令伺服器的作用是作為一箇中間人幫助雙方在儘可能少的暴露隱私的情況下建立連線。WebRTC 並沒有提供信令傳遞機制，你可以使用任何方式如 WebSocket 或者 XMLHttpRequest 等，來交換彼此的令牌資訊。
STUN 和 TURN 伺服器是兩種型別的 WebRTC 信令伺服器，可用於在構建實時通訊應用程式時建立對等 （P2P） 連線。
3。1 什麼是STUN？
STUN（NAT 會話遍歷實用程式）使用 UDP 協議透過 NAT 來實現 ICE能力。 STUN 允許應用程式發現它們之間和公共網際網路上的 NAT 、防火牆的存在和型別。 任何裝置都可以使用它來確定 NAT 分配給它的 IP 地址和埠。
通常，STUN 客戶端可以向 STUN 伺服器傳送訊息以獲取公共 IP 和埠資訊，然後基於此公共 IP 和埠資訊即可在客戶端之間透過網際網路進行點對點通訊。
3。2 什麼是TURN？
TURN（Traversal Using Relays around NAT）是一種協議，可協助 webRTC 應用程式穿越網路地址轉換器 （NAT） 或防火牆。 TURN Server 允許客戶端透過中間伺服器傳送和接收資料， TURN 協議是 STUN 的擴充套件。
在少數情況下，客戶端通訊端點在不同型別的 NAT 後面，或者當使用對稱 NAT 時，透過中繼伺服器及其稱為 TURN 伺服器傳送媒體可能更容易。
4。WebRTC API 呼叫
4。1 RTCPeerConnection
RTCPeerConnection 用於點對點之間建立連線以傳輸音影片資料流，這是 RTCPeerConnection 的任務，為此需要藉助一個信令伺服器（signaling server）來進行，信令包括 3 種類型的資訊：
Session control messages： 初始化和關閉通訊，及報告錯誤；
Network configuration： 雙方的 IP 地址和埠號（區域網內部 IP 地址需轉換為外部的 IP 地址）；
Media capabilities： 雙方的瀏覽器支援使用何種編碼以及多高的影片解析度。
var PeerConnection = window。RTCPeerConnection || window。mozRTCPeerConnection || window。webkitRTCPeerConnection；navigator。getUserMedia = navigator。getUserMedia ？ ‘getUserMedia’ ： navigator。mozGetUserMedia ？ ‘mozGetUserMedia’ ： navigator。webkitGetUserMedia ？ ‘webkitGetUserMedia’ ： ‘getUserMedia’；var v = document。createElement（‘video’）；// 建立信令（createOffer）var pc = new PeerConnection（）；pc。addStream（video）；pc。createOffer（function （desc） { pc。setLocalDescription（desc， function （） { // send the offer to a server that can negotiate with a remote client }）；}）；// 建立回覆（createAnswer）var pc = new PeerConnection（）；pc。setRemoteDescription（new RTCSessionDescription（offer）， function （） { pc。createAnswer（function （answer） { pc。setLocalDescription（answer， function （） { // send the answer to the remote connection }）； }）；}）；
4。2 RTCDataChannel
RTCDataChannel 介面代表在兩者之間建立了一個雙向資料通道的連線，可以用 RTCPeerConnection。createDataChannel（） 或者在現有的 RTCPeerConnection 上用 RTCDataChannelEvent 型別的 datachannel 事件接收，創建出 RTCDataChannel 型別的物件。
var pc = new RTCPeerConnection（）；// 獲取 RTCPeerConnection 物件var dc = pc。createDataChannel（‘my channel’）；// 建立 DataChannel 物件dc。onmessage = function （event） { console。log（‘received： ’ + event。data）；}；dc。onopen = function （） { console。log（‘datachannel open’）；}；dc。onclose = function （） { console。log（‘datachannel close’）；}；
4。3 訪問使用者攝像頭及麥克風 getUserMedia
WebRTC 支援直接傳輸音訊流和影片流（https：//appr。tc/）：
const pc = new RTCPeerConnection（） ；// 獲取RTCPeerConnectionnavigator。getUserMedia（{ video： true }， stream => { // 新增影片流到會話中 stream。getTracks（）。forEach（track => pc。addTrack（track， stream）） // 在網頁中預覽自己攝像頭拍攝到的內容，其中$localVideo表示一個Video物件 $localVideo。srcObject = stream； }）
navigator。getUserMedia（）還可以和web Audio API相結合，用來處理音訊效果：
var range = document。querySelector（‘input’）；window。AudioContext = window。AudioContext || window。webkitAudioContext；var audioCtx = new AudioContext（）；navigator。getUserMedia（{ audio： true}， function（stream） { // 建立音訊流 var source = audioCtx。createMediaStreamSource（stream）； // 雙二階濾波器 var biquadFilter = audioCtx。createBiquadFilter（）； biquadFilter。type = ‘lowshelf’； biquadFilter。frequenc。value = 1000； biquadFilter。gain。value = range。value； source。connect（biquadFilter）； biquadFilter。connect（audioCtx。destination）；}， function（error） { console。log（error）；}）；
其實，WebRTC並不只是用來做影片、音訊，它還可以用來傳輸任意資料，包括檔案，文字等。上面程式碼示例可以看到，WebRTC規定了
dataChannel
這個雙工資料通道，而https：//snapdrop。net/這個網站就是透過WebRTC進行檔案分享。
const pc = new RTCPeerConnection（） const dataChannel = pc。createDataChannel（‘chat’） // 監聽datachannel事件pc。addEventListener（‘datachannel’， event => { // 接收通訊方傳送過來的資料 event。channel。addEventListener（‘message’， event => { console。log（‘message’， event。message） }） }） dataChannel。addEventListener（‘open’， （） => { // 傳送資料，可傳送任意資料 dataChannel。send（‘Hi！’） }） dataChannel。addEventListener（‘close’， event => { }）
4。4 candidate 事件
當 RTCPeerConnection 例項執行 setLocalDescription（）後，RTCPeerConnection 就會探測自己的網路環境，然後用 candidate 事件返回候選網路環境資料，網路環境資料中最重要的是 IP 地址與埠組成的候選通訊地址。 candidate 事件中的 event。candidate 主要包含以下幾個部分：
本機 IP 地址
本機用於 WebRTC 通訊的埠號
候選者型別，包括 host、srflx 和 relay
優先順序
傳輸協議
具體資料結構的示例如下：
{ address： ‘192。168。31。67’， candidate： ‘candidate：2147606101 1 udp 2122260223 192。168。31。67 57959 typ host generation 0 ufrag EaWw network-id 1 network-cost 10’， component： ‘rtp’， foundation： ‘2147606101’， port： 57959， priority： 2122260223， protocol： ‘udp’， relatedAddress： null， relatedPort： null， sdpMLineIndex： 0， sdpMid： ‘0’， tcpType： null， type： ‘host’， usernameFragment： ‘EaWw’，}；
candidate 事件 type 欄位取值分別為 host、srflx、relay：
host(Host candidate)
：從本地網絡卡上獲取的地址
srflx(Server reflexive candidate)
：STUN（Session Traversal Utilities for NAT，即 NAT 會話穿越應用程式） 返回的該客戶端的地址
relay(Relay reflexive candidate):
：TURN （Traversal Using Relay NAT，即透過 Relay 方式穿越 NAT）伺服器為該客戶端分配的中繼地址
本地的 candidate 與遠端 candidate 構成的每一對都有一定的優先順序，按優先順序排序進行連通性檢查。最後從有效的 candidate 組合中選擇優先順序最高的作為傳輸地址，用於建立 P2P 連線。
5。網路地址轉換（NAT）
網路地址轉換（英語：Network Address Translation，縮寫：NAT；又稱網路掩蔽、IP 掩蔽）在計算機網路中是一種在 IP 資料包透過路由器或防火牆時重寫來源 IP 地址或目的 IP 地址的技術。這種技術被普遍使用在有多臺主機但只通過一個公有 IP 地址訪問網際網路的私有網路中。 要建立一個連線需要知道對方的 IP 地址和埠號，在局域網裡面一臺路由器（基站）可能會連線著很多臺裝置，例如家庭路由器接入寬頻的時候，寬頻服務商會分配一個公網的 IP 地址，所有連到這個路由器的裝置都共用這個公網 IP 地址。如果兩臺裝置都用了同一個公網 IP：port 去傳送請求，伺服器返回資料在經過路由器時它就不知道應該轉發給哪一個裝置。因此路由器需要重寫 IP 地址/埠號進行區分，如下圖所示：
NAT 裝置通常會自動設定各個裝置的對映關係，也可以在路由器端去手動設定。如上圖的 NAT 維護的對映關係還會和要訪問的目標 IP 地址進行繫結，例如同一終端使用同一埠訪問不同的目標 IP，就會建立不同的對映關係。
如上示例 NAT 上建立的對映關係如下：
內網 IP 埠
外網 IP 埠
NAT 對外 IP 與埠
192。168。1。2：8080
39。182。39。30：443
10。188。20。10：8000
192。168。1。2：8080
39。182。39。40：443
10。188。20。10：8001
所以實際儲存的對映關係會包含上面 3 部分內容，這樣做的目的是保證網路安全。想象如下例子，終端 192。168。1。2：8080 透過路由器使用 10。188。20。10：8000 訪問伺服器 A，建立 NAT 對映如果為 192。168。1。2：8080——>10。188。20。10：8000，那麼如果有人向 10。188。20。10：8000 傳送資料就會轉發到 192。168。1。2：8080，這樣就會導致內網的服務被外部隨意訪問，所以 NAT 對映會記錄目標地址。當然，由於 NAT 有多種型別，NAT 對映也會存不同，更多內容可參考維基百科或者 WebRTC 網路基礎 九、第二節 NAT 打洞原理，下表進行一個簡單的歸納。
5。1 NAT 打洞
由於 NAT 有上面 4 種類型，所以兩個裝置要建立 P2P 連線就要使用不同的方式。
5。1。1 完全錐型 NAT
完全錐型是非常簡單的 ，左邊是內網的主機，它有自己的內網 IP 地址和埠 ，透過防火牆之後，它形成一個外網的 IP 地址，那麼外網的主機要想與內網的主機進行通訊的時候，首先要由內網的主機向外傳送一個請求，請求外網中的其中一臺主機，這樣會形成的結果就是它會在 NAT 服務上打一個洞，這樣會形成一個外網的 IP 地址和埠。 形成了外網的 IP 地址和埠之後，
其他的主機只要獲得了這個 IP 地址和埠它都可以向它傳送資料
。並且可以順利的透過防火牆傳送給內網的主機。這樣就可以進行通訊了，這是完全錐型，也是最好穿越的一種 NAT 型別。但是安全性就差很多。
NAT內網計算機IP地址為10。0。0。1，其在埠 8000 上收發訊息，對映到 NAT 上的外部IP和埠為 202。123。211。25：8000。 這樣Internet 上的任何人都可以向 NAT 上的內網 IP： 埠傳送資料包，這些資料包將被傳遞到 10。0。0。1：8000 的客戶端機器。
5。1。2 地址限制錐型 NAT
它的安全性好一些，它會在防火牆上形成一個
五元組
，即內網主機的 IP 地址和埠、對映後的公網 IP 地址和埠、請求的主機 IP 地址。他們首先有一個公共的步驟，第一步就是要先由內網的主機向外網傳送一個請求，在這個防火牆上或者 NAT 服務上形成一個對映表，那形成之後外網的主機就可以和內網的主機進行通訊了。
客戶端向伺服器 1（IP - 192。248。22。100）傳送資料包，然後NAT將客戶端的10。0。0。1：8000對映到外網的202。123。211。25：8000， 現在 server1 可以將資料包傳送到目的地。
但是，NAT 將阻止來自伺服器 2（IP - 192.248.22.200）的資料包，直到客戶端向伺服器 2 的 IP 地址傳送資料包
。 一旦客戶端將資料包傳送到伺服器 2，伺服器 1 和伺服器 2 都可以將資料包傳送回客戶端。
5。1。3 埠限制錐型 NAT
埠限制型就更加嚴格一些了，不光是對 IP 地址，還要對埠做限制，所以在防火牆上就形成了
六元組
，不光有內網的 IP 地址和埠、對映後的公網的 IP 地址和埠、還有你請求的主機的 IP 地址和埠。
如果客戶端將資料包傳送到 192。248。22。100：10100（包含IP 和埠），NAT 將只允許來自 192。248。22。131：10100 的資料包（到客戶端），它
丟棄
來自 192。248。22。131：10200（相同 ip 但不同埠）的資料包。
5。1。4 對稱型 NAT
對稱限制型就更加嚴格了，以前的型別是在防火牆上形成對映後的公網的 IP 地址是保持不變的，大家要找還是能找到它的，雖然不通，但是對於 這個對稱型它就不一樣了，它就發生了變化，不光是形成了一個 IP 地址和埠，而且還會形成多個，
對於每一臺主機都會形成一個不同的 IP 地址和埠對
。
如果客戶端從 10。0。0。1：8000 傳送資料到 server1，其外網地址被對映為 202。123。211。25：12345，而如果客戶端從同一個埠（10。0。0。1：8000）傳送到不同的 IP，則對映的外網地址也會不同（即外網地址被對映為 202。123。211。25：45678）。
server1 只能響應自己的對映，server2也 只能響應自己的對映，兩者無法公用
。 如果任何一個地址嘗試傳送到另一個對映的 IP：port，這些資料包將被丟棄。
5。2 WebRTC 打洞這麼複雜麼？
WebRTC 本身就已經實現 NAT 打洞功能，只需要連線的雙方交換了網路埠和 IP 之後，WebRTC 就會自動進行打洞。WebRTC 使用一個叫做互動式連線設施（
ICE，Interactive Connectivity Establishment，即互動式連線建立
）協議框架，ICE 整合了 STUN 與 TURN。STUN 是用來探測終端 NAT 型別、IP 和埠的服務，WebRTC 獲取到 NAT 型別、IP 和埠後就會觸發 candidate 事件，然後連線雙方交換 IP 與埠，開始打洞。如果打洞失敗，那麼就會使用 TURN 伺服器轉發流量。
由於 WebRTC 提供了 ICE，所以使用非常簡單，只需在 new RTCPeerConnection 時傳入 iceServers 引數即可。googel 提供了免費的 STUN 伺服器去幫助打洞，也可以自己架設伺服器。
const pc = new RTCPeerConnection（{ // 可以傳入多個 stun 伺服器或者 turn 伺服器 iceServers： ［ { url： ‘stun：stun。l。google。com：19302’ }， { url： ‘stun：stun1。l。google。com：19302’ }， { url： ‘stun：stun2。l。google。com：19302’ }， { url： ‘stun：stun3。l。google。com：19302’ }， { url： ‘stun：stun4。l。google。com：19302’ }， ］，}）；
6。WebRTC vs WebSocket 區別
用途區別
WebSocket允許瀏覽器和Web伺服器之間進行全雙工通訊。
WebRTC允許兩個瀏覽器之間的全雙工通訊。
2。 協議區別
WebSocket使用TCP協議
WebRTC使用UDP協議
3。 流量路徑
WebSocket瀏覽需要經過伺服器
WebRTC是直接連線，瀏覽不會經過第三方伺服器，是一個去中心化的架構模型，簡單說就是省頻寬。
4。 實時性
WebSocket延遲高（不是直接連線）
WebRTC延遲低
通常WebRTC會與WebSocket配合使用，WebSocket的作用主要是用來交換客戶端的SDP與網路資訊，Websocket傳輸的內容與真正通訊資料無關，只是協助WebRTC建立連線。
參考資料
https：//medium。com/orion-innovation-turkey/webrtc-in-a-nutshell-ep-ii-ca8cb33f8ff3
https：//datatracker。ietf。org/doc/html/rfc4566
https：//medium。com/rahasak/network-address-translation-nat-df84dc1cb06c
https：//developer。mozilla。org/en-US/docs/Web/API/RTCDataChannel
https：//caniuse。com/？search=WebRTC
https：//www。jianshu。com/p/1022f559a805
https：//zhuanlan。zhihu。com/p/421503695
https：//github。com/nashaofu/webrtc-demo
https：//blog。csdn。net/xyphf/article/details/107297616
https：//medium。com/av-transcode/what-is-webrtc-and-how-to-setup-stun-turn-server-for-webrtc-communication-63314728b9d0
https：//webrtc。ventures/2020/12/webrtc-signaling-stun-vs-turn/
