STUN/TURN/ICE协议在P2P SIP中的应用(一)

1           说明

       本文详细描述了基于STUN系列协议实现的P2P SIP电话过程,其中涉及到了SIP信令的交互,P2P的原理,以及STUN、TURN、ICE的协议交互

       本文所提到的各个服务单元的交互均使用UDP,不涉及TCP的打洞及其他和TCP相关的操作。

       本文假设通信双方均没有防火墙对协议以及端口的限制。

       本文不涉及客户端的资源的发布与查找。

       本文适用于有一定基础的读者,比如说知道NAT设备的不同类型及其特点、知道STUN/TURN/ICE协议的基本概念、知道SIP协议的相关交互流程等。

       本文力求严谨,但难免有疏漏之处,敬请谅解,欢迎批评指正。

       本文大致可分为4个部分:

       第一部分,解释了穿越和打洞的概念以及STUN系列协议穿越的特点

       第二部分,STUN、TURN协议的工作原理及其作用,详细介绍了relay端口的分配、消息的接受与发送、STUN头的添加与去除

       第三部分,ICE协议的工作原理及其作用,详细介绍了ICE的打洞原理、两种打洞方式(regular nomination和aggressive nomination)、Peer Reflexive Candidates 的概念与发现过程

       第四部分,ICE在P2P SIP中的应用,详细讲解了SIP的信令交互流程与媒体建立流程。

2           打洞和穿越的概念

       有人将穿越打洞认为是一个概念,其实这也无伤大雅,在与其他人交流讨论的时候不产生歧义就好。严格来说,是先打洞,后穿越。

       由于NAT的特性(请查阅NAT的几种不同类型的各自特点),一个位于外界的主机是不可能向内网主机直接建立连接的。要想实现外界主机与内网主机的交互,那么 “我(内部主机)在我自己的NAT设备上先打一个洞,然后使得你(外界主机)的数据能经过这个洞穿越过来”。

       当我们打开电脑,连上网络,打开几个不同网站的时候,打洞和穿越时时刻刻都在发生着。你打开sina的时候,你就在自己的NAT上打了一个洞,这个洞只允许sina的80端口的数据穿越回来。如果没有你先打的洞,sina是不可能成功给你发消息的。

       时刻记住一个概念,打洞是为了能让对方的数据过来。

3           P2P中的打洞和穿越

       既然打洞和穿越实时都在发生着,那么在client/server模型的网络编程中为什么很少提及打洞和穿越的概念,却在P2P通信中反复提及呢?

       首先,在cs模型的网络编程中,服务器都架设在公网,服务器端不用打洞(服务端不用为客户端打洞,客户端的数据也能过来),客户端就能向服务器发送请求。

       其次,client向服务器发送请求时,client的打洞和服务器响应的穿越是自动实现的。

       最后,明确一点的是,cs模型中,打洞是单方向的,即只需客户端打洞。

 

       而在P2P网络编程中,通信的双方A和B既要当服务器,又要当客户端。因此打洞是双方的:A在自己的NAT上为B打一个洞,让B的数据能过来;B在自己的NAT上为A打一个洞,让A的数据能过来;

       AB双方的打洞的操作得由我们自己完成,所以不得不提及穿越打洞的概念。

       理解了“P2P通信中,打洞是双方的”这一点,也就理解了ICE的一半。

4           使用STUN系列 协议穿越的特点

       在知道NAT的几种类型和每种类型的限制后,就是针对性的解决这些问题实现NAT的穿越。

       最容易想到的就是,能不能在NAT上做一下手脚,让它能识别出我特有的协议,从而不限制我特有的协议,这就是ALG的初衷。ALG(应用层网关),有两个功能,一个是修改自己“认识的”协议中相关字段的内网地址为外网地址;另一个是,允许自己“认识的”协议直接穿透,而不需要打洞;

       可以认为ALG的能力是NAT的一个插件,插上什么协议类型的插件,NAT就能辨别什么类型的协议,继而对相应类型的协议做相关操作。常用的应用有FTP、DNS、ICMP、SIP等。在VOIP中,如果使用ALG的话,可以实现通信双方的直接媒体通信,但是不足之处就是需要NAT支持SIP,这就不适合像skype类型的应用。

       还有一种成熟的穿越技术:UPnP,它的想法跟ALG有点类似,也是在NAT上做了手脚。当内网的主机启动UPnP程序的时候,就会在NAT上产生 “映射端口”与UPnP程序的端口一一映射,而且不会被回收。从外部来的消息,只要是发送到“映射端口”的,直接就会送至内网的UPnP程序。像我们平常用到的迅雷、电骡等,这种方式也不用打洞,但缺点就是需要应用程序、操作系统以及NAT支持UPnP,同样不适用于skype类型的应用。

       使用STUN/TURN/ICE最大的好处充分利用NAT的特性,不需要操作系统支持、不需要对现有的NAT设备做改变就能实现穿越。

       最后需要说明的一点就是,没有不好的技术,只有不适合的技术。

5           STUN/ TURN/ICE协议的关系

       简单来说,STUN的目的是为了进行P2P通信,通过提供反射地址(Server Reflexive Address)这种能力来使双方可以进行P2P通信,但是依赖NAT类型的不同,这种方式是有失败的概率的:比如双方都为对称型NAT或者一方为对称型,另一方为端口限制型。

       因为有失败的可能性,所以单纯的依赖STUN协议提供的反射地址的话,需要事先探测出双方的NAT类型,假如发现是对称型的NAT,那么就不打洞了,而是直接中转。目前网络类型纷繁复杂,STUN协议在5389的时候去掉了NAT类型的判断的能力,因为越来越多的实践发现,在多层NAT下,类型的探测不总是有效的。而使用ICE的时候,不需要事先探测NAT类型。

       STUN还有一个作用是为ICE提供支持(对Binding的扩展)。

       TURN协议的目的是为了保证通信双方百分之百能进行通信,就是在只知道反射地址而打洞失败的情况下的一种补充方案-----使用中继,使用中继方式百分之百能使得双方进行通信,只不过已经不是P2P的了,而且伴随而来的是转发效率的问题。不过这不要紧,因为该协议的目的就是保证双方肯定能通信,损失效率来保证了连同性。

       ICE协议的目的就是综合以上两种方案,通过通信双方互相发探测包,找出一种最合理,最廉价的可行路径。ICE首先探测内网地址,再探测STUN提供的反射地址,最后探测TURN协议的中继地址,反正最终目的就是探出一条路,内网地址不行用反射地址,反射地址不行,最后不得已情况下那就用中继地址。

       一般来说,目前的TURN服务器通常也实现了STUN协议,所以可以称之为TURN服务器或者是STUN 服务器。

如果说一个服务器是STUN服务器,那么该服务器可能是纯的STUN(RFC 5389)服务器,也可能是一个TURN(RFC 5766)服务器,也可能是两者都实现了的服务器。本文以下图中所说的STUN服务器,均为实现了STUN和TURN的服务器。

相关文章
相关标签/搜索