[webrtc] 交互式连接建立（ICE）

课程地址：零声学院 WebRTC入门与提高 https://ke.qq.com/course/435382?tuin=137bb271

技术支持QQ群：782508536

webrtc时序图.png

更多音视频知识请点击：专注音视频开发

原文：[webrtc] 交互式连接建立（ICE）http://www.libsdl.cn/bbs/forum.php?mod=viewthread&tid=81

交互式连接建立是一种标准穿透协议，利用Stun和Turn服务器来帮助端点建立连接。市面上已有不少介绍ICE的资料，像《WebRTC权威指南(第三版)》中的“9.2 交互式连接建立”。但看了那些后，有人还是不能理解，这里试着用一个实例来描述整个过程。ICE协议只是制定规范，没规定怎么实现细节，在细节实现上这里参考Google的WebRTC。

图1 ICE呼叫流程

上图就是《WebRTC权威指南(第三版)》中的图9.1。呼叫要交换两种信息，一是候选地址，二是媒体信息。候选地址用于建立网络连接，它存储着和网络连接相关的参数。媒体信息（SDP）用于描述要在对等连接上传输的数据，包括音频、视频和数据。用路和车来比喻的话，候选地址用于造路，媒体信息于用指定要跑什么车。
　　在图中，双方是串行处理媒体、候选地址，但实际中是并发的。举个例子，主叫收到Answer后，它仍可能在收集候选地址，然后通过信令服务器发向被叫。
　　除了主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址外，ICE代理是相互独立地处理媒体和候选地址。（这结论细节参考底下的“四：选定候选地址，并启动媒体”）。
　　和“9.2 交互式连接建立”一样，这里也把ICE分为六个步骤。下图是例子使用的网络拓扑结构。

image

一：收集候选地址
　　候选地址是或许可用于接收媒体以建立对等连接的对，它分四种类型。

具体到例子，以下是此阶段将至少能收集到的候选地址。为简单，不再写A的IP2、B的IP2的服务器反射地址。

| 别名 | 类型 | 值 |
| ACand2 | srflx | 211.161.240.181(raddr: 192.168.1.105) |
| ACand1 | host | 192.168.0.204 |
| BCand3 | host | 192.168.0.181 |

二：交换候选地址
　　A通过信令服务器把ACand2、ACand1、BCand3发向A。对端收到一个候选地址后会做什么？深入它之前让引入两种对象：P2PTransportChannel、Connection。
　　ICE代理用P2PTransportChannel管理通道（Component）上的网络传输。什么是通道？Webrtc有个概念叫轨道（Track），常见有视频轨、音频轨，而要发送一条轨道中数据，最多可能使用两个通道，分别是Rtp、Rtcp。肯定会有Rtp，Rtcp则可选。一个P2PTransportChannel对应一条通道，如果当前会话要同时处理音频、视频，每条轨道又都包括Rtp、Rtcp，那会话中就存在四个P2PTransportChannel对象。P2PTransportChannel用维护一张连接状态表来管理网络传输，表中一条记录对应一个Connection对象。这里让具体到A的视频Rtp对应的P2PTransportChannel，看它在收到BCand1后，P2PTransportChannel会向连接状态表新增两条记录，即两个Connection。这时已到通道，地址须是ip:port对。

| 本地网卡地址(Port) | 对端地址 | 状态 |
| 192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过Stun检查 |
| 172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过Stun检查 |

此时A不知道该用哪个网卡IP才能把数据成功发向192.168.0.204，于是它只要在有可能的地址对就创建Connection。注意Connection只会基于网卡IP，即host，因为对发送源来说，host才可能是源，其它的只是中间转换出的地址，像srflx。当然，创建时会放弃明显不可能的<网卡地址, 对端地址>对，举个例子，网卡地址是ipv4，而对端地址是ipv6。
　　当收全BCand2、B$Cand3，状态表中就有6条记录。

| 本地网卡地址 | 对端地址 | 状态 |
| 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检查 |

表中有一条、或多条、或没有，能够把A的视频Rtp数据发向B的视频Rtp通道，到底怎么个可能性就要执行接下的Stun检查。

三：STUN检查
　　在状态表新建一条记录，即一个Connection，很快就会在此Connection上进行Stun检查。Stun检查具体操作是在此Connection上发Stun Binding请求。由于要能支持Stun应答，每个ICE代理必须内置Stun服务器功能。Stun检查具体步骤见下图。

image

　　为什么说Stun检查会发现prflx候选项？假如A和Stun服务器之间连接状态不好，在它收到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一开始就基本能确定连接是畅通的。

四：选定候选地址，并启动媒体
　　P2PTransportChannel会维护连接状态表，并排序表中记录（SortConnectionsAndUpdateState）。排序指的是计算每条记录的连接“成本”，把成本最低的排在第一条。如何计算成本？这涉及到很多因素，比如发出Stun请求到收到应答经过了的时间，用时越少的“成本”自然会低些。
　　当A有视频Rtp数据要发送时，它检查状态表的第一条记录，如果判断出它的状态是发送就绪，就会用此Connection进行发送。否则直接放弃这个发送任务。媒体模块在处理数据的采集、编码任务时，不用考虑候选地址方面进展怎样了，只是要到发送时才关注下，而即使不能发送也不会影响自个进度；同样，候选地址处理模块也不会关注媒体处理模块的进度。这正是之前写的一个结论：“除了主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址外，ICE代理是相互独立地处理媒体和候选地址”。
　　维护表任务包括新建、删除记录，以及修改记录中的状态字段。删除记录、修改状态都涉及到“长连接”。

五：长连接
　　为确保NAT映射和过滤规则不在媒体会话期间超时，ICE会不断通过使用中的候选项对发送Stun连接检查。具体到P2PTransportChannel，表现出来的是对状态表中所有记录隔段时间就要发送个Stun Binding请求。如果检测到本来是畅通的Connection上Stun应答超时了，那它就会更改该Connection状态，执行表排序时就有可能会向下掉，严重时会从状态表删除该记录。
　　一记录被删除后，如果之后那候选地址的连接又恢复了，则会基于该候选地址重新创建Connection。

六：ICE重新启动
　　分析长连接时，我们已能得出个结论，如果是网络拥堵或通断导致的状态表变化，P2PTransportChannel内部就能处理。但是，如果基地址发生改变，像一网卡被禁用，这就超出P2PTransportChannel可处理范围了，需重启ICE。

[webrtc] 交互式连接建立（ICE）

你可能感兴趣的:([webrtc] 交互式连接建立（ICE）)