什么是 ICE 协议？ICE 协议的工作原理及应用场景

你有没有遇到过视频通话突然中断、或者设备无法连接的情况？今天文章的主人公——ICE 协议有助于解决这一问题，它能为设备寻找最佳的通信方式，选择既快速又可靠的路径。本文将探讨该协议的定义、发展历程、核心组件、工作原理、优势、挑战及应用场景。

什么是 ICE 协议？

ICE 即 Interactive Connectivity Establishment（交互式连接建立）的简称，它通过寻找可能的路径、测试这些路径并选择最快的可用路径，帮助两台设备直接建立连接，即使它们位于防火墙之后。此外，即使在网络环境复杂的情况下，该协议也能确保连接顺畅可靠，不会出现延迟或断连。它会在后台默默运行，以确保设备之间能够尽可能高效地进行通信。

简单说：ICE 是一套”找路”机制。当两台设备想直接通信（比如视频通话），但中间隔着防火墙或路由器时，ICE 会自动探测所有可能的路径，测试哪条通，然后选最好的那条。整个过程在后台悄悄完成，用户完全感知不到。

ICE 协议的发展历程

据 Data Tracker 记载， ICE 协议于 2010 年 4 月首次作为 RFC 5245 发布。起初，采用该协议的系统寥寥无几，但如今 ICE 已成为 WebRTC 的必备组件。

早期背景

在 ICE 出现之前，VoIP 和视频通话等实时应用难以直接建立连接。这是因为网络地址转换（NAT）和防火墙会阻断点对点流量。为此，STUN、TURN、应用层网关和 MIDCOM 等方法应运而生，旨在解决这一问题。然而，这些方法只能部分解决问题，而且通常依赖于特定的网络配置，因此可靠性不高。

ICE 作为标准化方案

IETF MMUSIC 工作组创建了 ICE，作为一种利用 STUN 和 TURN 解决 NAT 穿越问题的统一方法。

首个正式规范：RFC 5245，2010 年 4 月发布，适用于采用 offer/answer 模型的 UDP 多媒体会话（例如 SIP）。

此外，RFC 5245 取代了早期的 NAT 文档（RFC 4091 和 4092），并成为 SIP 及相关协议的标准参考。

演变与现代应用

随着 WebRTC 实现浏览器实时通信，ICE 协议成为点对点连接的必备组件。ICE 最初用于 SIP，后来被 XMPP（Jingle）、RTSP、RTCWeb/WebRTC、HIP、RELOAD 以及其他实时或覆盖协议所采用。

此外，RFC 5245 已更新并由 RFC 8445（及相关 RFC 如 8839）取代，以实现规范的现代化。如今，ICE 在 WebRTC 通话及现代 VoIP/视频应用的后台运行。它有助于识别网络路径，并使点对点连接能够在 NAT 和防火墙的干扰下正常工作。

ICE 协议的核心组件

1. ICE 代理（Agent）

每台设备里都有一个 ICE 代理程序，负责找路、测路、选路。两端各有一个角色：

• 控制方（Controller）：做决定，选哪条路。
• 被控方（Controlled）：接受决定，跟着走。

2. 候选地址（Candidates）

ICE 会收集三种类型的”地址”作为候选：

• Host（本地地址）：设备自己的局域网 IP，如 192.168.x.x。
• Server-reflexive（服务器反射地址）：通过 STUN 服务器发现的公网 IP。
• Relayed（中继地址）：当直连失败时，通过TURN 服务器中转的地址。

3. 候选配对（Candidate Pairs）

ICE 把本地地址和每个远程地址配对。这些配对会进入一个检查清单，按顺序测试路径，成功的配对会被移至一个有效列表，该列表仅存储有效的路径。这样，ICE 就能知道哪些连接可以安全使用。

4. 连通性检测

ICE 会向每对节点发送 STUN 消息，以确定数据是否可以双向流动。部分检查会自动启动；其他检查则在收到来自对端的消息时启动。此外，为了避免重复工作，ICE会先冻结一些节点对，仅在类似路径成功时才进行测试。这样既节省了时间，又避免了测试可能失败的路径。

5. 优先级排序 & 最终选路

ICE 会对路径进行排序，优先使用直接路径。测试成功后，控制代理会指定最佳路径用于传输数据。只有选定的路径才会传输数据，其余路径则会停止传输。因此，如果网络发生变化，ICE 可以继续传输或切换路径，从而确保稳定的连接。

ICE 的工作原理

ICE 通过寻找穿过 NAT 和防火墙的最佳网络路径来实现点对点通信。此外，它还会收集本地和公共 IP 地址/端口（候选地址），并成对测试以确定最佳路径。要了解它如何选择最可靠的媒体和数据传输路径，请参阅以下工作流程指南：

• 候选地址收集：首先，每个设备运行一个 ICE 代理来识别所有到达自身的路径。由此，它可以收集主机地址、服务器反射地址和中继地址，以建立可能的连接。
• 通过信令交换候选地址：之后，双方通过信令信道共享各自的候选地址列表，通常使用 SDP 作为描述格式。这样，每个设备都能知道自身和对端的可能地址。
• 构建候选方案组合并确定优先级： ICE 会将本地和远程候选方案组合成方案组合。此外，还会根据类型、成本和偏好对方案组合进行排名，优先测试最佳方案。
• 连接性检查：之后，ICE 会通过向对端发送 STUN 请求来测试每个候选连接对。连接正常的连接对会被标记为有效，而连接失败的路径则会被忽略或降低优先级。
• 选择（指定）最佳路径：此外，控制代理会选择最佳的有效路径对。被控制代理接受该路径对后，媒体开始沿该路径传输。
• 使用和维护连接：最后，实时数据流经选定的候选接口对（音频、视频或数据）。此外，如果网络发生变化，ICE 可以重新运行，确保连接保持活动状态。

ICE 协议的优势

根据 StackWorkflow 的数据，ICE + STUN 在桌面设备上的连接成功率约为 85%。该报告还指出，如果两个设备之间成功建立过一次连接，只要网络环境保持不变，后续再次连接成功的概率就会更高。

因此，要了解其有效性，评估连接成功率、稳定性和性能至关重要。就此而言，ICE 的上述主要优势将凸显其如何改善点对点连接：

• 可靠连接：ICE 会查找两台设备之间所有可能的网络路径并进行测试。因此，即使经过防火墙和路由器，通话和数据传输也能正常工作。
• 更快更清晰的数据传输：与其他协议不同，ICE 尽可能选择设备间最佳的直接路径。这可以减少延迟、防止中断，并提高通话或视频质量。
• 无处不在：ICE 支持多种协议，例如 SIP 和 WebRTC，并兼容不同的网络。因此，开发人员可以在浏览器、手机和 PC 上使用同一系统。
• 安全可控路径：ICE 通过 STUN/TURN 身份验证对对等方进行检查，仅允许可信设备接入。当直接连接不安全时，流量也可保持在安全服务器上。
• 开发便捷，体验流畅： ICE 无需针对网络问题进行自定义修复。开发者可以专注于功能开发，用户也能享受可靠的通话体验，无需繁琐的设置。

ICE 协议面临的挑战

根据 Medium 的一项调查，约 6.7% 的通话会出现 ICE 连接失败。所谓“ICE 失败”，是指 ICE 连接状态变为失败状态。

这些失败主要归因于 WebRTC 漏洞，尤其是在去年 12 月 Chrome 47 版本发布之后，且该问题尚未完全修复。此外，ICE 协议还面临以下挑战：

• 设置困难： ICE 需要多个地址（主机地址、STUN 地址、TURN 地址）以及带有定时器和优先级的连接性检查。这使得实现起来很棘手，容易导致错误、优先级错误以及跨 NAT 类型的调试困难。
• 连接速度变慢：请注意，ICE 会同时运行多项检查，这可能会导致网络过载并造成丢包。因此，控制检查速度和优先级可以减少网络过载，但会在通话开始前造成延迟。
• 对 STUN/TURN 服务器的依赖：该协议依赖于 STUN 和 TURN 服务器，当直接连接失败时，TURN 中继会继续维持连接。这会增加带宽使用量、基础设施成本以及大规模服务的运维复杂性。
• 严格网络环境下的问题： ICE 在限制性防火墙、对称 NAT、运营商 NAT 或被屏蔽的 UDP 网络上可能会失效。因此，呼叫可能无法连接，或者必须使用速度较慢的 TCP/TLS 中继，从而降低用户体验。
• 难以调试：当 ICE 失败时，客户端会显示“呼叫失败”或 iceConnectionState: failed。而真正的原因可能是 STUN/TURN 问题、端口被阻塞、凭据错误或 NAT 行为异常，需要使用专门的工具才能确定。

ICE 协议的常见应用场景

1. WebRTC 音频和视频通话

浏览器中的 WebRTC 应用（如 Google Meet 或 Zoom）使用 ICE 直接连接两个用户。因为 ICE 会查找多个地址（Host、STUN、TURN），并选择最佳路径，从而使通话无需网络配置即可正常进行。

2. VoIP 和 SIP 通话

ICE 可以找到最直接的路径，从而提升通话质量并减轻服务器负载。因此类似 Cisco Jabber 或 3CX 等 VoIP 系统利用 ICE 通过 NAT 连接语音和视频通话。

3. 视频会议与协作

ICE 可以处理不同网络上的用户，并在直接连接失败时切换到 TURN。因此像 Microsoft Teams 或 Slack 这样的工具使用 ICE 进行群组会议和屏幕共享。

4. 点对点数据通道

ICE 技术使应用程序无需中央服务器即可在用户之间直接发送文件、文本或游戏数据。例如，Discord 等应用程序或浏览器游戏就使用 ICE 实现快速、低延迟的文件传输。

5. 在线游戏和多人游戏

ICE 可以减少延迟和服务器流量，使游戏体验更流畅、响应更迅速。因此像《堡垒之夜》或《Among Us》这样的游戏使用类似 ICE 的技术直接连接玩家。

6. 远程桌面和屏幕共享

ICE 允许远程桌面和屏幕共享工具高效安全地连接。因此，即使在网络受限的情况下，也能实现流畅的鼠标/键盘控制和视频流传输。

7. 物联网和设备间通信

智能设备，例如安防摄像头和智能家居助手，使用 ICE 协议连接到路由器。ICE 允许设备之间直接通信，用于遥测、命令或媒体传输，从而减少对云服务器的依赖。

ZEGO 如何借助 ICE 协议构建实时通信

即构科技(ZEGO) Web端实时音视频 SDK 有采用 WebRTC 和 ICE 协议，使开发者能够创建实时视频、音频和数据通道。由于 ICE 已被封装为易于使用的 SDK API，开发者无需再处理 NAT 穿透或信令等繁琐事务。ZEGO 云平台会自动处理 ICE、STUN 和 TURN，系统会收集 ICE 候选节点，与 ZEGO 遍布全球的服务器进行通信，并选择可行路径。

借助 ZEGO 实时音视频 SDK，开发者可以直接调用封装好的 API，无需手动处理 ICE 的底层细节。只需注册一个账户，即可免费体验全球端到端平均延迟 200 毫秒的实时音视频通话服务。

常见问题

Q1：ICE 协议是什么？

ICE（交互式连接建立）是 WebRTC 和其他实时通信系统中用于建立两个端点之间连接的框架。它的工作原理是收集可能的网络路径，测试连通性，并选择最佳的候选路径对进行​​媒体传输。

Q2：ICE 在没有 STUN 或 TURN 的情况下是否有效？

在某些简单的网络环境中，例如当两个对等节点位于同一局域网或具有可直接访问的地址时，ICE 可以无需 STUN 或 TURN 即可工作。然而，在大多数实际应用中，STUN 有助于发现公网地址，而当直接的点对点连接失败时，则需要 TURN。

Q3：为什么 ICE 在 WebRTC 中很重要？

ICE之所以重要，是因为它能帮助设备跨越不同的网络环境进行连接，而无需开发人员手动处理每个NAT或防火墙场景。它通过自动测试多条路径并选择最有效的路径，使实时通信更加可靠。