WebRTC ICE 候选类型详解：对等反射候选者（Peer Reflexive Candidate）

1. 定义与核心作用

• 定义 ：
  prflx（Peer Reflexive Candidate）是在 ICE 检查（Connectivity Checks）过程中，通过 对等端直接交互 动态发现的公网或 NAT 映射地址。它反映当前网络环境下对等端之间的实际通信路径。

• 核心作用：

  • 解决 NAT/防火墙穿透问题（尤其是对称型 NAT）。
  • 提供比 srflx（服务器反射候选者）更可靠的通信路径。

---

2. 与 srflx 的区别

特性	Peer Reflexive (prflx)	Server Reflexive (srflx)
发现方式	ICE 检查中动态发现（对等端交互）	通过 STUN 服务器预先查询
可靠性	更高（直接反映实时通信路径）	较低（可能因 NAT 类型变化失效）
依赖关系	不依赖 STUN/TURN（需 ICE 支持）	依赖 STUN 服务器
适用场景	对称型 NAT、动态端口分配等复杂网络	普通 NAT（如完全锥型、受限锥型）

---

3. 发现过程（ICE 检查阶段）

1. 初始候选收集：

   • 双方收集本地候选（host）、STUN 反射候选（srflx）和 TURN 中继候选（relay）。

2. ICE 检查（STUN Binding Request/Response）：

   • 对等端 A 向 B 的 srflx 地址发送 STUN 请求。
   • 若 B 的 NAT/防火墙修改请求源地址（如对称型 NAT），B 的响应会包含 A 的实际映射地址（即 prflx 候选）。
   • A 收到响应后，将此地址加入候选列表，并优先用于后续通信。

3. 优先级更新 ：

   ICE 协议为 prflx 分配比 srflx 更高的优先级（但低于 host）。

---

4. 为什么 prflx 更可靠？

• 动态适应性 ：

  在复杂网络（如对称型 NAT）中，srflx 可能因 NAT 端口随机分配失效，而 prflx 直接反映当前路径。

• 减少中间节点 ：
  prflx 通常绕过 STUN 服务器，降低延迟和丢包风险。

---

5. 实际示例

场景：对等端 A 和 B 处于对称型 NAT 后

1. A 的候选列表：

   • host: 192.168.1.100:5000
   • srflx: 203.0.113.5:6000（STUN 获取）

2. B 的候选列表：

   • host: 192.168.1.200:5001
   • srflx: 198.51.100.6:6001

3. ICE 检查过程：

   • A 向 B 的 srflx 地址（198.51.100.6:6001）发送 STUN 请求。
   • B 的 NAT 将请求源地址映射为 198.51.100.7:7000。
   • B 的响应包含 A 的实际映射地址 198.51.100.7:7000，A 记录为 prflx 候选。

4. 最终通信路径 ：

   A 和 B 通过 prflx 地址直接通信，绕过 STUN 服务器。

---

6. 调试与验证

• 查看候选类型 ：

  在 Chrome 中通过 chrome://webrtc-internals 查看 SDP 交换的候选地址，prflx 会标注为 typ prflx。

• 日志分析 ：

  WebRTC 日志示例：

  ICE candidate generated: candidate:123456789 1 udp 2113667327 198.51.100.7 7000 typ prflx generation 0