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值。
最新文章
- 【原创】免费申请SSL证书【用于HTTPS，即是把网站从HTTP改为HTTPS，加密传输数据，保护敏感数据】
- linux(centos)源码安装git
- 【Go语言】连接数据库SQLite、MySQL、Oracle
- BizTalk动手实验（四）Schema开发测试
- js 截取字符串
- PHP中__autoload()的不解之处，求高手指点
- MySQL数据库索引简介
- Java Web 浏览器关闭后Session就会被销毁吗？
- 3. mysql性能分析
- SpringBoot获取配置文件的自定义参数
- java基础（1）IntelliJ IDEA入门和数组操作 解决idea启动速度慢--配置JVM
- SVN——Couldn't perform atomic initialization
- Codeforces Round #423 (Div. 2, rated, based on VK Cup Finals) Problem D (Codeforces 828D) - 贪心
- java Concurrent包学习笔记（六）：Exchanger
- dnspod域名解析设置
- null的专栏：https://blog.csdn.net/google19890102
- 统计Github项目信息
- postman从入门到精通
- BZOJ4598: [Sdoi2016]模式字符串(点分治 hash)
- 倒计时特效的CountAnimationLabel