摘要
这个规范定义了一个名为TURN(使用中继穿越NAT)的协议,它允许一台主机使用中继服务与对端进行报文传输。TURN不同于其它中继协议在于它
允许客户机使用一个中继地址与多个对端同时进行通讯。
TURN协议也是ICE(交互式连接建立)协议的组成部分,也可以单独使用。
1、简介
一个处于NAT内的主机想要与其他主机进行通讯,其他主机有可能也处于NAT内。为了实现这个目的,主机利用“打洞”的技术用于发现直接通讯的路径;然而,这个通讯路径能够直接穿越NAT而无需使用中继。
[RFC5128] and [RFC4787]定义的这种“打洞”技术不能够适用于任何NAT情况,例如某主机位于的NAT路由器使用的“地址依赖映射”
或“地址-端口依赖映射”,那么这种“打洞”技术通常会失败。
当无法找到一个直接通讯路径时,必须要使用到服务中继来进行互换报文。这种中继通常适用于在公网环境下,两个都处于NAT环境下的主机进行通讯场景。
本文定义了一个名为TURN的协议,它允许两个处于NAT环境的主机利用中继进行通讯。client能够在TURN Server上分配资源,与peer(对端)进行通讯,
也能够决定何时应该停止通讯。client需要关联一个TURN Server的地址作为中继,称为relayed server address。当客户发送报文给TURN Server,
TURN Server使用relayed server address作为源地址向其他peer进行中继转发报文。
client用到TURN服务必须通过某种方式获取peers的地址,这个超越了本文的范畴,可以使用email互换信息,另一种是可以参考[RFC5128]。
如果TURN被使用于ICE[RFC5245],那么relayed transport address和这些peers的地址都必须提供给ICE进行选择,
如果TURN和ICE被作为SIP协议的一部分,。。。。
通过TURN服务看起来能够很好的解决两个主机都位于NAT下的通讯问题,但是这对TURN Server是有高昂代价的,比如TURN Server必须在英特网上拥有大带宽,
如此,应该优先使用主机双方之间通讯的方式,只有在主机间无法直接通讯的情况下才使用TURN服务。
当client和peers使用ICE决定通讯路径时,ICE会优先考虑直接通讯,除非无法直接通讯才使用TURN。
TURN原来是设计用于支持多媒体会话通讯在SIP协议。从SIP协议派生后,TURN支持使用一个relayed transport address与多个peer通讯。
这个特写能够使TURN适应于不同的应用场景。
TURN被作为ICE(NAT穿越)框架的一个重要组成部分,然后TURN可以独立于ICE之外单独工作。
TURN是STUN(Session Traversal Utilities for NAT)的扩展协议,大多数情况下,TURN消息采用STUN的消息格式,读者应该的对STUN协议有所了解。
2、功能一览
这个节主要预览TURN协议功能,是非严格的描述。在大多情况下TURN client处于私有网络下,并且通过一个或者多个NAT连接到公网。TURN Server是位于公网环境下。
client想要与其他peer进行通讯。这些peer可能位于同一个或者不同的NAT内。client利用TURN中继地址向peer发送报文,
也通过TURN的中继地址收集peer报文并发送给client。
- Peer A
- Server-Reflexive +---------+
- Transport Address | |
- 192.0.2.150:32102 | |
- | /| |
- TURN | / ^| Peer A |
- Client's Server | / || |
- Host Transport Transport | // || |
- Address Address | // |+---------+
- 10.1.1.2:49721 192.0.2.15:3478 |+-+ // Peer A
- | | ||N| / Host Transport
- | +-+ | ||A|/ Address
- | | | | v|T| 192.168.100.2:49582
- | | | | /+-+
- +---------+| | | |+---------+ / +---------+
- | || |N| || | // | |
- | TURN |v | | v| TURN |/ | |
- | Client |----|A|----------| Server |------------------| Peer B |
- | | | |^ | |^ ^| |
- | | |T|| | || || |
- +---------+ | || +---------+| |+---------+
- | || | |
- | || | |
- +-+| | |
- | | |
- | | |
- Client's | Peer B
- Server-Reflexive Relayed Transport
- Transport Address Transport Address Address
- 192.0.2.1:7000 192.0.2.15:50000 192.0.2.210:49191
- Figure 1
假设这个NAT是一个"bad NAT"; 例如其使用"地址-端口依赖映射"的NAT。
client告诉服务的(IP和端口)组合称为client's HODST TRANSPORT ADDRESS。(也称为TRANSPORT ADDRESS)
client发送TURN消息给TURN server的TURN SERVER TRANSPORT ADDRESS。client通过其他途径(比如配置)获得这一地址。
client使用TURN命令进行创建和管理一个名为ALLOCATION的资源在TURN server上。一个allocation是TURN server里的一个数据结构。
它包含但不限于RELAYED TRANSPORT ADDRESS。turn server发送从client获得要发送的数据后并通过这个relayed transport address发送给相关的peer。
并且allocation可以通过relayed transport address作为唯一标示。
一旦一个allocation被创建,client能发送应用数据给server,并且通过server中继这个数据给相关的peer。client发送的数据还是TURN的消息;
当server收到后将从消息中提取DATA部分,并通过原始UDP报文发送给对应的peer。
反向,当server收到peer的UDP数据,会封住为TURN的消息格式发送个对应的client。消息中包含peer的相关信息,因此可以使用一个allocatoin与多个peer同时通讯。
当peer处于NAT内,client必须指定peer的server-reflexive transport address,而不是它的host transport address,举例,
在上图示例中,向PeerA发送数据时,在client必须指定192.0.2.150:32102 (Peer A's server-reflexive transport address),
而不是192.168.100.2:49582 (Peer A's host transport address)。
在server端,每个allocation都能够关联一个单独client,这样能保证relayed transport address收到数据后只会被传送给对应的client。
client可以同事拥有多个allocation在服务端。
2.1传输方式
TURN,在本文的定义中,server与peer间总是使用UDP通讯。然而,client与server间可以使用UDP,TCP,TLS任何一种协议。- +----------------------------+---------------------+
- | TURN client to TURN server | TURN server to peer |
- +----------------------------+---------------------+
- | UDP | UDP |
- | TCP | UDP |
- | TLS over TCP | UDP |
- +----------------------------+---------------------+
TURN当前这个版本只允许peer与server之间使用UDP协议,估计大部分client也向使用UDP与server进行通讯,为何还要设计TCP和TLS的通讯方式呢?
TURN支持client与server使用TCP协议是因为有些防火墙完全阻止UDP协议,另外因为TCP对防火墙而且认为更加安全。举例,TCP使用
三步握手机制能够明确表明是用户所期望产生的行为。相对UDP而且,防火墙还需要花一定时间来判断连接是否失效,而TCP连接失效能够立刻反映出来。
TURN支持client与server间使用TLS是因为某些安全方面的需求,然而不推荐默认使用该协议,因为对server而且会带来加解密额外的性能开销。
2.2 Allocations
client使用allocate事务创建一个server端的allocation。client发送一个Allocate请求到server端,server回应allocation创建成功的相应给client,并且携带相应的relayed transport address。client可以在Allocate请求中携带所期望的属性(例如:allocation的存活周期等)。
如果数据有安全的考虑,server必须要求client进行认证授权,通常使用STUN协议定义的long-term认证方式。
一旦relay transport address被创建,client必须保持它存活。那么client需要主动发起Refresh请求给server进行刷新。
TURN新定义Refresh方法而不复用Allocate方法进行刷新是为了明确Allocatoin失效是由于某些的原因。
Refresh事务的频率由allocation存活时间决定,allocation默认存活时长是10分钟--设置这么长的时间是为了减轻client段刷新的负担。
并且当client意外退出是allocation能及时的失效。然而,client可以在Allocation请求设置一个长时间的存活时间,或者在Refresh请求修改这个一时间。
server总是在Allocate或Refresh回应消息中携带一个真实的存活时间。如果client相应释放这个allocation,可以在Refresh请求中将存活时间设置为0,
server端就会删除这个allocation。
server和client都保存一个5元组。client端,5元组包括client's host transport address,server transport address,传输协议。
server端,5元组和client类似,唯一不同的是server使用的server-reflexive transport address,而不是client's host transport address。
在Allocate请求时server和client能够保存5元组。在随后的消息中都会使用到5元组。这样client和server都知道哪些allocation。
如果client相应申请一个新的allocation,则必须使用不同的5元组(比如client;t host transport address是不同的)
- TURN TURN Peer Peer
- client server A B
- |-- Allocate request --------------->| | |
- | | |