前幾篇文章中，簡述了連接建立中的 NAT 穿越問題以及使用 STUN 和 TURN 來解決這些問題。而在這篇文我們來進一步介紹 WebRTC 在連線上最終的解決方案 ICE 協議。

WebRTC 使用 ICE 協議進行打洞，該協議整合 STUN 和 TURN 來獲取 IP 地址。

ICE 協議 - Interactive Connectivity Establishment

ICE 用於處理 NAT 穿越和防火牆問題同時使用 STUN 和 TURN 來獲取 IP 地址和 port （稱為候選者），這些候選者(RTCIceCandidate )可以有多個，連線時發起者與加入者都會創建多個候選者進行連接檢查並配對。

以下是 ICE 的工作步驟：

1. 搜集候選者：

   A和B分別向 STUN 發送請求，STUN 會回復他們的公共 IP位置及 port ，這些是候選者。

2. 交換候選者：

   A 將自己的候選者列表發送給B，而B將自己的候選者列表發送給A。這些列表包含了它們可用的連接方式，就像兩人互相告訴對方自己的聯絡方式。

3. 檢查連接：

   A 和 B 在列表中依照協議類型、地址類型、連接性類型等方式進行挑選，嘗試進行連接、發送測試消息，就像打電話並確保對方可以聽到。

4. 完成連接：

   當 A 和 B 完成連線~

RTCIceCandidate

以其中一個**RTCIceCandidate** 舉例，可以看到 candidate 中有許多候選人的資訊

1. 候選者（Candidate）：一個 RTCIceCandidate 包含了用來建立連接的候選者的資訊。通常包括IP地址、端口號、優先級、協議類型等信息。
2. iceCandidate 物件：在 WebRTC 中，當瀏覽器需要與對等方建立連接時，它會搜集自己的候選者信息，並將這些信息封裝為 RTCIceCandidate 物件。
3. 傳輸候選者：瀏覽器會將自己的 RTCIceCandidate 物件傳送給對等方，以便對等方知道如何連接到它。
4. iceCandidate 的 JSON 表示：RTCIceCandidate 可以轉換為 JSON 格式，方便傳輸。
5. SDP 中的 iceCandidate：RTCIceCandidate 通常嵌入在 Session Description Protocol（SDP）中，以便在 WebRTC 會話中進行交換。SDP 包含了有關通訊的描述，包括媒體類型、編解碼器、候選者等信息。

以上花了一些篇幅介紹 RTCPeerConnection 的概念~雖然在這次時做中不會用到傳輸文件的功能但還是可以了解一下這個重要的API，所以下一篇會來聊聊 RTCDataChannel ~

參考資料

RTCIceCandidate - Web APIs | MDN (mozilla.org)
WebRTC ICE介绍 - 知乎 (zhihu.com)
30-29之 WebRTC 的 P2P 打洞術 ( ICE ) - iT 邦幫忙::一起幫忙解決難題，拯救 IT 人的一天 (ithome.com.tw)