ICE（交互式连接建立）

什么是 ICE？

交互式连接建立（Interactive Connectivity Establishment，简称 ICE）是 WebRTC 用来在浏览器或设备之间建立直接连接的框架，即使面对 NAT（网络地址转换）和防火墙等网络障碍。可以把 ICE 想象成一个智能协商者，它同时尝试多种连接策略，找到两个对等点之间的最佳路径。

ICE 本身不传输媒体——它是一个确定如何连接两个设备的过程，一旦 ICE 成功，实际的 WebRTC 连接就会使用 ICE 发现的路径传输媒体（视频、音频、数据）。

ICE 标准化于 RFC 8445，对于 WebRTC 实现浏览器到浏览器通信的承诺至关重要。没有 ICE，大多数 WebRTC 通话都会失败，因为参与者通常位于阻止直接连接的 NAT 路由器后面。

为什么需要 ICE

ICE 解决的核心问题：大多数设备没有其他人可以直接访问的公网 IP 地址。

你家里的笔记本电脑有一个私有 IP，如 192.168.1.100。你的路由器（NAT）在访问互联网时将其转换为公网 IP。但互联网上的某人无法发起到 192.168.1.100 的连接——他们只能访问路由器的公网 IP，而路由器不知道将传入的 WebRTC 数据包发送到哪里。

再加上阻止意外传入连接的防火墙，你就有了连接失败的配方。ICE 系统地找到通过这些障碍的可用路径。

ICE 工作原理：分步详解

1. 收集 ICE 候选

当 WebRTC 连接开始时，每个对等点收集"候选"——潜在的连接路径。ICE 发现三种类型的候选：

主机候选：你设备的本地 IP 地址（如 WiFi 的 192.168.1.100，VPN 的 10.0.0.5）。这些仅在两个对等点位于同一本地网络时才有效
服务器反射候选：从互联网看到的你的公网 IP 地址，通过查询 STUN 服务器发现。这是路由器的公网 IP 以及它为此连接分配的端口
中继候选：TURN 中继服务器上的地址，如果直接连接失败将转发你的流量。这是始终有效但会增加延迟的降级方案

浏览器自动发现所有可用候选并确定优先级（主机 > 服务器反射 > 中继）。

2. 通过信令交换候选

每个对等点的候选通过信令通道（通常是 WebSocket 或 HTTPS）发送给另一个对等点。这种信令发生在 WebRTC 之外——你需要自己构建或使用服务。

交换包括每个候选的 IP 地址、端口、协议（UDP/TCP）和优先级。现代 WebRTC 使用"涓流 ICE"，随着候选被发现逐步发送它们，而不是在开始协商之前等待所有候选。

3. 连接性检查

一旦对等点拥有彼此的候选，ICE 执行连接性检查。它将本地候选与远程候选配对，并通过发送 STUN 绑定请求测试每对。

例如，如果你有 3 个候选，远程对等点有 3 个候选，ICE 测试最多 9 对（3 × 3）。测试并行运行，按候选质量优先（直接连接优先于中继连接测试）。

4. 选择最佳路径

ICE 识别哪些候选对成功连接，并根据以下条件选择"最佳"路径：

最低延迟
候选类型优先级（优先直接连接而非中继）
连接可靠性

通常，选定的路径是最直接的可能路由。如果两个对等点在同一本地网络上，将是直接 LAN 连接。如果他们在互联网上且 NAT 宽松，将是通过公网 IP 的点对点连接。如果 NAT 严格，将通过 TURN 中继。

5. 连接建立

一旦最佳候选对成功，ICE 宣布成功，WebRTC 开始通过该路径发送媒体。整个过程通常需要 2-5 秒，尽管涓流 ICE 可以在 1 秒内建立连接。

连接成功率

在实际部署中：

75-85% 的连接：通过使用服务器反射候选（STUN）的直接点对点路径成功
15-25% 的连接：由于对称 NAT、严格防火墙或企业网络需要 TURN 中继
<1% 的连接：完全失败，通常是由于企业代理完全阻止 WebRTC

这些数字突出了为什么 TURN 服务器至关重要——尽管成本高昂，它们确保即使直接路径失败连接也能成功。

涓流 ICE：现代优化

传统 ICE 等到所有候选收集完成后才开始连接性检查——通常需要 5-10 秒。

涓流 ICE 现在是 WebRTC 的标准，随着候选被发现逐步发送它们。一旦找到主机候选，它就被发送给远程对等点并开始连接性检查——即使 STUN 和 TURN 查询仍在运行。

这显著减少了连接建立时间。在最佳条件下（本地网络或宽松 NAT），连接可以在 500 毫秒内建立。

ICE 重启

ICE 支持在不结束通话的情况下重新启动候选收集和选择过程。这发生在：

网络条件变化（你从 WiFi 切换到蜂窝网络）
连接降级或失败
参与者在网络间移动

ICE 重启无缝地重新建立最佳路径，不会中断用户体验。视频可能会短暂冻结，但通话继续。

挑战和局限

对称 NAT

最有问题的 NAT 类型。对称 NAT 为每个目的地分配不同的端口映射，使 STUN 无效。只有 TURN 中继有效，增加了延迟和服务器成本。

企业防火墙

一些企业网络阻止所有 UDP 流量或只允许特定端口，破坏 WebRTC。ICE 可以降级到 TCP，但并非所有网络都允许这样做。

候选爆炸

具有多个网络接口（WiFi、以太网、VPN、蜂窝网络）的设备会生成许多候选。测试所有配对需要时间和带宽。现代实现使用启发式方法跳过不太可能的配对。

隐私考虑

ICE 暴露本地和公网 IP 地址，引发隐私问题。一些浏览器现在限制候选暴露或需要用户权限，这可能影响连接成功率。

实践中的 ICE

作为开发者或用户，你很少直接与 ICE 交互——WebRTC 自动处理它。但理解 ICE 有助于你：

知道为什么 STUN 和 TURN 服务器是必需的基础设施
理解为什么某些连接在严格网络中失败
通过检查 ICE 候选类型调试连接问题
估算基础设施成本（15-25% 的通话需要 TURN 带宽）

总结

ICE 是 WebRTC 的无名英雄。它是你可以点击链接并立即与世界各地的人开始视频通话的原因，尽管你们都在 NAT 路由器和防火墙后面。

通过系统地尝试多种连接策略——直接本地连接、通过 STUN 的点对点、通过 TURN 的中继——ICE 最大化了连接成功率，同时最小化了延迟。该框架在优先考虑更快路径和适应网络条件变化的智能性，使其对可靠的实时通信至关重要。

没有 ICE，WebRTC 只能在同一本地网络上或具有非常宽松网络配置的用户之间工作——使基于浏览器的视频通话对绝大多数互联网用户来说不切实际。