关于webrtc:WebRTC-之ICE浅谈-内有干货免费下载

前言

ICE 全称 Interactive Connectivity Establishment：交互式连通建设形式。

ICE 参照 RFC5245 倡议实现，是一组基于 offer/answer 模式解决 NAT 穿梭的协定汇合。
它综合利用现有的 STUN，TURN 等协定，以更无效的形式来建设会话。

客户端侧无需关怀所处网络的地位以及 NAT 类型，并且可能动静的发现最优的传输门路。

webrtc·1.04

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 的流程:

• 创立 Allocation：

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

当 allocation 创立后须要应用 refresh request 来保活，默认 lifetime 为 10 分钟。

• 创立 Permission：

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

有两种办法来创立和刷新 Permission

1. CreatePermission
2. ChannelBind

• 收发数据：

1. CreatePermission 应用 Send and Data indication 音讯
2. ChannelBind 应用 ChannelData 音讯

ICE 介绍

1. ICE 的角色

分为 controlling 和 controlled。

Offer 一方为 controlling 角色，answer 一方为 controlled 角色。

2. ICE 的模式

分为 FULL ICE 和 Lite ICE：

FULL ICE: 是单方都要进行连通性查看，实现的走一遍流程。

Lite ICE: 在 FULL ICE 和 Lite ICE 互通时，只须要 FULL ICE 一方进行连通性查看，Lite 一方只需回应 response 音讯。这种模式对于部署在公网的设施比拟罕用。

3. Candidate

媒体传输的候选地址，组成 candidate pair 做连通性查看，确定传输门路，有如下属性：

• Type 类型有：

Host/Srvflx/Relay/Prflx

• Componet ID

传输媒体的类型,1 代表 RTP;2 代表 RTCP。

WebRTC 采纳 Rtcp-mux 形式，也就是 RTP 和 RTCP 在同一通道内传输，缩小 ICE 的协商和通道的保活。

• Priority

Candidate 的优先级。

如果思考延时，带宽资源，丢包的因素，Type 优先级高下个别倡议如下程序：

host > srvflx > prflx > relay

• Base

是指 candidate 的根底地址。

Srvflx address 的 base 是本地 host address。

host address 和 relayed address 的 base 是本身。

4. Candidate pair

由本端和远端 candidate 组成的 pair，有本人的优先级。

pair 优先级的计算是取决 candidate 的 priority。

priority = 2^32*MIN(G,D) + 2*MAX(G,D) + (G>D?1:0)

G:controlling candidate 优先级

D:controlled candidate 优先级

ICE 抉择高优先级的 candidate pair。

1. Checklist

由 candidate pair 生成按优先级排序的链表, 用于 ICE 连通性查看。

6. Validlist

由连通性查看胜利的 candidate pair 按优先级排序的链表, 用于 ICE 提名和抉择最终门路。

ICE 过程

1. Gather candidates

依据 Componet ID:

• 获取本机 host address.
• 从 STUN 服务器获取 srvflx address.
• 从 TURN 服务器获取 relay address.
• 同时生成 foundation。

2. 删除反复的 candidate

收集地址实现后，须要去掉反复的 candidate，如果两个 candidate 的地址一样，并且 Base 地址也一样，则删除它。

3. 替换 candidates

ICE 应用 offer/answer 形式，单方通过 SDP 协商替换 candidate 信息.

Candidate 信息包含 type,foundation,base,component id,transport

SDP a 行格局如下:

“a=candidate:1 1 UDP 9654321 212.223.223.223 12345 typ srflx raddr 10.216.33.9 rport 54321”

示意 foundation 为 1，媒体是 RTP，采纳 UDP 协定，公网映射地址为 212.223.223.223:12345，优先级为 9654321，type 为 srflx，base 地址为 10.216.33.9:54321

4. 生成 candidate pairs

在本端收到远端 candidates 后，将 Component ID 和 transport protocol 雷同的 candidates 组成 pair。

修整 candidate pair，如果是 srvflx 地址，则须要用其 base 地址替换。

对端也是同样的流程。

5. 生成 checklist

将 candidate pairs 依照优先级排序，生成 checklist，供连通性查看应用。

6. 连通性查看

Ordinary checks 两端都依照各自 checklist 别离进行查看。

Triggered checks 收到对端的查看时，也在对应的 candidate pair 上发动连通性查看，以提高效率

如果 checklist 里有 relay candidate，则必须首先为 relay candidate 创立 permission。

7. 发送连通性查看申请

ICE 应用 STUN binding request/response，蕴含 Fingerprint 测验校验机制。

如果 A 收到 B 的 response，则代表连通性查看胜利，否则须要进行重传直到超 时。

在建设连贯时，如果没有响应，则会以 RTO 工夫进行重传，每次翻倍，直到最大重传次数。

STUN 申请 采纳 STUN short-term credential 形式认证，

STUN USERNAME 属性”RemoteUsername：localUsername”

两端在 SDP 协商时替换 ice-pwd 和 ice-ufrag，以得对端用户名和明码。

STUN 查看申请中须要查看地址的对称性，申请的源地址是响应的目标地址，申请的目标地址是响应的源地址，否则都设置状态为 Failed。

8. 生成 validlist

将连通性查看胜利的 candidate pair 并按优先级排序退出 validlist，这时本地 candidate 填写的是公网映射地址，remote candidate 填写的是对端发送的 STUN binding request 地址。

9. 提名 candidate pair

由 controlling 来提名哪对 candidate pair 为 valid pair

提名形式又分为一般提名和进取型提名

一般提名形式会做两次连通性查看，在第一次做连通性查看时不会带上 USE-CANDIDATE 属性，而是在生成的 validlist 里抉择 pair 再进行一次连通性查看，这时会带上 USE-CANDIDATE 属性，并且置位 nominated flag。

进取型形式则是每次发送连通性查看时都会带上 USE-CANDIDATE 属性，并且置位 nominated flag，不会再去做第二次连通性查看。

10. 抉择最终传输地址

ICE 在提名的 valid pair 里抉择优先级最高那对作为本次 ICE 流程传输地址。

ICE 状态

1. Waiting：还未开始连通性查看，从 checklist 中抉择适合优先级的 pair 进行查看
2. In-Progress：连通性查看曾经开始，但还未完结
3. Succeeded：该 pair 连通性查看曾经实现并且胜利
4. Failed：失败
5. Frozen：连通性查看还未开始

ICE 保活

1. 对于每个 ICE 通道，都须要为其会话进行保活。
2. 采纳 STUN binding request 或者 STUN binding indication。
3. 如果没有收到响应，则会重传，直到最大重传次数。

ICE 角色冲突解决

1. 当两端角色都为 controlling 或者 controlled 角色冲突时，在连通性查看阶段，要求发送 binding request 音讯里必须要带上 tie-breaker 属性。
2. 当呈现抵触时，比拟 tie-breaker 大小，值比拟大的则被认为是 controlling，同时回应 487 谬误给对端，对端收到 487 谬误后切换角色。

结束语

随着 WebRTC 的利用越来越广泛，无论是 Native 端还是 Web 端，因为宽泛的适应 能力以及对将来网络的反对，ICE 作为一种综合的解决方案将有着非常广阔的利用前景。

网易云信翻译了 W3C 举荐规范 WebRTC 1.0: Real-time CommunicationBetween Browsers，并提供《WebRTC1.0: 浏览器间实时通信》中文版 收费下载。

• 对于 WebRTC 初学者，本文档能够作为学习教程，帮忙你疾速对 WebRTC 有全面且具体的理解，学习相干 API 的应用，其附带的示例代码也是很好的学习材料；
• 对于 WebRTC 资深开发者，本文档能够作为开发中的使用手册，依据所提供的函数调用链或是算法流程进行开发或 bug 定位；
• 对于高阶玩家，也可通过浏览本文档对 WebRTC 工作组反馈改良意见。

webrtc·1.04

限时 收费下载，WebRTC 开发者必备。