17、ICE连接优化：ICE候选者优先级、连接选路策略、NAT穿透的失败处理
ICE，全称 Interactive Connectivity Establishment。说白了，它就是 WebRTC 里负责「打通网络」的那位老大哥。没有它，你的音视频数据就只能困在本地，哪儿也去不了。
我刚开始接触 ICE 时，觉得它就是个黑盒子。候选者收集、优先级排序、连通性检查……一堆概念砸过来。后来踩了不少坑，才慢慢摸清它的脾气。今天咱们就把它拆开，看看里面到底是怎么运作的。
ICE 候选者：你的网络「名片」
ICE 候选者，其实就是你的设备在网络中的各种「身份」。每个身份都对应一个 IP 地址和端口号。WebRTC 会收集这些候选者，然后发给对端。
候选者分三种类型：
- Host 候选者：本机网卡的 IP。比如你电脑的局域网 IP 192.168.1.100。这是优先级最高的，因为不走任何 NAT 或中继，延迟最低。
- Srflx 候选者：经过 STUN 服务器反射出来的公网 IP。说白了，就是你的路由器在公网上的「门牌号」。如果 Host 候选者连不上，就靠它了。
- Relay 候选者：通过 TURN 服务器中转的地址。这是最后的保底方案。当网络环境极其复杂（比如对称 NAT），前两种都失效时，数据就得走 TURN 服务器绕一圈。
我记得有一次做跨国会议项目，用户反馈「连不上」。排查后发现，他的网络是严格的对称 NAT，Host 和 Srflx 候选者都失败了。最后强制走 TURN 才解决。嗯，从那以后我养成了一个习惯：永远不要假设用户的网络环境是理想的。
候选者优先级：谁先上？
ICE 会给每个候选者算一个优先级。数值越高，越优先被尝试连接。这个优先级不是随便给的，它有一套计算公式。
公式长这样：
priority = (2^24) * type_preference + (2^8) * local_preference + (2^0) * component_id其中：
- type_preference：类型偏好。Host 是 126，Srflx 是 100，Relay 是 0。你看，Host 天生就比 Relay 高出一大截。
- local_preference：本地偏好。如果你有多个同类型候选者（比如两个网卡），可以用这个来区分。
- component_id：组件 ID。RTP 是 1，RTCP 是 2。一般 RTP 的优先级会略高一点。
我个人的习惯是，在调试时打印出每个候选者的优先级。这样能快速判断出「哪个候选者被优先选中了」。如果发现 Relay 候选者优先级异常高，那多半是代码里 type_preference 设置错了。
连接选路策略：ICE 的「决策树」
候选者收集完了，优先级也排好了。接下来就是连接选路。ICE 会按照优先级从高到低，依次尝试每一对候选者组合（本地候选者 + 远端候选者）。
这个过程叫「连通性检查」。说白了，就是发一个 STUN 绑定请求，看对方能不能收到并回复。如果能，这条路径就通了。
ICE 的选路策略其实很简单：谁先连通，就用谁。但这里有个细节：ICE 不会只试一对就停下来。它会同时尝试多对候选者，但最终只会选择最先连通的那一对。
你想想看，如果只试一对，万一它不通，用户就得干等好几秒。同时尝试多对，能大大缩短连接建立时间。
我曾经在一个项目中遇到过这样的问题：Host 候选者明明能通，但 ICE 却选了 Srflx。排查后发现，是 Host 候选者的优先级计算有 bug，导致它比 Srflx 还低。修复后，连接速度提升了 30%。
NAT 穿透的失败处理：别慌，有预案
NAT 穿透是 ICE 最核心的挑战。说白了，就是你的设备在局域网里，对方的设备也在另一个局域网里。你们俩怎么找到对方？
ICE 的应对策略分三步：
- 先试 Host：如果你们在同一个局域网，直接连。这是最快的。
- 再试 Srflx：如果不在同一个局域网，就通过 STUN 获取公网 IP，尝试穿透 NAT。大部分情况下，这步能成功。
- 最后用 Relay：如果前两步都失败了，就通过 TURN 服务器中转。这是最慢的，但也是最后的保障。
但 NAT 穿透失败的情况其实很常见。比如：
- 对称 NAT：这种 NAT 会为每个连接分配不同的端口。STUN 拿到的端口，和实际通信用的端口不一样。Srflx 候选者就失效了。
- 防火墙拦截：有些防火墙会拦截 UDP 流量。STUN 和 TURN 都走 UDP，一旦被拦，就全完了。
- TURN 服务器不可用：TURN 服务器挂了，或者带宽不够，Relay 候选者就形同虚设。
遇到这些情况怎么办？我总结了几条经验：
- 备选 TURN 服务器：至少配置两个 TURN 服务器，一个主用，一个备用。我曾经遇到过主 TURN 服务器所在机房断电，备用服务器自动顶上，用户几乎无感知。
- 启用 ICE 重启：如果连接失败，可以触发 ICE 重启。重新收集候选者，重新尝试。有时候网络环境会变化，重启后就能连上。
- 降级到 TCP：如果 UDP 被防火墙拦截，可以尝试用 TCP 走 TURN。虽然延迟会高一些，但至少能通。
- 设置超时和重试：连通性检查不能无限等下去。我一般设置 5 秒超时，超时后重试 3 次。如果还不行，就宣告失败。
ICE 连接优化的核心逻辑
下面这张图，是我自己整理的 ICE 连接优化核心逻辑。它涵盖了候选者收集、优先级排序、连通性检查、失败处理的全流程。
从图中可以看到，ICE 连接优化是一个闭环。失败后不是直接放弃，而是通过 ICE 重启、降级 TCP、切换 TURN 等方式重新尝试。这个循环机制，保证了即使在最恶劣的网络环境下，连接也能最终建立起来。
总结
ICE 连接优化，说白了就是三件事：收集候选者、排序优先级、处理失败。每一环都有很多细节，但核心思想只有一个：用最快的路径建立连接，同时准备好兜底方案。
我个人觉得，ICE 最容易被忽视的地方就是失败处理。很多开发者只关注「怎么连上」，却很少想「连不上怎么办」。但恰恰是这些「连不上」的场景，决定了用户体验的下限。
嗯，今天就聊到这儿。希望这些经验能帮你少踩几个坑。