WebRTC ICE协议揭秘

Interactive Connectivity Establishment (ICE)是WebRTC建立的支柱之一；没有 ICE，就没有 WebRTC。这是一个有趣的框架，无需明确了解底层拓扑或架构即可实现无缝网络遍历。在这篇文章中，我们将深入研究 ICE 并发现它如何为我们的底层媒体层工作。

WebRTC ICE协议背景

通常，用于在对等点之间建立会话连接的协议涉及 IP 地址和端口的交换。然而，这在处理网络地址转换器 (NAT)后面的网络时会导致问题，因为 NAT 隐藏了它们自己后面的源地址并维护一个内部映射表。

多年来，针对这个问题提出了许多解决方案，包括应用层网关 (ALG)和最初的 STUN 实现（已被淘汰）。

不幸的是，所有这些解决方案在某些网络拓扑中表现更好，而在其他网络拓扑中表现更差，这导致对将部署这些解决方案的系统架构做出假设。这是脆弱性和复杂性的潜在来源，这是不可取的。

ICE 的存在是有原因的，原因如下：

典型的 WebRTC 场景涉及（至少）两个希望进行通信的对等方（或代理）。这些代理最初并不知道它们自己的网络拓扑。特别是我们的代理，可能位于也可能不位于单层或多层 NAT 之后。ICE 允许代理充分了解它们的拓扑结构，以找到它们可以连接的一条或多条路径。

一个典型的部署场景

上图描述了 ICE 部署中的典型场景。每个代理都有多个候选传输地址（特定传输协议的 IP 地址和端口的组合），可用于与其他代理通信。这些可以包括：

直接连接的网络接口上的传输地址
NAT 公共端的转换传输地址（“服务器反射”地址）
从 TURN 服务器分配的传输地址（“中继地址”）

理论上，L 的任何候选传输地址都可以用于与 R 的任何候选地址进行通信。然而，在实践中，许多组合是行不通的；例如：如果 L 和 R 都位于 NAT 之后，则它们直接连接的网络接口将无法直接通信。ICE 的目的是发现哪些对可以工作；这是通过系统地尝试每一对（按照仔细排序的顺序）直到我们找到一个或多个有效来实现的。

将所有候选人聚集在一起

如前所述，有不同类型的候选人；有些来自网络接口，有些可以通过 STUN 和 TURN 发现。

主持候选人

第一类候选者是那些具有直接从本地接口（例如以太网或 Wi-Fi）获得传输地址，或者可以通过隧道机制（例如 VPN）获得的传输地址。在所有情况下，这样的网络接口对代理来说都是本地接口，可以从中分配端口（以及候选端口）。

服务器反身候选人

这些候选者是通过 STUN 发现的，在 NAT 的公共端有一个转换后的地址。如果不使用 TURN 服务器，这是最常见的候选类型，也是除主机候选之外的唯一类型。

中转候选人

如果使用 TURN 服务器（它们应该使用），则可以使用使用中继地址的候选人。所有候选人之间的关系如下图所示。

当仅使用 STUN 服务器时，代理向其 STUN 服务器发送 STUN 绑定请求。STUN 服务器将通过将绑定请求的源传输地址复制到绑定响应中来通知服务器反射候选 X1′:x1′ 的代理。
当代理从 IP 地址和端口 X:x 发送 TURN 分配请求时，NAT 创建绑定 X1′:x1’，将此服务器反射候选者映射到主机候选者 X:x。从主机候选者发送的传出数据包将由 NAT 转换为服务器自反候选者。发送到服务器反射候选者的传入数据包将由 NAT 转换为主机候选者并转发给代理。
当代理和 TURN 服务器之间存在多个 NAT 时，TURN 请求将在每个 NAT 上创建一个绑定，但代理只会发现最外层的服务器反射候选者（最接近 TURN 服务器的那个）。如果代理不在 NAT 后面，则基础候选者将与服务器自反候选者相同，而服务器自反候选者是多余的，将被忽略。