WebRTC中的ICE流程介绍

WebRTC 作为一项通讯技术，建立通讯连接的过程是其中很重要的部分。在webrtrc中采用了ICE（Interactive Connectivity Establishment）框架，可以通过使用多种技术（如 STUN、TURN、NAT 透明性检测等）来搜索可用的网络路径，并选择最优的路径建立连接，从而解决了 NAT 和防火墙等网络障碍的问题。

作者：赵鹏
单位：中国移动智慧家庭运营中心

01 网络拓扑

ICE流程通常需要STUN、TURN和SIGNAL三种服务器辅助。

STUN（Session Traversal Utilities for NAT）Server：STUN是一种协议，可用于终端确定NAT分配给它的IP地址和端口。位于NAT后的终端向STUN服务器发起请求，STUN服务器将NAT分配给该终端的地址返回给终端。

TURN（Traversal Using Relays around NAT）Server：TURN协议是作为ICE的一部分而设计的，当通信双方无法建立P2P连接时，可通过TURN服务器进行数据中转。

SIGNAL Server：信令服务器用于传递双方信令信息，也可传输业务信息。其传输信息的协议是 HTTP 或 Socket 等。

Peer：对等通信终端节点。

02 ICE流程

2.1 总体流程

在ICE流程之前，通信双方需要先连接到信令服务器，发起方向被叫方发送offer消息，被叫方给发起方回复answer消息，然后才能触发ICE流程。ICE流程主要包括以下步骤：

（1）收集candidate

（2）交换candidate

（3）连通性测试

2.2 收集candidate

Candidate地址有三类，host address、srflx address和relay address，这三种地址有优先级，由高到低依次是 host、srflx、relay。其含义如下：

host address：本地ip和端口地址，从本机直接获取。

Srflx(server-reflexive) address ：NAT为本机分配的ip和端口地址。

Relay address ：turn服务器为本机分配的ip和端口地址。

因此收集步骤也分为三步：

（1）获取本机地址 host address

（2）从STUN服务器获取srflx address

（3）从TURN服务器获取 relay address

下图是cadidate的一个示例

2.2.1 收集srflx address流程

上图展示了一种比较普遍的STUN Server和终端节点部署的位置，但STUN Server也并非一定处于公网。终端节点Peer A给STUN server发送UDP消息binding request，请求可能穿过一个或多个NAT到达STUN server，STUN server收到该request时能看到离自己最近的NAT给Peer A分配的ip和端口，这个地址就是srflx address，STUN Server在回复binding response时就将这个srflx address携带在消息里返回给Peer A。此后Peer A还会周期性的给STUN Server发送bing request消息防止长时间没有消息经过该srflx address被NAT回收。

2.2.2 收集relay address流程

终端节点Peer A给TURN Server发送allocate request消息，请求分配relay address，TURN Server启动监听一个新的UDP端口，这个新端口的地址就是relay address，然后在allocate success response消息中将relay address告知Peer A。每一个relay address都有生命周期，因此Peer A需要周期性的给TURN Server发送Refresh request消息刷新生命周期，当超时未刷新或Peer A发送refresh request将生命周期置为0时，该relay adress被回收。

2.3 交换candidate

交换candidate有两种方式，一种是在offer和answer消息中携带发送给对方，但由于这种方式需要等到candidate收集完成后才能发送，因此建立连接过程往往比较缓慢。第二种方式是offer协商和收集candidate同时进行，candidate在收集到后单独发送给对方。

2.4 连通性测试

测试时按照地址优先级尝试连接，优先使用host地址建立连接，然后使用srflx建立连接，当前两种方式都无法成功时，最后采用relay地址建立连接。因此webrtc的连通成功率几乎达到100%。连通性测试也是使用binding request和binding response消息。示意图如下：

2.5 通过TURN Server转发业务数据时的流转流程

当使用host address或srflx addres打通了P2P通道时业务数据流转流程比较简单。未打通P2P时，业务数据通过relay address进行转发，其流程要相对复杂一点。典型拓扑结构如下。

如图所示，假设Turn client（也是一个Peer节点，此处为了方便描述）与Peer B通信，TURN Server的固定监听地址为39.173.116.100:20000,下文统一称为Turn 20000端口，TURN Server给TURN client分配的relay address为39.173.116.100:26321，下文统一称为Turn 25321端口。

2.5.1 TURN client发数据给Peer B

Turn client先按照TURN协议将数据包封装为turn packet，然后再发往TURN Server的Turn 20000端口，该协议里告知了TURN Server该数据包的目的地址。

TURN Server收到turn packet后会进行解析，并且将业务数据和目的地址提取出来，按普通UDP包的格式使用Turn 25321端口发给Peer B。

2.5.2 Peer B发数据给TURN client

Peer B直接把UDP数据包发给Turn 25321端口，此时Turn 25321端口可看作TURN client的专用代理，所有发到该端口的数据默认都被转发给TURN client。Turn 25321端口收到数据后，使用TURN协议对数据进行封装，然后通过TURN 20000端口发送给TURN client。