[知识篇]WebRTC - ICE(STUN/TURN)

新手入门，如有错误，欢迎指正～～～

系列文章同步更新於部落格

在整个 RTCPeerConnection 建立连线的步骤中，如果要到正式环境使用的话，必定会遇到网路(NAT)的问题，也就是在进行 SDP offer/answer 前，必须先透过 ICE 选取到适合的 candidate 後才能开始进行的原因。

其 ICE 查找到时确定能连接时 RTCPeerConnection.iceGatheringState 属性就会转为 complete，接续进行 SDP offer/answer 的步骤。

WebRTC 就是透过 ICE 来处理实际网路(NAT)的复杂性。

而网路上有许多文章都讲得不错，在这里只统整主要用途与参考的资料。

ICE

为了解决NAT的复杂性，ICE 将会尝试找到连接对方的最佳途径。

而再进行查询时的会有几个步骤：

1. ICE agent 在操作系统中查询本地 IP 地址。
2. 失败的话，则 ICE agent 会查询外部 STUN 服务器 以检索对等方的 public IP 和端口。
3. 再失败的话，则 ICE agent 会将 TURN 服务器 做为最後的选择。如果对等连接失败，则数据将通过指定的中介进行中继。

换句话说：

• STUN server 是用来获取外部地址的。
• TURN server 是用来在直接连接（p2p）失败的情况下进行中继数据流量的。(相对的这样其实就不算是p2p了，中间还是要透过中继server帮我们传递数据。）

在使用上，ICE server 的 URL 加进 RTCPeerConnection 参数中（如下):

const ice = {
  "iceServers": [
    {"url": "stun:stun.l.google.com:19302"},
    // {"url": "turn:turnserver.com", "username": "user", "credential": "pass"} //范例
  ]
};

const peer = new RTCPeerConnection(ice);

范例是使用 google 提供的公用STUN server，而turn server的话google也有提供open source project: coturn 可以参考看看～

为了解决 NAT 的复杂性(如下):

撷取自MDN

很好地呈现了，最终经过 ICE 处理後的样貌。

总结

上述是了解一下ICE(STUN/TURN)的作用，方便实作上遇到问题时能够找到问题点做更深入的研究，
网上蛮多资源再说明ICE(STUN/TURN)相关可供参考：

• 真实世界的WebRTC
• WebRTC.org
• 30-29之 WebRTC 的 P2P 打洞术 ( ICE )

参考

• coturn
• webrtc
• 真实世界的WebRTC
• 30-29之 WebRTC 的 P2P 打洞术 ( ICE )
• MDN