【网络通信 -- 直播】网络通信协议简介 -- ICE
【0】简介
交互式连接建立,(ICE,Interactive Connectivity Establishment) 与 STUN 和 TURN 不同,ICE 不是一种协议,而是一个框架(Framework)并整合了 STUN 和 TURN;
【1】ICE 的基本步骤
ICE 的目的,确定可用于双端通信的传输地址对;
ICE 基本思想,每一个代理拥有多种可用于与对端通信的候选传输地址(TRANSPORT ADDRESSES,针对特定传输协议(一般为 UDP 协议)的 IP 地址和端口的组合),ICE 通过不断地尝试以确定真正可用的传输地址对;
- 传输地址包括
- 直接连接的网络接口上的传输地址
- NAT 公共端的转义传输地址,即服务器反射地址(server reflexive)
- TURN 服务器上分配的传输地址,即转发地址(relayed address),中继地址
图示显式了 ICE 的呼叫的基本步骤
呼叫需要交换两种信息,一是候选地址,二是媒体信息;
- 候选地址用于建立网络连接,存储着和网络连接相关的参数;
- 媒体信息(SDP)用于描述要在对等连接上传输的数据,包括音频、视频和应用数据;
图示为详细示例使用的网络拓扑图
【1.1】收集候选传输地址
候选地址(或许可用于接收媒体以建立对等连接的 IP 地址和端口),候选地址必须在呼叫时收集,不能提前收集;
候选地址类型
候选地址类型 | 传达对端方式 | 用法 |
主机候选地址,HOST CANDIDATE | 信令服务器 | 从网卡 (Network Interface Card,NIC) 中获取的本地传输地址;若该地址位于 NAT 之后,则为私有地址,无法在子网之外路由到; |
服务器反射地址,SERVER REFLEXIVE CANDIDATES | 信令服务器 | 从发送给 STUN 服务器的 STUN 检查中获取的传输地址,若该地址位于 NAT 之后,则为最外层 NAT 的公共 IP 地址; |
对端反射地址,PEER REFLEXIVE CANDIDATES | Stun Binding 请求 | 从其他 ICE 代理发送的 STUN 连接检查中获取的传输地址,该地址是一种在连接检查期间发送的新候选项,不通过信令通道发送; |
中继地址,RELAYED CANDIDATES | 信令服务器 | 媒体中继服务器的传输地址,通过 TURN 分配请求获取; |
候选地址之间的关系图示
示例讲解
示例中,A 端 B 端可以收集到的候选地址信息
别名 | 类型 | 值 |
A$Cand1 | HOST CANDIDATE | 192.168.1.105 |
A$Cand2 | SERVER REFLEXIVE CANDIDATES | 211.161.240.181 (源地址: 192.168.1.105) |
A$Cand3 | HOST CANDIDATE | 172.16.40.6 |
B$Cand1 | HOST CANDIDATE | 192.168.0.204 |
B$Cand2 | SERVER REFLEXIVE CANDIDATES | 11.92.14.8 (源地址: 192.168.0.204) |
B$Cand3 | HOST CANDIDATE | 192.168.0.181 |
【1.2】交换候选传输地址
通过信令通道交换候选传输地址,一旦收到候选传输地址,便对这些候选传输地址进行排序与确定优先级,一般主机候选传输地址优先级最高,其次是反射传输地址,最后是中继传输地址;
Webrtc 概念:轨道(Track),常见有视频轨、音频轨,而要发送一条轨道中数据,最多可能使用两个通道,分别是 Rtp、Rtcp;
ICE 代理用 P2PTransportChannel 管理通道(Component)上的网络传输;一个 P2PTransportChannel 对应一条通道,若当前会话要同时处理音频、视频,每条轨道又都包括 Rtp、Rtcp,则会话中就存在四个 P2PTransportChannel 对象;P2PTransportChannel 维护一张连接状态表以管理网络传输,表中每一条记录对应一个 Connection 对象;
示例讲解
示例中 A 收到 B 发来的 B$Cand1 后,P2PTransportChannel 会向连接状态表新增两条记录,即两个 Connection;
本地网卡地址 | 对端地址 | 状态 |
192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过 STUN 检查 |
172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过 STUN 检查 |
当 A 收到 B 的所有 B$Cand1、B$Cand2、B$Cand3 之后,状态表中的数据如下
本地网卡地址 | 对端地址 | 状态 |
192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过 STUN 检查 |
172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过 STUN 检查 |
192.168.1.105:60001 | 11.92.14.8:50002 | 未进行过 STUN 检查 |
172.16.40.6:60003 | 11.92.14.8:50002 | 未进行过 STUN 检查 |
192.168.1.105:60001 | 192.168.0.181:40003 | 未进行过 STUN 检查 |
172.16.40.6:60003 | 192.168.0.181:40003 | 未进行过 STUN 检查 |
【1.3】连接检查
对于代理 A 当从代理 B 收到 SDP 应答时,便开始连接检查;对于代理 B 当向代理 A 发送了 SDP 应答时,便开始连接检查;每一个检查是一个 STUN 请求/响应事务,该事务通过客户端使用特定的候选地址对,由本地候选地址向远端候选地址发送 STUN 请求的方式执行,该过程如下图所示;
获选地址对状态变化图示;
- 排序后的候选地址对最初处于“冻结”状态,即在检查准备就绪之前一直处于待命状态;
- 当 ICE 连接检查算法确定应执行检查时,候选地址对进入“等待”状态;
- 当步调适于进行检查时,一旦将 STUN 连接检查发送至另一端的对等端,候选地址对进入“正在进行”状态;
- 若接收到响应,则候选地址对进入“成功”状态,若检查超时且没有响应,则候选地址对进入“失败”状态;
示例讲解
在状态表新建一条记录,即一个 Connection,很快就会在此 Connection 上进行 Stun 检查;Stun 检查具体操作是在此 Connection 上发 Stun Binding 请求,检查步骤图示如下;
STUN 检查会发现 prflx 候选地址(对端反射候选地址)
- 若 A 和 STUN 服务器之间连接状态不好,在 A 收到 B 发来的 srflx(11.92.14.8)之后还没得出本身的 srflx(211.161.240.181);虽然 A 没得到自身的 srflx,但并不妨碍对 B 的 srflx 候选地址进行 STUN 检查,于是会向 11.92.14.8 发 STUN 请求;B 收到这个请求,从请求解析出 211.161.240.181,虽然该地址在值上等于 A 的 srflx,但不是从信令服务器得到,而是来自对端的 STUN 请求,此时 B 就会以这个 prflx 向状态表新建 Connection;
- A 在之后从 STUN 服务器确认了自身的 srflx,并通过信令服务器发向 B;B 发现该 srflx 值对应的 Connection 已存在,便不会重复创建连接;
结论,两种原因会导致新建 Connection,一是从信令服务器收到候选地址,二是 STUN 检查发现 prflx;
- 不同于从信令服务器得到地址而创建 Connection,STUN 检查时创建的 Connection 一开始就基本能确定连接是畅通的;
【1.4】选择选定的候选地址对并启动媒体
- 连接检查将一直持续直到所有可能的检查都已经完成(所有的检查状态从“冻结”到“成功”/“失败”)或某一候选地址对被选定;
- 选择候选地址对的操作由施控 ICE 代理执行;
- 当收到的 STUN 连接检查属性指示将使用某个候选地址对时,受控 ICE 代理便可知对端 ICE 代理已经选择该候选地址对,随后,受控 ICE 代理便回复连接检查,确认使用该候选地址对;
- 确认了候选地址对之后,便可以使用选定的候选地址对发送媒体数据;
示例讲解
P2PTransportChannel 会维护连接状态表,并排序表中记录(SortConnectionsAndUpdateState);
- 排序指的是计算每条记录的连接"成本",把成本最低的排在第一条;
- 计算"成本"涉及到很多因素,比如发出 STUN 请求到收到应答经过的时间,用时越少的"成本"相应低些;
当 A 有视频 RTP 数据需要发送时,A 检查状态表的第一条记录,若判断出其状态是发送就绪,则会用此 Connection 进行发送,否则直接放弃这个发送任务;
媒体处理模块在处理数据的采集、编码任务时,不用考虑候选地址方面的进度,只在需要发送时才关注一下,然而即使不能发送也不会影响媒体处理模块自身的进度;候选地址处理模块也不会关注媒体处理模块的进度;
- 即除了主叫必须创建 Offer 才开始收集候选地址、被叫必须创建 Answer 才开始收集候选地址外,ICE 代理相互独立地处理媒体和候选地址;
维护表任务包括新建记录、删除记录、以及修改记录中的状态字段,删除记录、修改状态都涉及到"长连接";
【1.5】长连接
ICE 会每隔 15 秒通过使用中的候选传输地址发送连接检查,以确保 NAT 映射以及过滤规则不在媒体会话期间超时;这样当媒体暂停或因其他原因没有发送的情况下,仍有数据包可以持续发送;
若媒体会话仍处于活动状态,对端 ICE 代理会生成 STUN 响应,若本端 ICE 收到此 STUN 响应则表明仍可继续发送媒体数据;若本端 ICE 没有收到 STUN 响应则停止媒体流,此时需要重启 ICE;
示例讲解
P2PTransportChannel 对状态表中所有记录隔段时间就要发送一个 STUN Binding 请求,若检测到原本畅通的 Connection 上 STUN 应答超时,则更改该 Connection 状态,执行表排序时就有可能会排到后面,严重时会从状态表中删除该记录;记录被删除后,若之后该候选地址的连接又恢复了,则会基于该候选地址重新创建 Connection;
【1.6】ICE 重新启动
任何一端 ICE 代理检测到传输基地址发生变更,都会触发重新启动 ICE 的事件,该事件将导致 ICE 代理重新从步骤一开始执行,并以 SDP 提议形式将候选地址发送给对端的 ICE 代理;此时,会使对端 ICE 代理重新从步骤一开始执行整个过程;
示例讲解
若网络拥堵或通断导致的状态表变化,P2PTransportChannel 内部就能处理;若基地址发生改变,比如网卡被禁用,此时便超出 P2PTransportChannel 可处理范围,需重启 ICE;
资料链接
ICE_RFC5245,链接:https://pan.baidu.com/s/1d3_IkytQQ28nB7eYPA4m-Q 提取码:05yu
参考致谢
本博客为博主的学习实践总结,并参考了众多博主的博文,在此表示感谢,博主若有不足之处,请批评指正。
【1】ICE_RFC5245
【2】P2P技术详解(四):P2P技术之STUN、TURN、ICE详解
【3】WebRTC 权威指南