WebRTC 之ICE浅谈

前言

ICE全称Interactive Connectivity Establishment：交互式连通建立方式。

ICE参照RFC5245建议实现，是一组基于offer/answer模式解决NAT穿越的协议集合。
它综合利用现有的STUN，TURN等协议，以更有效的方式来建立会话。

客户端侧无需关心所处网络的位置以及NAT类型，并且能够动态的发现最优的传输路径。

Classic STUN（RFC3489）的劣势:

Classic STUN 有着诸多局限性，例如:

1. 不能确定获得的公网映射地址能否用于P2P通信
2. 没有加密方法
3. 不支持TCP穿越
4. 不支持对称型NAT的穿越
5. 不支持IPV6

STUN（RFC5389）协议

RFC5389是RFC3489的升级版

1. 支持UDP/TCP/TLS协议
2. 支持安全认证

 

ICE利用STUN（RFC5389） Binding Request和Response，来获取公网映射地址和进行连通性检查。同时扩展了STUN的相关属性:

1. PRIORITY:在计算candidate pair优先级中使用
2. USE-CANDIDATE:ICE提名时使用
3. tie-breaker:在角色冲突时使用

TURN协议

ICE使用TURN（RFC 5766）协议作为STUN的辅助，在点对点穿越失败的情况下，借助于TURN服务的转发功能，来实现互通。端口与STUN保持一致

 

TURN消息都遵循 STUN 的消息格式，除了ChannelData消息。

 

1. 支持UDP/TCP/TLS协议，适用于UDP被限制的网络。
2. 支持IPV6。

 

TURN的流程:

1. 创建Allocation：

client 使用allocation transaction创建relay 端口，并在allocation的响应中回复给client。

当allocation创建后需要使用refresh request来保活，默认lifetime为10分钟。

 

1. 创建Permission：

由allocation创建Permission，每个Permission 由 IP 地址 和lifetime组成。

有两种方法来创建和刷新Permission

1. CreatePermission
2. ChannelBind

 

1. 收发数据：

1. CreatePermission使用