ICE 简介
ICE 是用于 UDP 媒体传输的 NAT 穿透协定（适当扩大也能够反对 TCP），它须要利用 STUN 和 TURN 协定来实现工作。
STUN 协定提供了获取一个内网地址对应的公网地址映射关系（NAT Binding）的机制，并且提供了它们之间的保活机制。
TURN 协定是 STUN 协定的一个扩大，容许一个 peer 只应用一个转发地址就能够和多个 peer 实现通信。其本质是一个中继协定。
在 WebRTC 中，ICE 会在 SDP 中减少传输地址信息，利用这个信息进行 NAT 穿透及确定媒体流传输地址。
ICE Candidate
WebRTC 中的 ICE Candidate 是用来形容能够连贯的远端的根本信息，它至多包含（address，port，protocol）三元组，还有 Candidate 类型、用户名等。
WebRTC 将 Candidate 分成四种类型，且类型间存在优先级秩序，从高到低别离为 host、srflx、prflx 和 relay。
- host：从本机网卡上获取到的地址，一般来说，一个网卡对应一个地址。
- srflx（server reflexive）：从 STUN 服务器获取到的地址。
- relay：从 TRUN 服务器获取到的地址。
- prflx（peer reflexive）：在联通测试中从对端数据报文中获取到的地址。
其中，srflx 和 prflx 地址可能是一样的，但获取的路径不一样。
ICE 的根本流程
ICE 的根本流程有三步：收集 Candidate，替换 Candidate，按优先级尝试连贯。
收集 Candidate
WebRTC 在进行 NAT 穿透时（也就是俗称的打洞），首先会收集 Candidate。客户端会按程序先获取本地的 host 地址，而后从 STUN 服务器获取 srflx 地址，再从 TRUN 服务器获取 relay 地址。
替换 Candidate
客户端收集到的这些地址会写到 SDP 报文中，之后通过信令零碎将它们发送给对端。对端收到这些 Candidate 后，会与本地的 Candidate 组成 CandidatePair。当然，这种组合也是有规定的，比方传输协定雷同的 Candidate 能力组成 CandidatePair。
须要阐明的是 WebRTC 中的 Candidate 替换是应用的 trickle 形式，也就是边收集边替换。
按优先级尝试连贯
WebRTC 会将 CandidatePair 按优先级排序，而后依照这个程序去进行连通性测试。如果有能够连通的 CandidatePair 就进行尝试，将它作为数据传输地址。后续开始建设连贯，胜利后就能够利用这个通道传输音视频数据了。
总结
- WebRTC 的 ICE 会抉择出最好的连贯通道来传输音视频数据。
- WebRTC 的连通率简直是 100%，因为即便无奈实现 P2P 的连贯，最终也能通过中继（relay）的形式来实现端到端的连贯。
- 那么 WebRTC 具体是怎么利用 ICE 协定来实现 P2P 的 NAT 穿透的呢？请关注后续文章。