RFC5766-TURN协议
摘要
这个规范定义了一个名为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 --------------->| | |
| | | |
|<--------------- Allocate failure --| | |
| (401 Unauthorized) | | |
| | | |
|-- Allocate request --------------->| | |
| | | |
|<---------- Allocate success resp --| | |
| (192.0.2.15:50000) | | |
// // // //
| | | |
|-- Refresh request ---------------->| | |
| | | |
|<----------- Refresh success resp --| | |
| | | |在图2中，client没有携带鉴权信息发送Allocate请求给server。但server要求所有请求必须使用STUN的long-term授权机制时，
server会返回401错误，要求重新鉴权。client第二次携带鉴权信息重新发送Allocation请求，server回复allocation创建成功，并且
携带relayed transport address。稍后client发起Refresh请求给server,server回应Refresh请求成功。
2.3 Permissions (许可）
为了避免使用防火墙安全机制，TURN定义了许可的概念。TURN许可仿照了“NAT地址过滤限制[RFC4787]”机制。
一个allocation可以用0个或更多的许可。每个许可包含了IP地址和存活时间。当server的中继地址(relayed transport address)接收UDP报文后
必须检查源地址是否包含在许可列表中。如果源地址被匹配成功，则将UDP报文中继给client，否则则丢弃该报文。
一个许可在未刷新的5分钟之后失效，并且无法显示的删除许可。这个行为是匹配NAT规范。
client可以使用CreatePermission或ChannelBind请求进行创建和刷新许可。一个CreatePermission请求里可以携带多个被安装或刷新的许可。
--这点ICE里十分重要。处于安全考虑，许可只能创建和刷新，并且可以被验证。但是Send和ChannelData消息不需要安装和刷新任何许可。
注意，一个许可是携带allocation上下文的，因此一个allocation的许可失效是不会影响其他allocations的。
2.4 传输机制
这里有两种使用TURN服务让client与其peers进行交换数据的方式。第一种是使用Send和Data方法，第二种是使用通道。这两种方法能够利用一个中继地址与多个peers进行通讯。也意味着server收到client的数据后发送给peers，
收到peers数据后发送给client。
第一种方式下，client通过Send方法发送应用数据给server，而server使用Data方法发送数据给client。
使用这种发送机制时，client发送Send信令给server时需要包含XOR_PEER_ADDRESS属性，并且填写peer的NAT外地址（server-reflexiv）,而不是peer的主机地址。
使用DATA属性包含应用数据。server收到Send信令提取DATA数据并用中继地址作为源地址向peer发送UDP报文。
注意这里无需指定中继地址，因为Send信令已经隐含了5元组。
反向而言，当server的中继地址收到UDP报文，将其转化为Data信令发送给client，XOR_PEER_ADDRESS属性携带peer的NAT外地址，data包含在DATAT属性中。
因为中继地址是allocation的唯一标示，所有通过中继地址能够确定哪个client需要接收该数据。
Send和Data信令不能进行STUN的long-term认证。这对这套发送机制而言并不是大问题。
因为Send信令无法进行授权认证，为避免一个攻击者伪造send数据，因此在发送Send信令前需要安装许可。
TURN TURN Peer Peer
client server A B
| | | |
|-- CreatePermission req (Peer A) -->| | |
|<-- CreatePermission success resp --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<-------------- Data ind (Peer A) --| | |
| | | |
| | | |
|--- Send ind (Peer B)-------------->| | |
| | dropped | |
| | | |
| |<== data ==================|
| dropped | | |
| | | |
Figure 3
图3中，client已经创建好了allocation。首先client发送CreatePermission请求在XOR-PEER-ADDRESS属性中携带PeerA的NAT地址进行许可创建。
如果这一步未完成，则无法进行中继。然后client通过Send信令发送数据给server，server中继给PeerA。当server中继地址收到PeerA的UDP报文
后，将其转化为Data信令中继给client。最后，client相应中继给PeerB，但是之前没有安装许可因此server将其丢弃，PeerB发送给中继地址
的UDP报文也同样被丢弃。
2.5 Channels（通道）
某些应用场景下（例如VoIP),使用Send或Data信令需要36字节的负担，这样大大增加了client到server间的带宽。为解决这个问题，client利用server发送指定peers通讯方式有另一种选择。
这种方式是利用一种名为ChannelData的另一种消息格式。ChannelData消息不同与之前的消息格式，它不是使用STUN格式的消息。
而是使用4自己的头部用于标示一个通道ID，每一个通道ID都对应指定的peer，可以使用peer host transport address对应。
为了将peer绑定为一个通道，client需要向server发送ChannelBind请求，并且包含通道ID和对端地址信息。一旦通道绑定成功，
client可以使用ChannelData消息向peer传送数据。同样server的中继地址收到peer消息后也会转换为ChannelData消息发送给client。
通道绑定存活时间为10分钟长于许可的存活时间5分钟，通道绑定刷新请求需要重新发送ChannelBind请求。类似于许可，通道绑定也无法
显示取消绑定，只能等待通道绑定超时失效。
TURN TURN Peer Peer
client server A B
| | | |
|-- ChannelBind req ---------------->| | |
| (Peer A to 0x4001) | | |
| | | |
|<---------- ChannelBind succ resp --| | |
| | | |
|-- [0x4001] data ------------------>| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
|--- Send ind (Peer A)-------------->| | |
| |=== data ===>| |
| | | |
| |<== data ====| |
|<------------------ [0x4001] data --| | |
| | | |
Figure 4
图4展现了通道传输机制。在传输之前client已经创建了allocation。client发送ChannelBing请求给server,
指定PeerA的地址和通道ID(0x4001)。在稍后的ChannelData消息中必须携带相同的通道ID(0x4001).
当server收到ChannelData消息将Data封装为UDP报文发送给PeerA。
反向而言，当server中继地址收到PeerA的UDP报文，通过中继地址能关联到一个allocation，server将其封住为ChannelData消息方式给client，
并且填写通道ID为(0x4001)。
一旦一个通道绑定成功，client可以自由选择Send信令或ChannelData消息向peer发送数据。在这张图的最后，client选择Send信令向peer传输数据。
下一章节将介绍IP的是否允许分配。而且一旦一个通道绑定，client只会收到server发来的ChannelData消息。
注意，通道只能被用于被绑定的peer,上图只能适用于PeerA，而PeerB这无法利用这个通道。
2.6 TURN Server的限制
当前版本的TURN被定义于使用用户空间实现，而非操作系统内核，因此无法使用操作系统的特权级别。之所以如此设计，是希望TURN server能够很好的集成到其他应用之中来实现NAT穿越。
这种设计原则对中继服务有以下局限性。
* 无法选择不同的服务类型
* IP报文存活时间(Time to Live:TTL)字段无法被用户设置。
* 显示拥塞通知(Explicit Congestion Notification: ECN)字段无法被用户设置
* ICMP消息无法被中继。
* 没有end-to-end分段，当报文被重传时。
在未来可以考虑解决这些局限性。
2.7 避免IP分片
在某些特殊因素的应用中，尤其是某些需要发送大量数据的情况需要避免数据被IP分片。如果使用TCP协议可以忽略这点，因为在标准的TCP协议中已经考虑IP分片的因素。但是如果使用UDP协议，必须要考虑避免IP分片。
有以下两种避免IP分片的方法。
第一种避免IP片方法是避免client和peer直接传输大量的应用数据，这种方法比较适用于VoIP这种音频数据，IP报文的长度最后不要超过576字节。
这个方案需要首先考虑传输方式是TCP,UDP还是TLS，然后是使用Send/Data信令还是ChannelData消息进行数据传输。另一个因素是很难处理的，
例如使用IP隧道技术时很难处理路径MTU逐渐减少的情况。
作一个参考，（client到server）的应用数据和(server到peer）的UDP报文的最大长度最多500字节，为了进一步减少IP分片的情况，优先使用ChannelData消息，
因为其更为节省字节。
第二种方式是，client和peer各种使用路径MTU发现机制来决定其应用程序数据的大小上限。
不幸的是，由于TURN server无法对ICMP进行中继，因此经典的路径MTU发现机制（RFC1191）无法解决client到peer的路径MTU发现。
因此client和peer无法利用ICMP消息作为路径发现的原理，[RFC4821]定义路径MTU发现的算法。
具体如何使用[ rfc4821 ]算法依次仍在研究。然而，为实现这一目标的步骤，这个版本将支持dont-fragment属性。
2.8 RTP 协议支持
一个使用TURN进行音频或者视频进行实时数据的例子是需要使用RTP协议，为了实现这个目录，TURN包含了支持这协议的一些特性。老版本RTP[RFC3550]要求RTP流和其RTCP流的端口是RTCP=RTP+1的关系，因此TURN允许client创建allocatoin时保留之后的一位端口，
便于在随后的分配时提供。
2.9 Server的选播发现机制
这个版本TURN协议设计了一个基于UDP协议的server发现机制。具体而言，一个TURN server可以拒绝一个Allocate请求，并且建议client尝试一个备选server。为了避免某些类型的攻击，client必须使用相同
鉴权信息进行鉴权。
3 术语
本文档包含“必须”，”必须不"，”要求”，“应该”，“不应该”，“需要”，“不需要”，“推荐”，“可能”，“可选”等关键字已经被定义于RFC 2119中。
预计读者已经阅读RFC5389相关的定义。
本文的定义有：
TURN: 这个协议是STUN协议的扩展，本协议允许client利用中继服务与相关peer通讯。
TURN client: 本协议规范了TURN client的实现
TURN server: 本协议规范了TURN server的实现，提供client中继数据给它的peers。
Peer: 一个TURN client相应通讯的主机，peer与server直接的通讯并不使用本协议，直接使用UDP。
Transport Address: IP地址和端口的组合
Host Transport Address: client和peer的主机地址。译者注：NAT内地址。
Server-Reflexive Transport Address: 一个client/peer在其公网NAT端的映射地址，这个地址有路由器和主机地址进行互换。译者注：NAT外地址。
Relayed Transport Address: TURN server分配的与client和peer进行中继的地址。 译者注：中继地址。
TURN Server Transport Address: TURN消息的交换地址。这个地址被用于client与server进行交互。译者注：server地址
Peer Transport Address: Peer的地址，如果Peer位于NAT内，则该地址表示PeerNAT的地址。译者注:对端地址
Allocation: 由client使用Allocate请求生成的中继地址，并伴随着许可和存活时间等状态。
5-tuple: 5元组，client端是（client's NAT内地址，server地址，传输类型），server端（client's NAT外地址,server地址，传输类型）是allocation的唯一标识。
Channel: 通道，一个通道ID绑定了一个对端地址，一旦通道绑定成功，client和peer可以使用通道进行更节省带宽的交互。
Permission: 许可，由一个IP地址和协议（无端口）向关联的通道，是client向peer通讯和peer向client通讯的许可。
Realm: 用于描述服务器上下文的字符串。该Realm将告知client,并被用于用户名和口令的校验。
Nonce: 一个服务器随机选择的信息摘要，为了防止重复攻击，服务器应该定期进行更换。
Indications: 译者注：一个Send/Data的机制，用于传输数据的信令。
4、通用行为
这节包含TURN的通用处理规则是相应所有的TURN消息。TURN是STUN协议的扩展。所有TURN消息，除ChannelData消息外，都是STUN的消息格式。所有集成的处理规则被定义于RFC5389响应STUN消息。
这意味着所有消息格式和消息处理规则都被定义于RFC5389。
[RFC5389]定义的鉴权机制称为long-term认证机制。TURN server和client“必须”实现这个机制。服务端"必须"对所有client的请求消息进行这种
认证机制进行校验。或者使用一个同样强大的认证机制。
注意，long-term认证机制只针对于请求消息，而不校验indications(信令)，换言之indications在TURN server无需鉴权。如果server要求请求需要校验，
server管理者选择一个realm值并且选择唯一的username和password组合给client使用，除非client使用多个server外。
server管理者“可能”选择不重复的username给不同的client使用，或者使用同样的username给所有client。
对于每个allocation,server“应该”生成新的随机nonce在第一个分配时。
在创建allocation后的所有请求都必须使用相同的username并且使用这个allocation,防止攻击则挟持client's allocation。
具体而且，如果server要求使用long-term认证机制，并且非Allocation请求通过鉴权机制，并且5元组标示存在于allocation，但是
这个请求的username不同于创建于allocation时的username，则server必须拒绝这个请求，并且返回441（非法权限）的错误。
当server收到client的TURN消息后，server使用5元组来识别相关的allocation。对所有TURN消息而言（包括ChannelData消息），如果5元组没有
找到关联的allocation，如果是请求消息（eg, Refresh,ChannelBind)将返回437（Allocation未找到的消息），如果是数据消息（eg Send/Data Ind，或者ChannelData)
则被丢弃。如果client收到437消息后必须认为allocation已经不存在。
[RFC5389]定义一下属性，例如DSOFTWARE和FINGERPRINT属性。client需要在Allocate和Refresh消息中包含SOFTWARE属性，也可以在其他消息包含该属性。
server应该在Allocation/Refressh的响应消息中包含SOFTWARE消息（无论成功还是失败），也可以在其他消息中包含该属性。
client和server可能包含FINGERPRINT属性在STUN格式的消息中。
TURN不使用定义于[RFC5389]的向后兼容的机制。
TURN，定义在本文档中只支持IPv4。client地址，服务器地址和所有地址必须为IPv4地址。
默认情况下，TURN使用和STUN相同的端口，UDP和TCP使用5348，TURN的TLS使用5349。也应该有自己的服务名字，如TURN for UDP/TCP,TURN for TLS。
所有的服务记录名字和备选服务的机制都定义在第6节。TUNR也可以使用不同的端口。
为确保互操作性，TURN服务必须实现UDP协议进行client和server交互，也应该实现TCP和TLS的交互方式。
当client使用UDP传输协议和server进行交互时，必须实现重传机制当一定时间内未收到响应时。正是因此，server可能收到2个或者更多的请求携带着相同的5元组和事务号。
TURN要求识别这种情况，并参考[RFC5389]进行处理。一些实现可能要求所有的请求在40秒之内收到响应，。。。。。
当client使用TCP传输协议和server进行交互时，可以由于某些错误导致包长度字段受损，使得接收方丢失同步信息流，如果发现这种情况应该将连接断开，让其它端能够
及时发现。
为了避免有意或无意的拒绝服务攻击，client应该提供有效的用户名和密码。建议server限制username同时可分配的allocaiton数量和带宽。
当server的allocation数量达到上限时，应该拒绝分配新的allcation，返回486(资源不足)的错误码，并且丢弃已经超过带宽限制的数据。
5、Allocations
所有TURN操作都围绕着allocations，并且TURN消息都关联了一个allocation。一个allocatoin伴随以下这些状态：* 中继地址
* 5元组
* 鉴权信息
* 存活时间
* 许可列表
* 通道绑定列表
中继地址是server所分配的并用于server与peers进行通讯，5元组用于client和server通讯的标示。
client端是（client's NAT内地址，server地址，传输类型），server端（client's NAT外地址,server地址，传输类型)。
中继地址和5元组都能唯一标识一个allocatoin。
鉴权信息（包括，用户名，口令，realm,nonce)被使用与校验随后的消息并且提供回应消息的完整信息。用户名、realm,nonce在Allocate请求中被确定。
nonce在存活周期内可以利用438（nonce改变）响应进行改变。注意，处于安全考虑，Nonce是realm,username,password的hash值。
存活时间是一个allocation是有效期，以秒为单位。每个Allocation和Refessh事务设置它的值。默认情况下，它的值为10分钟，但是client可以
在Allocation和Refresh请求内携带一个指定值。Allocations只能用Refresh请求刷新存活时间。发送数据给peer并不代表刷新存活时间。
当allocatoin超时失效，它所伴随的状态都将被释放。
许可将在第8节进行讲解，通道将在第11节进行讲解。
6、创建Allocation
allocation是使用Allocate请求进行创建的。6.1 发送Allocate请求
client发送Allocate请求需要有如下要求。client首先获取到自己的主机地址。建议利用soket来选择一个未被使用的地址。
client选择一个协议用于与server进行通讯。传输协议必须是UDP,TCP,TSL之一。因为server与peers直接只能适用UDP，如果没有其他特殊原因应该
优先使用UDP协议。2.1节讲解选取TCP,TSL作为传输协议的原因。
client需要获取server地址（可能通过配置）需要做如下事情，通过域名获取server的地址。
client在Allocate请求中必须包含REQUESTED-TRANSPORT属性指示选择的传输协议。这个传输协议被用于server与peers之间（注意，这不是client的5元组的协议）。
目前这个值只能为UDP,但是未来可以扩展为其他协议。
如果client需要指定一个allocation的存活时间可以设置LIFETIME属性。这仅仅是请求值，server可以根据情况选择是否使用，还是使用默认值。
如果client想要在后续Send indication使用DONT-FRAGMENT属性，可以在请求中携带该属性。这个可以让client测试server是否支持该属性。
如果client响应保留一位中继地址，可以使用EVEN_PORT属性。这样要求server为其分配中继地址时，保留中继地址+1端口，以便在随后分配给client。
client可以使用RESERVATION-TOKEN属性来获得server保留的中继地址，此时不能再使用EVEN_PORT属性。
一旦构造，client发送Allocation请求确定5元组。
6.2 接收到Allocate请求
当server接收到Allocate请求，需要进行如下检查。1、Server必须对请求使用long-term机制进行鉴权检查，除非client和server使用其他机制进行认证。
2、Server需要检查该5元组是否已经存在allocatoin，如果存在，则拒绝请求并返回437（Allocation不匹配）错误。
3、Server需要检查请求是否协议REQUESTED-TRANSPORT属性，如果属性不存在或者是非法的则返回400 (Bad Request)错误，否则如果不是UDP协议，
则返回442 (Unsupported Transport Protocol) error。
4、请求可能携带DONT-FRAGMENT属性，如果server不支持该属性，则忽略。
5、Server检查是否包含RESERVATION-TOKEN属性，如果是但是又包含EVEN-PORT属性，则拒绝并回复400 (Bad Request) error。否则则检查TOKEN
是否有效，如果无效则拒绝并返回508 (Insufficient Capacity)error。
6、Server检查请求是否携带EVEN-PORT属性，则需要找到两个端口连续的中继地址，如果无法满足这种条件，则拒绝并回复508 (Insufficient Capacity)error。
7、任何情况下，client如果已经分配到的上限，server可以拒绝并回复486 (Allocation Quota Reached)error。server应该要求检查client的用户名，而不是地址。
8、在任何情况下，server可以回复一个300(Try Alternate)错误码，将client重定向到另一个server。这个错误码定义在[RFC5389]中。
如果一切都检查通过，这server创建allocation,5元组被设置在这个allocation中，此时许可列表和通道绑定列表为空。
server为allocation选择中继地址遵从下面事项：
*如果请求中包含RESERVATION-TOKEN属性，server选择之前保留的中继地址（如果仍然可用）。
注意这个保留是服务端的行为，这次Allocate请求的5元组应该不同于之前的5元组，可以使用不同的client地址或端口，甚至不同的server地址或端口。
*如果请求包含EVEN-PORT属性，并且R bit设置为0，则server选择中继地址是一任意端口。
*如果请求包含EVEN-PORT属性，并且R bit设置为1，则server选择一对端口N，N+1，Port N被用于当前allocation，端口N+1将被保留，用于后续的
allocation，server必须保留端口30秒，甚至更长，例如这个allocation失效，server将这个token通过RESERVATION-TOKEN属性填写到回应消息中。
*否则，server选择任意可用的中继地址。
上述所有情况，serve应该选择端口的范围是49152 - 65535，除非TUNR server知道哪些端口可以被使用。如论如何，TURN server都不能使用0-1023之间的端口。
server决定allocation存活时间的初始值如下。如果请求中携带LIFETIME属性，server选择这个值与server允许最大存活时间直接取最小值。
如果这个结果大于默认时间（10分钟），则使用这个值，否则使用默认时间。我们推荐server的设置最大存活时间不要超过1小时。因为当client
由于某种原因断开连接时，server需要利用这个超时时间进行释放allocatoin。同样，这个规则也使用与Refresh请求，这个值将在第一次刷新是被重新计算。
一旦allocaton创建成功，server需要回复一个成功回应消息，应该包含：
*XOR-RELAYED-ADDRESS 关联的中继地址。
* LIFETIME server决定的存活时间
* RESERVATION-TOKEN （如果需要保留中继地址时才用）
* XOR-MAPPED-ADDRESS （ client的NAT外地址）
这个回应是（无论成功还是失败）都将发生给client通过5元组。
注意： 当Allocate请求使用UDP传输时，因为重传原因server端可能收到相同的Allocate请求消息，server应该避免创建多个allocation。
可能需要使用一种叫”无状态协议栈的方法“来实现如下。
需要识别重传消息，通过事务号和五元组。一旦识别为重传消息，server无需解析直接回复成功。当构造回应消息时，这个存活时间和原始可能不同，
如果原始请求没有创建成功下，这个消息没有什么特殊的，但是注意的是client可能收到第一个请求创建失败，而由于重传收到第二个请求创建成功，
此时client可能无法使用这个回应，那么已经被创建的allocatoin只能等待超时，因为client不会进行刷新。
6.3 接收成功的回应
当client接收到成功回应时，必须校验MAP Address和Delayed Address是否是同一个协议簇。当前这个版本定义这个两个地址只能是IPV4，如果这两个地址不是这个协议簇，这需要删除这个allocation，并且不要创建另一个allocations直到server解决这个问题。
否则，client记录这些数据，特别是存活时间，不是请求中的，而是回应中的。client要记录5元组，并且保持username,password被用于鉴权。
client也可能利用MAP-Address与它peers进行通讯，它是ICE的一个过程。
6.4 接收失败的回应
当client收到错误Allocate错误回应时，它的处理依赖实际的错误码。* （请求超时） 可能是server端错误，或者选择错误的server端地址，client考虑使用不同的传输协议（TCP)进行重试。
* 300 （重定向） server想要client使用另一个server进行通讯，在 ALTERNATE-SERVER属性中指定该服务的地址。client认为这次处理失败，
应该尝试连接这个服务。当client连接备选服务器是的过程被定义于 [RFC5389]。
* 400(错误请求消息） server认为client的请求是不合法的。client认为创建失败，并且通知给用户，不要再次进行请求除非确保server问题已经解决。
* 401 (未授权）如果client已经使用long-term鉴权机制，否则认为创建失败，并且通知用户。
* 403 (拒绝）这个请求是合法的，但是server无法处理，比如管理限制。client认为创建失败。
*420（未知的属性）当client发送DONT-FRAGMENT属性给server,但server不支持该属性，回复绝交，并指明该属性为未知属性，client收到错误消息后
可以认为server不支持该属性，并且去掉该属性重新发送Allocate请求。
*437 (Allocatoin失效） client认为创建失败，client使用另一个地址重新请求，当重试3次之后还不成功，2分钟只能不能再次请求。
*438 (过期的Nonce) : 参见[RFC5389]的long-term认证机制。
* 441 (错误的认证)： client认为创建失败，并且通知用户。
* 442 （不支持的传输地址）client可能填写非UDP传输类型导致server返回不支持。
* 486 （Allocation达到上限）client认为server已经无法分配资源，认为创建失败，并且提示用户。
* 508 （能力不足） client可能携带EVEN-PORT或者 RESERVATION-TOKEN属性用于创建allocation，server无法满足client的条件会返回该错误码，
client可以去除这个两个属性重新进行Allocate，否则应该等待1分钟以上再次创建allocation。
其他未知错误的处理行为参考[RFC5389]。
7、刷新Allocation
Refresh事务可用于刷新存活时间和删除Allocation两种用途。client如果想继续使用Allocation需要在失效前进行刷新。建议在失效期前1分钟进行刷新。如果client不想使用这个allocatoin
需要删除allocation。client可能由于某些原因在任何时间进行刷新。
7.1 发送Refresh请求
如果client需要立即删除allocation需要包含属性LIFETIME值设为0.刷新事务用于更新allocation的存活时间。如果client需要指定存活时间可以携带LIFETIME属性。当这个属性值为0时，server立即删除这个allocation。
7.2 接收Refresh请求
当server收到刷新请求，处理规则如下：server决定存活时间，如果第6节的一段所介绍一样。
如果请求包含LIFETIME属性并且为0，则为0，如果不为0，server选择这个值与server允许最大存活时间直接取最小值。
如果这个结果大于默认时间（10分钟），则使用这个值，否则使用默认时间。
下面server决定存活时间有如下处理：
*如果存活时间为0，那么server立即删除allocation。
*如果存活时间非0，那么响应成功后更新allocation的存活时间。
如果请求成功，server发送回应消息包括如下属性：
*LIFETIME 包含server所决定的存活时间。
注意：关于使用UDP是会收到重传的处理。
7.3 接收Refresh请求回应
如果client收到存活时间为非0的刷新成功响应后，那么应该使用相应中存活时间值来更新allocatoin响应的存活时间数据结构。当client删除一个allocation收到一个437 (Allocation Mismatch) 错误时，有可能是重传消息导致，也认为这个allocation已经不纯在了，事务执行成功。
8、Permissions(许可）
其实读到这里，基本上已经理解TURN协议了，有时间再补上。9、创建Permission
10、发送数据方式
11、Channels
12、IP头字段
13、STUN新方法
这节列举了本文档新定义的方法。0x003 : Allocate
0x004 : Refresh
0x006 : Send
0x007 : Data
0x008 : CreatePermission
0x009 : ChannelBind
14、Stun新属性
这个Stun扩展协议定义如下新属性：0x000C: CHANNEL-NUMBER
0x000D: LIFETIME
0x0010: Reserved (保留，可用于带宽)
0x0012: XOR-PEER-ADDRESS
0x0013: Data
0x0016: XOR-RELAYED_ADDRESS
0x0018: EVEN-PORT
0x0019: REQUESTED-TRANSPORT
0x001A: DONT-FRAGMENT
0x0021: Reserved (was TIMER-VAL)
0x0022: RESERVATION-TOKEN
15、新错误码
403 (Forbidden):437 (Allocation Mismatch):
441 (Wrong Credentials):
442 (Unsupported Transport Protocol):
486 (Allocation Quota Reached)：
508 (Insufficient Capacity):
参见6.4的描述
16、示例
下图的示例都基于图1的网络环境进行展示的，请回顾图1的网络环境。
TURN TURN Peer Peer
client server A B
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example client, version 1.03" | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| | | |
|<-- Allocate error response --------| | |
| Transaction-Id=0xA56250D3F17ABE679422DE85 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=401 (Unauthorized) | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| | | |
|--- Allocate request -------------->| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example client 1.03" | | |
| LIFETIME=3600 (1 hour) | | |
| REQUESTED-TRANSPORT=17 (UDP) | | |
| DONT-FRAGMENT | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Allocate success response ------| | |
| Transaction-Id=0xC271E932AD7446A32C234492 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=1200 (20 minutes) | | |
| XOR-RELAYED-ADDRESS=192.0.2.15:50000 | |
| XOR-MAPPED-ADDRESS=192.0.2.1:7000 | |
| MESSAGE-INTEGRITY=... | | |
客户选择一个本机地址用于这个TURN会话；例如使用（10.1.1.2:49721)在图1网络环境所描述的。客户发送一个Allocate请求到服务端的监听地址。并使用一个随机分配的96位事务号;并且包含到消息头格式中。客户使用SOFTWARE属性表示客户的软件信息;这里使用”Example client,version 1.03”作为示例。客户包含的LIFETIME属性值为1小时，大于服务端存活时间的默认最大值10分钟。在Allocate请求中必须包含REQUESTED-TRANSPORT属性，并且仅允许值为17，表示server到peer之间使用UDP进行通信。客户也可以包含DONT-FRAGMENT属性，因为可能想要在随后的Send indications中被使用;
服务端要求请求是被鉴权过的。然而，当服务端接受到初始Allocate请求时，会拒绝请求因为没有携带鉴权信息。根据STUN[RFC5389]定义的长期鉴权机制，服务端返回401错误的响应，并且携带REALM属性表示server的realm（在这个例子中是“example.com”）,并且包含NONCE属性，也包含SOFTWARE属性表示服务端的软件信息。
客户端收到401错误需要重新发起Allocate请求，这次需要包含鉴权的属性。客户端选择一个新的事务号。客户端包含USERNAME属性并且包含401返回消息中所得到的REALM和NONCE属性，最终客户需要包含MESSAGE-INTEGRITY作为消息最后一个属性。它的值是通过加密算法(HMAC-SHA1)基于上面的几个属性和password计算得出。攻击者在没有password的条件下是无法计算出它的值的。
服务端收到携带鉴权消息的Allocate请求后，如果一切正常，就会创建allocation。服务端返回成功回应。服务端返回LIFETIME属性告诉allocation的存活时间。这里返回的是20分钟比请求时的1个小时要小。服务端返回的XOR-RELAYED-ADDRESS属性携带中继地址。XOR-MAPPED-ADDRESS属性包含了客户的NAT外地址，这个值在TURN协议没有使用，但是返回给客户。MESSAGE-INTEGRITY属性用于保证返回消息的完整性，注意返回消息中没有USERNAME,REALM,NONCE属性。还是可以包含SOFTWARE属性。
TURN TURN Peer Peer
client server A B
|--- CreatePermission request ------>| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| XOR-PEER-ADDRESS=192.0.2.150:0 | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- CreatePermission success resp.--| | |
| Transaction-Id=0xE5913A8F460956CA277D3319 | |
| MESSAGE-INTEGRITY=... | | |
客户使用CreatePermission请求创建PeerA的许可。XOR-PEER-ADDRESS属性包含了PeerA的地址。注意端口是被忽略的。这里端口被设置为0.注意PeerA的地址应该是外网地址，而不是主机地址。客户使用和allocate请求中相同的username,realm,nonce属性。可以选择不包含SOFTWARE属性。
服务端接受到创建许可请求后进行创建，并且返回成功的消息。类似客户端，服务端在回应请求中也可以不包含SOFTWARE属性。
TURN TURN Peer Peer
client server A B
|--- Send indication --------------->| | |
| Transaction-Id=0x1278E9ACA2711637EF7D3328 | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DONT-FRAGMENT | | |
| DATA=... | | |
| |-- UDP dgm ->| |
| | data=... | |
| | | |
| |<- UDP dgm --| |
| | data=... | |
|<-- Data indication ----------------| | |
| Transaction-Id=0x8231AE8F9242DA9FF287FEFF | |
| XOR-PEER-ADDRESS=192.0.2.150:32102 | |
| DATA=... | | |
服务端收到客户的Send indication后，使用中继地址作为源地址向PeerA发送UDP数据报，并且确定DF标记。注意，如果没有PeerA地址的许可，那么服务端收到客户的Send indication后会丢弃报文。
PeerA发送UDP报文给服务端，服务端中继地址收到报文后，会构造Data indication，将UDP报文的源地址放到XOR-PEER-ADDRESS属性中，UDP报文数据放到DATA属性中发送给客户。
TURN TURN Peer Peer
client server A B
|--- ChannelBind request ----------->| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| CHANNEL-NUMBER=0x4000 | | |
| XOR-PEER-ADDRESS=192.0.2.210:49191 | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- ChannelBind success response ---| | |
| Transaction-Id=0x6490D3BC175AFF3D84513212 | |
| MESSAGE-INTEGRITY=... | | |
服务端收到请求，将Channel号与PeerB绑定好，回复成功响应。
TURN TURN Peer Peer
client server A B
|--- ChannelData ------------------->| | |
| Channel-number=0x4000 |--- UDP datagram --------->|
| Data=... | Data=... |
| | | |
| |<-- UDP datagram ----------|
| | Data=... | |
|<-- ChannelData --------------------| | |
| Channel-number=0x4000 | | |
| Data=... | | |
现在客户发送ChannelData消息给服务端目的发网Peer B。ChannelData不是STUN消息格式，没有事务号，只有三个字段，分别是通道号，消息长度，消息。通道号就是上面所指定的值（这里0x4000)。服务端收到消息后检查下通道号，并使用UDP报文发给Peer B。
随后，Peer B发送UDP报文到服务端中继地址，服务端创建ChannelData消息发给客户，服务端上知道通道号，因为根据Peer B的地址可以查找之前绑定时的通道号，如果之前没有绑定，那么服务根据是否创建许可，如果有使用Data indication 发往客户端。
TURN TURN Peer Peer
client server A B
|--- Refresh request --------------->| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="adl7W7PeDU4hKE72jdaQvbAMcr6h39sm" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh error response ---------| | |
| Transaction-Id=0x0864B3C27ADE9354B4312414 | |
| SOFTWARE="Example server, version 1.17" | |
| ERROR-CODE=438 (Stale Nonce) | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| | | |
|--- Refresh request --------------->| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example client 1.03" | | |
| USERNAME="George" | | |
| REALM="example.com" | | |
| NONCE="npSw1Xw239bBwGYhjNWgz2yH47sxB2j" | |
| MESSAGE-INTEGRITY=... | | |
| | | |
|<-- Refresh success response -------| | |
| Transaction-Id=0x427BD3E625A85FC731DC4191 | |
| SOFTWARE="Example server, version 1.17" | |
| LIFETIME=600 (10 minutes) | | |这20分钟之内，客户端发起刷新请求给服务端，有时候服务端认为Nonce信息已经过期，会回应一个438端错误吗给客户端，并且携带新的nonce属性，注意nonce属性有变化，客户端需要再次使用新的nonce发起刷新，服务端收到新的刷新后回复成功响应。当然438错误不是必须的，根据服务端的策略而定。