stun/turn/ice学习笔记

stun基本只是用于client探测NAT之后靠近stun server的外网地址，本身不包含应用数据通信的功能，其底层STUN协议通信多是基于UDP的。多个端点之间相互通过信令通道拿到彼此的NAT外网地址之后，就可以进行直接的P2P通，但可能因路由防火墙的规格太严格导致直接P2P通信不成功。

turn是扩展了stun功能，除了类似stun可是实现NAT外网侧地址探测之外，也实现了基于中继转发实现应用数据通信，其底层通信可以基于UDP或TCP，多基于UDP，（rfc5766也建议基于UDP）。由于turn包含了stun的功能，自然是可以实现类似stun时的直接的P2P通信。类似可能因路由防火墙的原因直接的P2P通信不成功，可以使用turn的中继转发来实现两个端点之间的间接通信。

中继转发模式时，两个端点间的通信始终需要turnserver参与，turnserver对此实施了权限管理。
1，首先每个端点链接到turnserver后，需要通过turnserver的身份认证之后才能进行后续操作，认证方式是向turnserver提供预先分配的realm/用户名／密码等信息。此步骤在 STUN Alloc Request中执行。在响应消息中中会得到turnserver返回的mapped addr和relay addr。
2，第一步的身份认证通过之后，若想向其他的端点发送数据，则需要先向turnserver申请发送许可，此步骤需要提供目标端点的relay地址。此步骤在STUN CreatePermission request中执行。
3，之后即可以STUN Data Indication消息形式向turnserver发送应用数据，目的地址为目标端点的relay地址。为进一步减小包头开销，可以进一步向turnserver申请通道绑定，将当前turn中继会话与turnserver的一个通道相关联，后续和turnserver以ChannelData的方式通信，其包头开销小很多。

以上可见STUN/TURN是已经提供了基本可用的通信机制，实际可优先采用STUN P2P直接的通信方式，但可能不通，继而需要改用TURN中继。因此就需要初始的连通性协商检查过程，而此过程都是类似的，ICE的作用正是可以替我们完成这个探测协商过程，并且还提供了双方身份确认的功能。

在pjnath实现中，ICE具体的数据收发由STUN UDP P2P／TURN中继来完成，每个STUN UDP P2P／TURN数据通道在内部用transport表示，而对应应用层的每一路数据流用component表示，其各自的都分配一个id，后续通过ice会话进行数据收发时都需要按需指定这些id值。

需要注意的是，ICE连通性检查是两端相互给对方发送检查报文，并根据是否接收到预期的成功响应来确定是否连通的。本端检查OK，不代表对端也OK。因而当底层采用UDP传输时，由于报文顺序无保证，当在一端检查OK之后就立即给对端发送应用数据时，可能在对端就会出现应用报文先于连通性检查结果到达。实际应用时需要处理这种时序问题，在进行封装开发时应该合理的结果是保证应用数据在检查结果之后送给上层。