10、ICE连接状态机：ICE候选者收集、连接检查、状态变化与重连机制
各位同学，今天我们来聊聊ICE连接状态机。说实话，这是WebRTC里最容易让人头晕的部分之一。我刚接触的时候，看着那一堆候选者类型和状态切换，脑子里全是问号。但搞懂了它，你就真正理解了WebRTC的底层通信逻辑。
10.1 ICE候选者收集：从本地到中继
ICE的第一步，就是收集候选者。说白了，就是找出所有可能的通信路径。我习惯把候选者分成三类：
- 主机候选者（Host）：本机网卡IP，比如192.168.1.100。延迟最低，但内网环境才有效。
- 反射候选者（Server Reflexive）：通过STUN服务器获取的公网IP。我在项目中遇到过，有些企业防火墙会拦截STUN请求，导致反射候选者收集失败。
- 中继候选者（Relay）：通过TURN服务器转发。成本高、延迟大，但它是最后的保底方案。
核心原则：ICE会优先选择延迟最低的候选者对。主机 > 反射 > 中继，这是默认的优先级顺序。
收集过程其实是个异步操作。你调用createOffer()之后，浏览器就开始默默收集候选者了。每个候选者会通过onicecandidate回调告诉你。嗯，这里要注意：回调可能触发多次，每次只带一个候选者，直到最后传一个null表示收集完毕。
// 典型的候选者收集流程
peerConnection.onicecandidate = (event) => {
if (event.candidate) {
console.log('收集到候选者:', event.candidate.candidate);
// 通过信令通道发送给对方
signalingChannel.send({
type: 'candidate',
candidate: event.candidate
});
} else {
console.log('候选者收集完毕');
}
};10.2 连接检查：谁先连上就用谁
候选者收集完成后，ICE就开始做连接检查了。这个过程我打个比方：你有一堆钥匙（候选者），要一把一把去试哪把能打开对方的门。每把钥匙试一次，就叫一次连接检查。
连接检查的核心逻辑是：
- 双方交换候选者列表后，形成候选者对（Candidate Pair）。
- 按优先级排序，从高到低依次发送STUN binding请求。
- 收到响应后，确认该路径可用，进入提名（Nomination）阶段。
- 提名成功后，选中的候选者对成为选定对（Selected Pair），开始传输媒体数据。
个人经验：我曾经调试过一个跨国的视频通话，连接总是要等5-6秒。后来发现是候选者对太多（双方都有多个网卡），ICE在逐个检查时浪费了时间。解决方案是限制候选者类型，只收集反射和中继，跳过主机候选者。
10.3 ICE状态机：一张图看懂所有状态
ICE连接状态机其实不复杂，就几个状态来回切换。我画了一张图，你看完就明白了：
这张图展示了ICE的完整生命周期。你想想看，从new开始，到completed结束，中间每一步都有明确的触发条件。我个人习惯在调试时监听iceConnectionState的变化，它能告诉我当前连接处于哪个阶段。
10.4 状态变化详解：每个状态代表什么
| 状态 | 含义 | 常见触发场景 |
|---|---|---|
| new | ICE代理创建，尚未开始收集 | 刚创建RTCPeerConnection时 |
| gathering | 正在收集候选者 | 调用setLocalDescription后 |
| checking | 正在执行连接检查 | 收到对方候选者后开始检查 |
| connected | 至少一条路径可用 | 连接检查成功，开始传输数据 |
| completed | 所有检查完成，选定最终路径 | 所有候选者对检查完毕 |
| failed | 所有路径都不可用 | 连接检查全部超时或失败 |
| disconnected | 连接中断，但可能恢复 | 网络波动、丢包严重 |
| closed | ICE代理关闭 | 调用close()或页面关闭 |
注意：disconnected和failed的区别在于，前者还有恢复的可能，后者已经彻底没救了。我曾经在弱网环境下调试，看到状态在connected和disconnected之间反复横跳，这就是典型的网络抖动。
10.5 重连机制：断网了怎么办？
WebRTC的重连机制，说白了就是ICE的自我修复能力。当检测到连接断开时，ICE不会立刻放弃，而是尝试以下步骤：
- 重新检查已有候选者对：可能是临时网络波动，重新发一次STUN请求试试。
- 重新收集候选者：如果网络环境变了（比如从WiFi切到4G），旧的候选者可能失效，需要重新收集。
- 重启ICE：如果前两步都失败，就调用
restartIce()，完全重新开始。
// 监听连接状态变化，触发重连
peerConnection.oniceconnectionstatechange = () => {
const state = peerConnection.iceConnectionState;
console.log('ICE状态变化:', state);
if (state === 'disconnected') {
console.log('连接断开，尝试恢复...');
// 等待几秒，看能否自动恢复
setTimeout(() => {
if (peerConnection.iceConnectionState === 'disconnected') {
console.log('未能自动恢复，重启ICE');
peerConnection.restartIce();
}
}, 3000);
} else if (state === 'failed') {
console.log('连接彻底失败，需要重建连接');
// 重新创建PeerConnection
createNewConnection();
}
};避坑指南：我曾经在实现重连时犯过一个错误——每次断开都立刻重启ICE。结果网络稍微波动一下，就频繁重启，反而导致连接更不稳定。后来我加了一个3秒的延迟，给ICE一点自我恢复的时间，效果好了很多。
10.6 实际项目中的ICE调优
最后分享几个我在项目中用到的ICE调优技巧：
- 限制候选者数量：如果双方都有多个网卡，候选者对数量会爆炸式增长。我一般只保留优先级最高的前10个候选者对。
- 设置ICE候选者策略：通过
iceCandidatePoolSize控制预收集的候选者数量，减少连接建立时间。 - 使用ICE提名模式：默认是
regular模式，但aggressive模式可以更快完成提名，适合对延迟敏感的场景。 - 监控ICE状态：在生产环境中，我会把
iceConnectionState和iceGatheringState上报到监控系统，方便排查问题。
嗯，ICE连接状态机的内容就这些了。你想想看，从候选者收集到连接检查，再到状态切换和重连，每一步都有它的设计意图。搞懂了这些，WebRTC的底层通信对你来说就不再是黑盒了。
公众号:蓝海资料掘金营，微信deep3321