基于stun, turn, ice协议的NAT穿越


stun, turn, ice协议概述

stun,turn,ice是ietf提出的处理voip网络中nat穿越问题的协议族。

    stun 可以处理大部分nat问题,turn是stun协议的一个增强版,专用于处理对称形nat问题,而ice则是综合stun及turn的产物,是一个框架,综合运用STUN和TURN的结构,它提供可靠的VoIP或视频通话配置以及媒体传输,通过一个SIP供给/应答模型供端点交换多个候选IP地址和端口(比如私有地址和TURN服务器地址)。

    采用此框架可以完美解决voip 中 媒体传输中遇到的 nat及防火墙问题,而信令穿越则需要另一套机制,过去人们提出了多种处理nat问题的方案,但都有局限性,采用ice则完全解决了这些问题,ice的另一个特点时能够通过一定机制检测nat类型,从而决定采用何种方案处理,比如对于大多数呼叫,媒体可能直接用p2p方式即可,而有些方案可能不论什么nat类型都用media-relay方式,这种方式增加了端到端延时及丢包概率。

    stun和turn都是client/server协议,说白了就是客户端向服务器要自己的公网地址及端口,然后放在自己invite请求的sdp消息体及对invite的 200 ok  sdp 消息体中。

大多数sip客户端和服务器支持stun协议,所以都有一定缺陷。


http://blog.csdn.net/perfectpdl/article/details/7636067


TURN 协议 深入剖析

概括一下:

若一个主机位于NAT后面,那么在特定的环境下,它不可能跟其他主机通信。这种情况下,这台主机有必要通过一个转发的主机来实现通信。有种协议叫TURN,允许主机通过转发来和其他主机通信。TURN协议与其他转发协议不同的地方在于它允许客户端用一个转发地址同多个主机交流。


 1 简介

一个位于NAT后面的主机可能相同其他位于NAT后面的主机交流。为了达到目的,可以用打洞的方法来找到一条路径,但是不通过转发。

当两台主机都位于对称NAT之后时,打洞技术可能会失败。

TURN协议允许一个位于NAT之后的主机请求另一台主机转发。客户端可以通过服务端转发包到另一端。并且可以控制转发如何结束。这个客户端通过在服务端获取一个IP端口对,也被称作转发端口地址来进行上述操作。


当对方发送一个包到转发端口地址时,服务器就将这个包转发到客户端。当一个客户端发送一个数据包到服务器时,服务器转发这个包到转发端口地址所对应的客户端。


一个采用TURN协议的客户端一定有一些方法把自己的转发地址告诉对方,并且知道每个通信伙伴的IP端口地址对。


若TURN协议被用作ICE协议中,那么它的转发IP端口对和其他伙伴的IP端口对都包含在ICE候选者信息中。例如,如果TURN和ICE被SIP用于媒体传输时,SIP以会话协议的方式,将ICE候选者的信息放进SIP消息体中。若TURN和ICE协议被用在其他会话协议中,那么【MUSIC-ICE-NONSIP】将提供一些会话协议必须实现的功能。


虽然TURN服务器的应用能使两个位于NAT之后的主机交流成为可能,但是这对TURN服务器来说开销太大。因而,最后是在直接交流没法执行的时候,才用TURN服务器。当客户端与伙伴通过ICE协议来确定通信路径的时候,ICE协议将首先通过打洞的方法来寻找一条直接的路径来让两方通信,仅仅当这条路径找不到的时候才会用TURN服务器。


TURN原来被设计用来支持基于SIP的多媒体会话信号传输。

TURN被设计成ICE中的用于NAT穿越的一部分。

TURN是一个STUN的扩展版本。大多数情况下,TURN消息是STUN格式的消息。该文档的读者应该熟悉STUN协议。

2 大体看一下操作

这一节给出了TURN操作的一个预览。

在一个传统的配置中,TURN客户端被连接到私有网络中,并且通过这个一个或多个NATS连到共有网络中。在这个没有共有网络中,是TURN服务器。其他的就是这个TURN客户端想连接的同伴客户端。这些同伴可能处在NAT的后面也可能没有处在NAT的后面。客户端用这个服务器作为一个转发来发送数据包到其他的伙伴,并且通过转发接收来自同伴机的数据包。

图1显示了一个经典的过程。这个图中,TURN客户端和TURN服务端被NAT分割。客户端在私有网络中,服务端在公网中。NAT是地址端口对称。

客户端通过一个叫做客户端主机传输地址得到IP地址端口对同server通话。

客户端从它的主机传输地址中传输TURN消息到一个TURNServer的一个端口地址中。

由于这个客户端位于NAT的后面,这个服务器根据客户端在NAT的传输地址看到了从客户端中传回的包。这个NAT的传输地址叫做SERVER-REFLEXIVEtransport address。

这个客户端用TURN命令在服务端进行了一个ALLOCATION操作。allocation是一个位于server的数据结构体。这个数据结构体包含了分配的RELAYED TRANSPORT ADDRESS。伙伴们可以通过这个RELAYED TRANSPORTADDRESS让服务器转发消息到客户端。

只要这个allocation被创建,客户端就能发送应用程序数据到服务器,并且指明这个数据将送给那个伙伴。这样,服务器将转发数据岛相关的伙伴。客户端发送的应用程序数据包含在TURN消息中。

在服务端,应用程序将数据从TURN消息中取出。并将数据发送以UDP的形式发给伙伴。相反的,伙伴同样可以以UDP的方式发送应用程序数据到服务端分配的转发传输地址。服务端将从TURN消息解析出数据,并且将这个数据发送到伙伴指定的客户端。由于TURN消息总是包含着客户端将发给的同伴的地址。客户端可以用唯一的一个allocation和多个peer通信。

当peer位于NAT之后,客户端必须通过peer的server-reflexive transport address辨别peer而不是host transportaddress。例如上图,发送数据到PeerA,客户端必须辨别192.0.2.150:32102而不是192.168.100.2:49582。

每一个allocation属于单一的一个客户端。并且有确切的一个relayed transport address。这样当一个包到达relayed transport address时,服务端知道数据将到哪个客户端。

每个allocation属于唯一的一个客户端。但是一个客户端可以有多个allocation。

2.1 Transport

TURN,就如在这个说明书中定义的那样,总是通过UDP在服务端和peer中通信。然而TCP也允许。

2.2 Allocation

为了创建一个Allocation在服务端。客户端发送一个Allocate请求道服务端,服务端将回复一个Allocate Sucessresponse,这个response包含着一个allocated relayed transportaddress。客户端可以包含属性到这个Allocate request中,这个属性可以描述allocation的类型(例如allocation的寿命)。

一旦relayed transport address被分配。客户端必须保证allocation处于活跃状态。为了达到目的,客户端必须周期性的发送更新请求到server。更新的频率跟allocation的寿命相关。默认的allocation的寿命是10分钟。这个值已经足够的常,以至于更新及时。


http://my.oschina.net/u/220943/blog/38158




  • 0
    点赞
  • 7
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值