stun协议笔记二（webrtc之turn流程简介）
一、turn典型应用场景
这张图描述的是TURN Client、PeerA、PeerB三方会议之间，网络报文互相通讯的场景。其中：
1、TURN Client客户端、PeerA分别连接到两个内网中，并且通过一个或者多个NAT到达公网。
2、TURN服务器架设在公网中，不同的客户端以TURN服务器为中继和其他peer进行通信。如上图所示：TURN Client客户端通过中继和其他peer进行通讯；PeerB没有NAT，可直接通过自己的IP地址与其他peer进行通讯；这里是假设PeerA网络是全锥型网络，也是可直接通过自己的reflex IP地址与其他peer进行通讯。
TURN Client客户端通过中继和其他peer进行通讯的流程描述如下：
1、TURN Client是位于NAT后面的一个客户端（内网地址是10.1.1.2:49721），连接公网的TURN服务器（默认端口3478）后， 服务器会得到一个Client的反射地址（Reflexive Transport Address）192.0.2.1:7000。
2、TURN Client通过TURN命令创建或管理ALLOCATION，allocation是服务器上的一个数据结构，包含了中继地址的信息。 服务器随后会给Client分配一个中继地址，即图中的192.0.2.15:50000。
3、另外两个对等端若要通过TURN协议和TURN Client进行通信， 可以直接往中继地址收发数据即可，TURN服务器会把发往指定中继地址的数据转发到对应的Client，这里是其反射地址。
4、Server上的每一个allocation都唯一对应一个client，并且只有一个中继地址，因此当数据包到达某个中继地址时，服务器总是知道应该将其转发到什么地方。
但值得一提的是，一个Client可能在同一时间在一个Server上会有多个allocation，这和上述规则是并不矛盾的。
二、turn交互流程
整理实际应用中Turn协议的工作主要有四个阶段：绑定（binding）、分配（Allocation）、转发（Relay）和信道（Channel）
三、流程详解
1）资源申请
binding request&response
binging request：client向server发送的reflex地址请求命令
binging response：server将client公网地址并server的局域网地址发送给client端。
一般只要部署turn服务器，就不用另外部署stun服务器，turn服务器已经兼容了stun功能。
- binging request示例：
- binging response示例：
allocation request&response
客户端想要在服务器端获得一个中继分配，客户端需要在中继服务器上申请一个中继事务。客户端发送分配请求(Allocate request)到服务器，然后服务器为用户开启一个relay端口后返回分配成功响应，并包含了分配的地址信息。客户端可以在属性字段描述其想要的分配类型：UDP or TCP。
上图中，turn服务器的turn port是配置文件中配置的监听地址，默认是3478；A的Relay是Client向服务器发送allocation request，turn服务器动态分配的relay地址。
a）客户端A向turn Port发送Allocate请求(图中绿色部分)。
b）turn服务器接收到客户端A的Allocate请求，服务器一看是Allocate请求，则根据relay端口分配策略为A分配一个端口。
c）服务器发送response成功响应。在该response中包含XOR-RELAYED-ADDRESS属性。该属性值就是A的relay端口。
d）客户端接收到response后，就知道了自己的relay地址。该relay地址是个公网地址，可以看作是客户端A在公网上的一个代理，任何想要联系A的客户端，只要将数据发送到A的relay地址就可以了
- allocation request示例：这里是申请UDP协议中继，实际应用中也可以使用TCP协议中继。
- allocation response示例
2）保活机制（refresh request）
一旦中继传输地址分配好，客户端必须要将其保活。通常的方法是发送刷新请求(Refresh request)到服务端。这在TURN 中是一个标准的方法，刷新频率取决于分配的生命期，默认为10分钟。客户端也可以在刷新请求里指定一个更长的生命期，而服务器会返回一个实际上分配的时间。当客户端想终止通信时，可以发送一个生命期为0的刷新请求。
3）数据交换机制
client和peer之间有两种方法通过turn server交换应用信息：
第一种：使用Send和Data转发机制
第二种：使用channels信道机制
两种方法都通过某种方式告知服务器哪个peer应该接收数据，以及服务器告知client数据来自哪个peer。
转发机制
转发机制使用Send和Data指令（Indication）。其中Send指令用来把数据从client发送到server，而Data指令用来把数据从server发送到client。当使用Send指令时，客户端发送一个Send Indication到服务端，其中包含：
1、XOR-PEER-ADDRESS属性：指定对等端的(服务器反射)地址。
2、DATA属性：包含要传给对等端的信息。
当服务器收到Send Indication之后，会将DATA部分的数据解析出来，并将其以UDP的格式转发到对应的端点去，并且在封装数据包的时候把client的中继地址作为源地址，从而从对等端发送到中继地址的数据也会被服务器转发到client上。
值得一提的是，Send/Data Indication是不支持验证的，因为长效验证机制不支持对indication的验证，因此为了防止攻击，TURN要求client在给对等端发送indication之前先安装一个到对等端的许可（permission）。
如下图所示，client到Peer B 没有安装许可，导致其indication数据包将被服务器丢弃，对于peer B也是同样。
1）create permission request&response
CreatePermission Request示例：
CreatePermission Response示例：
2）send indicate（stun ping）&data indicate
webrtc中使用send&data indicate数据包，主要是用来做连通性测试使用，代码实现函数是：
P2PTransportChannel::SortConnectionsAndUpdateState
->P2PTransportChannel::MaybeStartPinging
->P2PTransportChannel::OnCheckAndPing
->P2PTransportChannel::PingConnection
->Connection::Ping
Send Indicate示例：
Data Indicate示例：
信道机制
音视频数据转发场景中，使用Send/Data Indication转发机制，会多加的36字节格式信息，加重客户端和服务端之间的带宽压力。为改善这种情况，turn提供channeldata message信道机制。channeldata message不使用stun头部，而使用一个4字节的头部，包含一个称为信道号的值(channel number)。每一个使用中的信道号都与一个特定的peer绑定，即作为对等端地址的一个记号。要将一个信道与对等端绑定，客户端首先发送一个信道绑定请求(channelbind request)到服务器，并且指定一个未绑定的信道号以及对等端的地址信息。绑定后client和server都能通过channeldata message来发送和转发数据。信道绑定默认持续10分钟，并且可以通过重新发送channelbind request来刷新持续时间。和Allocation不同的是，并没有直接删除绑定的方法，只能等待其超时自动失效。
上图中0x4001为信道号，即channeldata message的头部中头2字节，值得一提的是信道号的选取有如下要求：
0x0000-0x3FFF ：这一段的值不能用来作为信道号
0x4000-0x7FFF ：这一段是可以作为信道号的值，一共有16383种不同值在目前来看是足够用的
0x8000-0xFFFF ：这一段是保留值，留给以后使用
1）channel bind request&response
channel bind request示例：
channel bind response示例：
2）Channel Data Turn Message
TURN ChannelData Message示例：
四、参考：
https://zhuanlan.zhihu.com/p/71025431
https://zhuanlan.zhihu.com/p/26797422
RFC5766
stun协议笔记二（webrtc之turn流程简介）相关推荐
- 趣谈网络协议笔记-二（第十六讲上）
趣谈网络协议笔记-二(第十六讲上) 流媒体协议:如何在直播里看到美女帅哥? 自勉 给岁月以文明,而不是给文明以岁月!--<三体> 在触不到的獠牙上点火--就像不必仰望那星星就能够解决--就 ...
- 趣谈网络协议笔记-二（第十讲）
趣谈网络协议笔记-二(第十讲) UDP协议:因性善而简单,难免碰到"城会玩" 自勉 如果手上没有剑,我就无法保护你.如果我一直握着剑,我就无法抱紧你.--<Bleach> ...
- 趣谈网络协议笔记-二（第十五讲）我与刘超有不同看法
趣谈网络协议笔记-二(第十五讲) HTTPS协议:点外卖的过程原来这么复杂 前言 好饿啊= =,最近感觉自己真的是胖的不行了,所以开始了适当的节食操作. 我似乎很不擅长隐藏自己的想法.我似乎很不习惯于 ...
- 趣谈网络协议笔记-二（第十九讲）
趣谈网络协议笔记-二(第十九讲) HttpDNS:网络世界的地址簿也会指错路 自勉 勿谓言之不预也 -- 向为祖国牺牲的先烈致敬! 引用 dns缓存刷新时间是多久?dns本地缓存时间介绍 - 东大网管 ...
- 趣谈网络协议笔记-二（第十八讲）
趣谈网络协议笔记-二(第十八讲) DNS协议:网络世界的地址簿 自勉 勿谓言之不预也 -- 向为祖国牺牲的先烈致敬! 正文 DNS用于域名解析,但也不仅仅是用于域名解析,不仅仅是将域名转换成IP. 在 ...
- 趣谈网络协议笔记-二（第十七讲）
趣谈网络协议笔记-二(第十七讲) P2P协议:我下小电影,99%急死你 自勉 逃离舒适区! 正文 一. P2P协议 整个篇章讲的就是这两个协议之间的区别.P2P协议就是迅雷下载数据时所用的协议, 众所 ...
- 趣谈网络协议笔记-二（第十三讲）
趣谈网络协议笔记-二(第十三讲) 套接字Socket:Talk is cheap, show me the code 前言 这只是笔记,是为了整理刘超大神的极客时间专栏的只是而存在的! 经常会在网络上 ...
- 趣谈网络协议笔记-二（第十二讲）
趣谈网络协议笔记-二(第十二讲) TCP协议(下):西行必定多妖孽,恒心智慧消磨难 前言 哈哈哈,越当我看刘超的通俗讲解,我就越感觉自己的无能.每次当我看了讲解之后,每次当我感觉到这个东西原来是这么简 ...
- 趣谈网络协议笔记-二（第十一讲）
趣谈网络协议笔记-二(第十一讲) TCP协议(上):因性恶而复杂,先恶后善反轻松 自勉 我似乎天性不擅长争斗,但是有些时候,我也必须砥砺前行. 强大是和平的前提,而善良不是. 前言 今天回到家里已经是 ...
最新文章
- oracle数据库视图存放位置,oracle数据库审计
- 2017甲骨文JavaOne参会感想
- 第一章计算机基础知识作业答案,第一章 计算机基础知识.doc第一次作业
- CSS的伪类 :before 和 :after
- 100行Python代码的贪吃蛇
- 常用的排序算法（java版）
- 发布与安装Github Packages
- Android使用iconfont图标
- cad画钟表_cad应用环形矩阵制作钟表盘
- 我怎么就沦落到听新裤子的地步了呢？
- 网络带宽和下载速度的换算方法
- js将数字转换成中文大写
- java设置excel标题栏_Java EasyExcel写入Excel中复杂头(head)表中的标题的方法及示例代码...
- linux的veth导致网络不通,使用veth-pair和bridge搭建的本地网络环境网络不通
- nodejs爬虫淘宝详情图
- 【Javascript】二十个工具函数
- node.js express配置响应头解决跨域问题
- SELINUX+PASSWD实战
- 十大常见的用户认知偏差
- 谁是中国最大的门户网站？？