初探 WebRTC — 手把手建立線上視訊 (2)
前言
本系列主要介紹使用 WebRTC 搭配 Socket.io 建立一對一的視訊。上禮拜提到如何在本地端取得影像聲音，在講解程式碼前，會有許多的專有名詞…所以這回打算講解 WebRTC 的實作方式。
連結：
1. 初探 WebRTC — 手把手建立線上視訊 (1)
2. 初探 WebRTC — 手把手建立線上視訊 (2)
3. 初探 WebRTC — 手把手建立線上視訊 (3)目錄
- 取得裝置
- 連線方式
- 輪詢
- WebSocket
- P2P - 交換住址 ( SDP )
- 真・交換住址 ( ICE Candidate )
- NAT 是什麼
- NAT 怎麼運作
- NAT 類型
- NAT 打洞
- ICE
取得裝置
在取得完本地影像聲音後，我們可以透過 getTracks() 來取得影像聲音流，並透過 label 來查看裝置名稱。
除了裝置名稱外，我們還可以使用屬性內的
enabled來切換靜音。
連線方式
在講到 WebRTC 連線方式前，我們要先來了解什麼是輪詢 ( Polling ) 以及 WebSocket。
輪詢
每隔一段時間由 Client 端主動詢問 Server，缺點是當有訊息時不能即時知道，又或是當詢問後沒有訊息就等於白問了一次。
WebSocket
當 WebSocket 出現後，只要 Client 端初始化時連線到 Server 端，並且持續連線的話，就能實現雙向溝通，網頁常見的聊天室就是使用 WebSocket 服務。
P2P
Peer to Peer 點對點的簡寫，也就是 WebRTC 所採用的連線方式。當 P2P 連線建立後，就能讓雙方 Client 端自己溝通。但但但…建立連接前，如果不知道對方住址，就需要透過 Server 來幫忙傳遞雙方住址。這時的 Server 我們稱為 Signaling Server，幫忙傳遞訊號的 Server，很好記吧！
另外要提的是，WebRTC 在這塊並沒有特別定義，不管你是用輪詢或是 WebSocket，只要能取得對方的住址就能建立連線！
交換住址
接下來我們要把鏡頭拉到我們傳給 Signaling Sever 的住址，也就是所謂的 SDP Session Description Protocol 。
SDP 內含了住址、媒體類型、傳輸協議等等，另外還分為 Offer 與 Answer 兩種類型，詳細內容可以參考最後的延伸閱讀。
所以大致會分為以下步驟 ( 使用 WebSocket 情境下 ) ：
- A 送出自己的 SDP，type 為
Offer Signaling Sever將 A 的 SDP 送至 B 處- B 收到後，也回傳自己的 SDP，type 為
Answer Signaling Sever將 B 的 SDP 回傳至 A 處- A 與 B 使用雙方的 SDP 建立 P2P 連線
真・交換住址
剛剛講到了使用 Signaling Sever 送出自己的 SDP，但…(還有啊？
根據不同情況，光是上述還不算是成立了真正的 P2P 連線。
謎之聲：難道是 真・P2P ( ?
這時候我們要有請 NAT 的進場了，拍手鼓掌 XD
NAT 是什麼
講 NAT 前…要先提到他被開發的起源：
大家都知道每台電腦在網路上都會有一個 IP 位置，但以前的人在開發 IPv4 時沒想這麼多，於是當所有 IP 都被使用光的時候怎麼辦？像是台灣的摩托車車牌，就從 6 碼新增到 7 碼。
雖然說也有位置較長的 IPv6 可以取代，但網路的發展速度是很快的，一樣會有一天被用完，這時候 NAT 就出現了。
NAT 可以讓一個區域的電腦共用 1 個 IP，所以也多了所謂的內網、外網。
共用 IP 後，NAT 擔起內外網位置轉換的責任…甚至還提高了安全性，但相對的也有一些缺點， Ex: 降低傳輸速率等等。也因為有了 NAT，在實現 P2P 連線上會相對麻煩！
NAT 怎麼運作
通常會有一張映射表，NAT 就查表並把內網 IP 轉成外網 IP 。
NAT 類型
NAT 分以下四種類型：
- Full Cone NAT 全錐型
只轉換 IP 與 Port，沒有受限非常自由。 - Address-Restricted Cone NAT 受限錐形
限制只有發過連線的外網 IP 能訪問。 - Port-Restricted Cone NAT 連接埠受限型
比上一個多了一個 Port 的限制。 - Symmetric NAT 對稱型
比上一個更加嚴格，根據不同的訪問位置，會轉換成不同的外網 IP，因此不能使用在 P2P 連接上。
而目前在 Mobile 端，使用 3G、4G 都是屬於 Symmetric NAT，只有連 wifi 才是前三種。
NAT 打洞
回到上方的問題，因為 NAT 是把內網轉為外網，那要怎麼知道自己的外網 IP 位置？這時候有兩種協定可以使用：
- STUN ( Simple Traversal of UDP Through NAT )
直翻就是：使用 UDP 簡單穿越 NAT，缺點在不支援Symmetric NAT。
我們可以透過詢問STUN Server來知道自己的位置。 - TURN Traversal Using Relay NAT
使用 Relay 穿越 NAT，當 STUN 不能使用時則會改用此中繼模式，這時候就不能算是 P2P，因為中間還透過了TURN Server來轉發封包。
ICE
上面講完兩種協定，接下來講 WebRTC 使用的是一個叫 ICE Interactive Connectivity Establishment的框架，他就是把上述兩種協定包進去。
而上圖的候選 IP，指的是 STUN Server 會根據你的主機，給予不只一組的可連線 IP，並且稱作 IceCandidate，當我們出去約會時總要有個備案對吧（？
在拿到 IceCandidate 後，就可以透過Signaling Sever 傳送給對方，雙方都取得後，才可以算是成立了 P2P 連線！
這邊提出一個新的問題：
為什麼送出 SDP 後還需要再次送出
IceCandidate？IceCandidate是必須的嗎？
這篇有提到，如果你是真的要 Client 端打 Client 端的話是必須的，除非你有一台 Server 可以做到類似 TURN Server 在做的事，又或者兩個裝置都存在於同個局部區網 ( LAN ) 就不需要。
最後我們可以看個流程圖：
後記
本篇比較多是講解 WebRTC 的實作方式，突然出現很多專有名詞應該會混亂，所以在這邊做一個總結，看完本篇後我們學到：
- 如何查看本地的影像聲音裝置，以及如何靜音。
- 輪詢、WebSocket、P2P 三種連線的運作方式。
Signaling Server在做啥、SDP 又是什麼，分為哪兩種類型。- NAT 是什麼，NAT 打洞以及 WebRTC 使用的 ICE 是什麼。
- 為什麼光是傳送 SDP 還不算是成立 P2P 連線。
延伸閱讀
30–27之 WebRTC 的 Signaling Server