WebRTC ICE 连通性检查详解：对等端如何找到一条可用的网络路径

WebRTC 如何确定两个对等端之间的网络路径是否真正可用？这正是 ICE 连通性检查（ICE Connectivity Checks）的用武之地。

1. 为什么需要连通性检查？

假设用户 A 与用户 B 开始视频通话。

双方对等端收集 ICE 候选地址，并通过信令服务器交换它们。

用户 A 现在知道了若干可能联系到用户 B 的地址。然而，一个公布出来的 IP 地址和端口，并不能保证通信一定成功。

网络地址转换（NAT）、防火墙和网络限制，都可能阻止某条路径正常工作。

因此，WebRTC 需要在选定一条路径用于通信之前，先测试这些可能的路径。

2. 什么是 ICE 连通性检查？

ICE 连通性检查是一种用于确定某个候选地址对（candidate pair）是否能够通信的测试。

它使用 STUN Binding Request 与 Response。

把它想象成在假设某人可达之前，先敲一下他们的门。

以下是简化后的流程：

USER A                         USER B
             |                              |
             |                              |
             |   STUN Binding Request       |
             | ---------------------------> |
             |                              |
             |   STUN Binding Response      |
             | <--------------------------- |
             |                              |
             |                              |
             |      CHECK SUCCEEDED         |

当用户 B 收到请求，并且用户 A 收到相应的响应时，该检查就已经证明了这条路径上的连通性。

这些 STUN 消息是控制消息。它们并不是实际的音频或视频数据。

3. 什么是候选地址对？

在理解连通性检查的结果之前，我们需要先理解一个重要术语：候选地址对（candidate pair）。

一个 ICE 候选地址代表一个可能的网络端点。

一个候选地址对由以下两者组合而成：

来自用户 A 的一个本地候选地址（local candidate）。
来自用户 B 的一个远程候选地址（remote candidate）。

例如：

User A
Local candidate: 192.168.1.5:6000
                 |
                 | Connectivity check
                 |
                 v
User B
Remote candidate: 203.0.113.20:5000

WebRTC 会检查本地和远程候选地址的各种组合，以发现哪些路径是可用的。

它并不仅仅是检查某个 IP 地址是否存在。它检查的是，这两个候选地址端点是否能够进行通信。

4. 连通性检查何时开始？

让我们跟随一次典型的一对一通话流程。

第 1 步：拨号方创建 offer

用户 A 调用 createOffer() 来生成一个 SDP offer。

第 2 步：拨号方设置其本地描述

用户 A 调用 setLocalDescription(offer)。

如果 ICE 收集尚未启动，通常此时会启动。随着候选地址变得可用，拨号方可以将它们通过信令服务器发送给用户 B。

第 3 步：接收方创建 answer

用户 B 收到 offer，调用 setRemoteDescription(offer)，创建一个 answer，并通过 setLocalDescription(answer) 设置它。

接收方收集自己的 ICE 候选地址，并将它们传达给用户 A。

第 4 步：连通性检查开始

当所需的本地和远程候选地址信息变得可用时，ICE 就可以开始检查候选地址对了。

重要： WebRTC 不需要等待所有候选地址都收集完毕才开始连通性检查。借助 Trickle ICE，候选地址收集、信令和连通性检查可以重叠进行。

5. 当一次检查失败时会发生什么？

并非每一个候选地址对都能正常工作。

例如，由于 NAT 或防火墙阻止通信，一条直接路径可能会失败。

WebRTC 可以继续检查其他候选地址对。这些候选地址可能涉及主机候选地址（host candidates）、通过 STUN 发现的服务器自反候选地址（server-reflexive candidates），或通过 TURN 分配的中继候选地址（relay candidates）。

如果直接路径不可用，那么一条通过 TURN 中继的可用路径就可能让通话继续进行。

一次失败的连通性检查，并不自动意味着整个通话已经失败。

6. 成功的检查就意味着通话已连接吗？

不一定。

一次成功的检查证明了所测试的候选地址对已经演示了连通性。ICE 仍然需要通过其提名（nomination）和选择（selection）过程来选定一个合适的候选地址对。

在连接以及所需的安全设置准备就绪之后，音频和视频才能够在选定的路径上传输。

让我们区分一下各自的职责：添加到对话

WebRTC 概念	职责
SDP	描述会话与媒体参数
ICE 候选地址	描述可能的网络端点
连通性检查	测试候选地址对之间能否通信
ICE 提名与选择	确定使用哪个合适的候选地址对
DTLS-SRTP	为 WebRTC 媒体建立安全保护