WebRTC ICE 连通性检查详解：对等端如何找到一条可用的网络路径
内容提要
ICE通过STUN请求与响应检查候选地址对的连通性，以验证WebRTC对等端的网络路径。候选地址对由本地和远程候选地址组合而成。在Trickle ICE下，检查可与收集、信令重叠进行。检查失败不代表通话失败，可尝试其他路径；成功也需经提名与选择，再由DTLS-SRTP加密传输媒体。
延伸解读
连通性检查与候选地址对的关系
ICE 连通性检查的核心是测试候选地址对，即本地候选地址与远程候选地址的组合。文章指出，一个公布的 IP 地址和端口并不能保证通信成功，因为 NAT、防火墙等可能阻止路径。因此，WebRTC 会检查各种组合，以发现哪些路径真正可用。这解释了为什么检查的是端点对，而非单个地址。
Trickle ICE 如何影响检查时机
在 Trickle ICE 下，连通性检查不必等待所有候选地址收集完毕。文章说明，候选地址收集、信令和连通性检查可以重叠进行。这意味着检查可能在通话建立早期就开始，从而加快连接过程。读者应理解，这种重叠是 ICE 高效工作的重要机制。
检查失败与通话失败的区别
一次连通性检查失败，并不代表整个通话失败。文章举例，直接路径可能因 NAT 或防火墙受阻，但 WebRTC 可以继续检查其他候选地址对，包括主机、服务器自反或中继候选地址。如果直接路径不可用，通过 TURN 中继的路径仍可能让通话继续。因此，失败只是排除了某条路径。
成功检查后的提名与安全步骤
成功的连通性检查仅证明所测候选地址对可通信，并不等于通话已连接。文章强调，ICE 仍需通过提名和选择过程确定最终使用的候选地址对，之后还需建立 DTLS-SRTP 安全保护，音频和视频才能在选定路径上传输。这区分了检查、提名、选择和安全建立的不同职责。
Q&A
为什么WebRTC需要ICE连通性检查？
因为公布的IP地址和端口不能保证通信成功，NAT、防火墙和网络限制可能阻止路径正常工作，所以需要在选定路径前测试可能的路径。
ICE连通性检查具体是怎么做的？
它使用STUN Binding Request和Response来测试候选地址对能否通信。当一方收到请求并返回响应，另一方收到响应时，就证明该路径连通。
什么是候选地址对？
候选地址对由一个本地候选地址和一个远程候选地址组合而成，代表两个可能的网络端点。WebRTC会检查各种组合以发现可用路径。
连通性检查什么时候开始？
当所需的本地和远程候选地址信息变得可用时，ICE就可以开始检查。在Trickle ICE下，候选地址收集、信令和连通性检查可以重叠进行，无需等待所有候选地址收集完毕。
如果一次连通性检查失败了，通话会失败吗？
不一定。一次检查失败只意味着该候选地址对不通，WebRTC会继续检查其他候选地址对，如主机候选、服务器自反候选或中继候选。如果直接路径不可用，通过TURN中继的路径可能让通话继续。
成功的连通性检查是否意味着通话已经连接？
不一定。成功的检查只证明该候选地址对连通，ICE还需要通过提名和选择过程选定一个合适的候选地址对，之后才能传输媒体。
