Candidate种类与优先级

要了解 ICE 的整个实现过程，我们还是要从 Candidate 的优先级说起。ICE 中使用的 Candidate 具有优先级次序，由高到低分别为 host、srflx、prflx、relay。WebRTC 进行一对一音视频通信时，就是按照这个次序尝试建立连接的，如图 6.1 所示。

Figure 1. 图6.1 WebRTC ICE Candidate优先级

在图 6.1 中，有 A、B、C 三个终端。下面看一下任意两个终端之间是如何建立连接的。假设 A 与 B 要进行通信，按照一对一通信的原则，两个终端都要先与信令服务器建立连接。之后双方通过媒体服务器交换信息进行媒体协商，并在媒体协商时收集各自的 Candidate。根据 Candidate 的收集次序，WebRTC 会先收集 host 类型的 Candidate，并通过信令服务器交换给对端。当收到对端的 Candidate 后，WebRTC 在其内部生成 CandidatePair，这样终端就可以利用 CandidatePair 尝试建立 socket 连接了。在本例中，由于 A 和 B 是在同一局域网下，因此它们通过 host 类型的 Candidate 可以在内网建立起连接。当连接成功后，音视频数据就可以源源不断地从一方流向另一方了。

如果 A 与 C 通信，因为不在同一局域网内，双方尝试 host 型 Candidate 连接时会失败。不过，在 A 与 C 尝试连接时，各端 Candidate 的收集工作并未停止。Candidate 收集线程还在收集其他类型的 Candidate，如从 STUN/TURN 服务器收集 srflx 和 relay 类型的 Candidate（图 6.1 中的步骤❸）；当收集到 srflx 类型的 Candidate 时，ICE 会尝试 NAT 打洞（关于 NAT 打洞的过程将在 6.3 节中做详细介绍），如果打洞成功，则 A 和 C 会通过 P2P 的方式传输数据；如果打洞失败，A 和 C 则会通过 TURN 服务器中转数据。

B 与 C 通信的逻辑同 A 与 C 通信的逻辑是一样的，这里就不再赘述了。从上面的描述中可以总结出以下两点信息：

WebRTC 的 ICE 机制会选择最好的链路传输音视频数据，即如果通信的双方在同一网段内，则优先使用内网链路；如果通信的双方不在同一网段，则优先使用 P2P；当以上方式都无法连通时，则使用 relay 服务进行中转。
ICE 的连通率几乎可以达到 100%。在内网和 P2P 无法连通的情况下，它还可以通用中继的方式让彼此连通，从而大大提高了 WebRTC 的连通率。

通过上面的分析，你现在应该对 WebRTC 在网络处理方面的策略略知一二了。WebRTC 中的 ICE 既考虑了数据传输的效率，又考虑了网络的连通率，同时实现起来还很简单。

WebRTC 中的 srflx（Server Reflexive Candidate）和 prflx（Peer Reflexive Candidate）是两种不同类型的 ICE 候选地址，它们在 NAT 穿透和网络连接建立过程中扮演不同角色。

Table 1. 定义与生成机制
类型	定义	生成方式
srflx	通过 STUN/TURN 服务器获取的 NAT 映射地址。客户端向服务器发送请求后，服务器返回客户端在 NAT 上的公网 IP 和端口。	客户端主动向 STUN/TURN 服务器发送请求，服务器通过响应中的 XOR_MAPPED_ADDRESS 字段告知客户端的公网地址
prflx	通过直接与对端通信发现的 NAT 映射地址。在对端响应 ICE 连接请求时，携带对端 NAT 分配的新地址。	在 ICE 连接检查阶段，客户端收到对端返回的 STUN 请求响应，发现对端 NAT 分配的新地址并生成 prflx 候选。

Table 2. 使用场景与目的
类型	主要用途	适用条件
srflx	用于客户端向服务器通告自己的公网地址，以便对端直接通过该地址建立连接。	需要 STUN/TURN 服务器支持，适用于大多数 NAT 环境（如对称型、端口受限型 NAT）
prflx	用于优化连接路径。当直接连接失败时，通过发现对端的新 NAT 地址建立更优路径。	要求对端 NAT 类型允许接收来自客户端的请求（如 Full Cone NAT），且 ICE 连接检查阶段触发。