目前几种常见穿NAT的方法分析

NAT的出现在一定程度上解决了发展中国家网络地址资源不足的情况,然而,这种解决方法也带来了一些问题,尤其是对网络要求十分苛刻的流媒体传输方面,这些问题变得尤为突出(什么是NAT请参考BOLG的另外一篇文章),在一个带有NAT结构的网络环境中，不能实现P2P(peer to peer也就是点对点)的数据传输是VOIP的一个硬伤,而如何穿过这些NAT,实现数据的点对点传输也成了VOIP开发人员不得不面对的一个头疼问题.

       目前，解决NAT问题的方法大体有四种(按照我的个人观点，不同意的请拍砖)：修改设备、辅助探测、设备支持和流中转。下面我来分别说明。

       （1）修改设备。这种方法也就是通过修改防火墙、router等方法，对在有NAT情况下，实现P2P的数据传输方式。优点很明显，不用对UA做任何修改，缺点也同样突出：不可能指望所有的防火墙或者router都支持。这种方法不牵扯到技术方面的东西，更多的工作交了防火墙或者router开发人员，我不想多说。

       （2）辅助探测。和第一种方法相比较，这种方法不需要对防火墙或者router做任何修改，但UAC需要做一些配合，才能完成NAT的穿越。STUN是这种穿越方式的典型代表。STUN是RFC为了解决NAT而做出的一个标准（你可以在RFC下载到相关文挡，在我的开发资源里面有连接），符合这个标准的UAC和服务器，依靠他们之间的一些信息交换，可以确定出UAC在公网的IP地址和端口，从而达到穿越NAT实现P2P的目的。STUN不需要修改网络的任何部分，也可以在多层NAT下，实现P2P（注：并不是真正意义上的P2P），是一种很可靠的NAT解决方法，因此，STUN在NAT的初期得到了迅速的发展，你可以找到很多支持STUN的UAC和server资源。STUN的缺点也是显而易见的：首先，他需要UAC支持。其次用这种方法必须要得到服务器的支持并且要求UAC不停的向一个公网IP发送数据包以维持端口（keep alive）。而这几个都不是STUN的硬伤，真正置STUN于死地的是一种叫对称NAT的NAT类型，对于这种NAT类型，STUN 无能为力。在NAT的早期，这种对称NAT是很少的，然而，随着对网络安全要求的提高，目前生产的NAT几乎全是对称NAT，这也就等同于宣布STUN的死亡。

      （3）设备支持。这种方法和第一种有些类似，但是区别也是很大的，我用这种方法的典型实例：UPNP来说明。UPNP是微软和Intel力推的一种标准（显然这两个家伙大家都不喜欢，但这并不意味着它们的东西不好），你可以认为这种标准是另一种USB标准，只要你符合这种标准，你生产的USB设备可以被世界上任何一天USB设备使用（我不想讨论主从的问题）。而UPNP是网络设备的USB标准，只要你生产的设备符合UPNP标准，那么它就变成了可以连接到网络上的，通过网络控制的USB设备，你用就可以，而不需要关心如何用，怎么用。

      第一次看到UPNP的协议文挡的时候，我就对自己说：这是个好东西。尤其是当我看到，目前绝大部分（近期生产）网络设备都支持UPNP的时候，我就更加坚信了我的观点。

     事实上，我们穿越NAT所需要用的只是UPNP协议族中的一个：WANIPCONNECT SERVICE，也就是互连网接入服务（请允许我这么翻译，虽然这么有点不恰当，但是更加通俗）。你可以理解为USB设备有N多，而我们用的是U盘一样。通过这个协议，你可以控制互连网接入设备（通常是router），来做一些特殊操作，打开一个IP地址影射来实现P2P。这个过程很简单，只是发几个符合要求的数据包给UPNP服务设备，但功能却很强大，的确很迷人。（你可以在开发资源里面找到UPNP的相关连接）

     UPNP的优点如上所说，不需要在累述，但缺点也是有的：1、他需要UAC支持，完成对UPNP设备的控制，令人高兴的是，这不是很难。2、这种方法不支持多层NAT嵌套。3、总会碰到不支持UPNP或者号称支持，实际上却不支持的UPNP设备。

     （4）流中转。流中转是依靠一个公网服务器对两个UAC的RTP流进行中转的方式解决NAT问题（注意：只是解决，而不是实现P2P），在这种方式下，UAC不需要做任何修改（或者很少修改），并且可以穿越所有的NAT。典型的是outbound。也就是具有公网IP的一台RTP流转发服务器。如果outbound server和sip server 没有合成到一个程序中，那么你必须首先把信令发送给outbound server，其它的你不需要再关心。如果是已经合成了一个，那你可以象在公网中一样使用你的UAC，不必再考虑NAT的问题（舒服吧）。

      流转发（outbound）方式简单，可靠。它使你不再需要考虑NAT的任何东西，可以穿越所有NAT，并且UAC不需要做任何修改，目前网络上有很多SERVER都是工作在这种方式下。但是它的代价也是昂贵的：它不能实现P2P。这在两个UAC距离服务器很远的情况下，会有高的网络延时和高的丢包率，而这种环境下的语音或者视频效果，可能是你不能忍受的。

      由于我水平有限，我所知道的NAT解决方案就这四种。如果你问我：xxx方式（比如ICE）怎么没有的时候，请您先考虑下这种方法是不是上面方法中的一种或几种的组合（比如汽车是一种交通工具，船也是一种，而我并不认为你把汽车和船弄到了一起就是种新的交通工具），当您知道有别的好的NAT解决方案的时候，麻烦您通知我下，在此谢过。

 

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/wcl0715/archive/2006/04/25/676078.aspx