TURN协议(RFC5766详解)

摘要

   如果一台主机处于NAT后面，那么在一定条件下两台主机无法之间进行通讯。在这种条件下，那么使用中继服务提供通讯是有必要的。
这个规范定义了一个名为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。

[plain] view plain copy

1.                                        Peer A  
2.                                        Server-Reflexive    +---------+  
3.                                        Transport Address   |         |  
4.                                        192.0.2.150:32102   |         |  
5.                                            |              /|         |  
6.                          TURN              |            / ^|  Peer A |  
7.    Client's              Server            |           /  ||         |  
8.    Host Transport        Transport         |         //   ||         |  
9.    Address               Address           |       //     |+---------+  
10.   10.1.1.2:49721       192.0.2.15:3478     |+-+  //     Peer A  
11.            |               |               ||N| /       Host Transport  
12.            |   +-+         |               ||A|/        Address  
13.            |   | |         |               v|T|     192.168.100.2:49582  
14.            |   | |         |               /+-+  
15. +---------+|   | |         |+---------+   /              +---------+  
16. |         ||   |N|         ||         | //               |         |  
17. | TURN    |v   | |         v| TURN    |/                 |         |  
18. | Client  |----|A|----------| Server  |------------------|  Peer B |  
19. |         |    | |^         |         |^                ^|         |  
20. |         |    |T||         |         ||                ||         |  
21. +---------+    | ||         +---------+|                |+---------+  
22.                | ||                    |                |  
23.                | ||                    |                |  
24.                +-+|                    |                |  
25.                   |                    |                |  
26.                   |                    |                |  
27.             Client's                   |            Peer B  
28.             Server-Reflexive    Relayed             Transport  
29.             Transport Address   Transport Address   Address  
30.             192.0.2.1:7000      192.0.2.15:50000     192.0.2.210:49191  
31.   
32.                                 Figure 1  

图1显示一个典型的网络环境，在这张图中，TURN client处于NAT内，TURN server处于NAT外，
假设这个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任何一种协议。

[plain] view plain copy

1. +----------------------------+---------------------+  
2. | TURN client to TURN server | TURN server to peer |  
3. +----------------------------+---------------------+  
4. |             UDP            |         UDP         |  
5. |             TCP            |         UDP         |  
6. |        TLS over TCP        |         UDP         |  
7. +----------------------------+---------------------+  

如果TCP或TLS协议被用于client与server之间，那么server需要转为UDP协议与peer进行通讯。

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是不同的）

[plain] view plain copy

1. TURN                                 TURN           Peer          Peer  
2.   client                               server          A             B  
3.     |-- Allocate request --------------->|             |             |  
4.     |                                    |             |