这里我们主要是是简单讲解一下UDP实现NAT的穿透(俗称打洞)
当然TCP与之相似,可以以此类推。

NAT最开始出现在路由器上。详细的大家可以在网上查下资料
NAT的全称是Network Address Translator中文称之为网络地址转换
NAT分为两大类,NAT和NAPT(Network Address Port Translator)这个不用说了,端口地址转换。

用于实例,简单的说,实现P2P需要一个中转服务器。也就是需要一个第三方。(一会儿我们来说为什么需要一个第三方)

以简单的通迅来讲,首先我们来看一个示例图。

A<——————>B  A与B之间进行的通迅
A的IP地址为222.182.100.1
B的IP地址为222.182.100.2
如果这两个用户都是采用的全球唯一的IP地址,那么他们通迅很简单,也不需要实现P2P。
A<------------------>Nat<-------------------->B
如果其中一方为内网用户,及IP地址不为全球唯一IP
就会出现通过路由器进行通迅。
那么在经过路由器的时候,路由器会出现映射IP地址与端口的情况。
如:A为内网用户。B为外网用户。则B的IP地图为全球唯一IP地址。可以直接通迅。
A的IP地址为:192.168.1.100 端口为1025
经过路由器向B进行通迅,路由器将会产生一个一分钟到几小时不定的一个Session,这个Session映射了内网A的IP地址及其接收信息的端口。
那么路由向B发送信息的时候,IP地址及端口就变成了222.182.100.1:3645(假设)
这个时候实际上A就是在进行路由NAT的穿透,
如果我们在B向A发送信息的时候采用192.168.1.100:1025这样的IP和端口,是找不到A的,因为这个IP不是全球唯一IP。
那么B需要的是在收到A的信息的时候,获取其IP地址和端口,那么获取到的就是222.182.100.1:3645这个路由器的映射Session地址。
B现在只需要向这个映射地址发送消息,路由器就会自动将消息发送到对应的A方去。否则路由器将当作无用包,将这个消息丢弃。
那如,我们现在就实现了局域网向某单个固定外网机器发送消息。
如 果再来一台C端,也是外网的IP。C通过222.182.100.1:3645向A发送消息,A是否能收到呢?答案是否定的,A不能收到。为什么?因为路 由在映射A的穿透时就记录了B的地址,也就是除了B向这个映射点发送消息可以通向A,其它的地址是不行的。路由器此时会将其当作无用包消息给丢弃掉。
那怎么办呢?只有A再向C发送一个穿透,C才可以向A发送消息。

以上我们只是说了一点基本的理论。接下来我们要实现什么?不同内网通过internet网进行通迅。
再来,我们举个图例

A<----------->NatA<---------->NatB<---------->B
A的地址是:192.168.1.100端口4000
B的地址是:192.168.1.100端口4000
它们两个都是内网的地址。及局域网内部地址。并不是全球唯一地址。
两个路由:
NatA的地址是:222.182.100.1
NatB的地址是:222.182.100.2
这两个路由是外网的地址,及全球唯一地址。

现在我们要实现A与B的通迅。
因为A与B都不是外网地址。所以A不可能向192.168.1.100发送消息。这消息只会它自己收到,因为这个IP是它自己的。同样B也不可以。
那么A向NatB发送消息,B能收到吗?答案是否定的,不能收到。刚才我们提到过。因为路由没有映射B的地址。A并不知道这个Session就连NatB也不知道这个Session因为B没有向A发送消息,并不产生这个Session。
就算B和A同时向双方的路由发送消息,产生的Session,A和B也得不到。因为在路由上就把这个消息当做为无用包给丢弃掉了。

那么这样的情况我们要进行通迅怎么办呢?
对,就是刚才我们提到的第三方。第三方是个什么方呢?
第三方必须是一个拥有固定外网IP的服务方。及一个外网服务器。全唯一IP地址。

图例:
假定我们这个第三方为C
C  IP:222.182.100.3端口4001
A<----------->NatA<--------------->C<-------------------->NatB<------------->B
                    ↑______________________________↑                                                          

原理如下
A通过路由向C发送消息,C获取A的在路由上的Session地址,映射的IP和端口
B同样。
这时候C就有了A和B的地址。
C可以和A、B进行通迅,但是A和B还不行。
现在C需要通知A方B的映射IP和端口。也要通知B方A的映射IP和端口。
这样A就有了B的映射地址,B也有了A的。但是现在还不能进行通迅。
因为在路由上A和B都只有对C的穿透。并没有相互之前的穿透。
那么A要向B发送消息怎么办呢?需要C向B发送一个消息告诉B方A的地址让B向这个地址发送一个消息,对A进行一个穿透。
这样A就可以向B发送消息了。在A向B发送消息的同时,A也在向B进行穿透。
这样就可以实现相互的通迅了。如果有多个端点,也就以此类推了。
宗上所述就是P2P的UDP实现原理了。TCP也是一样的。提示一点。Session在路由上是有时限的,一分钟到几小时不定。不同的路由不同的时间,为了保持这个Session的存在,你需要在固定时间点进行通迅,保持这个穿透,否则就得重新穿透。

值得注意的一点。
路由上的映射有两种情况
第一种情况是:Cone NAT
第二种情况是:Symmetric NAT
我们以上的实现是以Cone Nat为基础的。为什么呢?因为Cone Nat在映射的时候端口是不变的。无论你内网有多少台机器,向外网发送消息在路由上映射的端口都是不变的。

而Symmetric Nat则相反,一个映射一个端口。如果碰到这种情况只有祝你好运了,最好不要猜。(十有八九猜不到。所以不推荐猜)




看看下面的情况:

    Server S1                                     Server S2
 18.181.0.31:1235                              138.76.29.7:1235
        |                                             |
        |                                             |
        +----------------------+----------------------+
                               |
   ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
   |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
   v 155.99.25.11:62000 v      |      v 155.99.25.11:62000 v
                               |
                            Cone NAT
                          155.99.25.11
                               |
   ^  Session 1 (A-S1)  ^      |      ^  Session 2 (A-S2)  ^
   |  18.181.0.31:1235  |      |      |  138.76.29.7:1235  |
   v   10.0.0.1:1234    v      |      v   10.0.0.1:1234    v
                               |
                            Client A
                         10.0.0.1:1234

 

    接上面的例子,如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包,那么这个UDP包在通过NAT时会怎么样呢?

    这时可能会有两种情况发生,一种是NAT再次创建一个Session,并且再次为这个Session分配一个端口号(比如:62001)。另外一种是NAT再次创建一个Session,但是不会新分配一个端口号,而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT,后一种叫做Cone NAT。我们期望我们的NAT是第二种,呵呵,如果你的NAT刚好是第一种,那么很可能会有很多P2P软件失灵。(可以庆幸的是,现在绝大多数的NAT属于后者,即Cone NAT)

   

    好了,我们看到,通过NAT,子网内的计算机向外连结是很容易的(NAT相当于透明的,子网内的和外网的计算机不用知道NAT的情况)。

    但是如果外部的计算机想访问子网内的计算机就比较困难了(而这正是P2P所需要的)。

    那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢?首先,我们必须在内网的NAT上打上一个“洞”(也就是前面我们说的在NAT上建立一个Session),这个洞不能由外部来打,只能由内网内的主机来打。而且这个洞是有方向的,比如从内部某台主机(比如:192.168.0.10)向外部的某个IP(比如:219.237.60.1)发送一个UDP包,那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”,(这就是称为UDP Hole Punching的技术)以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。(但是其他的IP不能利用这个洞)。

    

    呵呵,现在该轮到我们的正题P2P了。有了上面的理论,实现两个内网的主机通讯就差最后一步了:那就是鸡生蛋还是蛋生鸡的问题了,两边都无法主动发出连接请求,谁也不知道谁的公网地址,那我们如何来打这个洞呢?我们需要一个中间人来联系这两个内网主机。

    现在我们来看看一个P2P软件的流程,以下图为例:

                       Server S (219.237.60.1)
                          |
                          |
   +----------------------+----------------------+
   |                                             |
 NAT A (外网IP:202.187.45.3)                 NAT B (外网IP:187.34.1.56)
   |   (内网IP:192.168.0.1)                      | (内网IP:192.168.0.1)
   |                                             |
Client A  (192.168.0.20:4000)             Client B (192.168.0.10:40000)

 


    首先,Client A登录服务器,NAT A为这次的Session分配了一个端口60000,那么Server S收到的Client A的地址是202.187.45.3:60000,这就是Client A的外网地址了。同样,Client B登录Server S,NAT B给此次Session分配的端口是40000,那么Server S收到的B的地址是187.34.1.56:40000。

    此时,Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B,那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000,是不是Client A向这个地址发送信息Client B就能收到了呢?答案是不行,因为如果这样发送信息,NAT B会将这个信息丢弃(因为这样的信息是不请自来的,为了安全,大多数NAT都会执行丢弃动作)。现在我们需要的是在NAT B上打一个方向为202.187.45.3(即Client A的外网地址)的洞,那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢,呵呵,当然是Server S。

    总结一下这个过程:如果Client A想向Client B发送信息,那么Client A发送命令给Server S,请求Server S命令Client B向Client A方向打洞。呵呵,是不是很绕口,不过没关系,想一想就很清楚了,何况还有源代码呢(侯老师说过:在源代码面前没有秘密 8)),然后Client A就可以通过Client B的外网地址与Client B通信了。

    

    注意:以上过程只适合于Cone NAT的情况,如果是Symmetric NAT,那么当Client B向Client A打洞的端口已经重新分配了,Client B将无法知道这个端口(如果Symmetric NAT的端口是顺序分配的,那么我们或许可以猜测这个端口号,可是由于可能导致失败的因素太多,我们不推荐这种猜测端口的方法)。


NAT的完全分析及其UDP穿透的完全解决方案
 
一:基本术语
防火墙
防火墙限制了私网与公网的通信,它主要是将(防火墙)认为未经授权的的包丢弃,防火墙只是检验包的数据,并不修改数据包中的IP地址和TCP/UDP端口信息。
网络地址转换(NAT)
当有数据包通过时,网络地址转换器不仅检查包的信息,还要将包头中的IP地址和端口信息进行修改。以使得处于NAT之后的机器共享几个仅有的公网IP地址(通常是一个)。网络地址转换器主要有两种类型.
P2P应用程序
P2P应用程序是指,在已有的一个公共服务器的基础上,并分别利用自己的私有地址或者公有地址(或者两者兼备)来建立一个端到端的会话通信。
P2P防火墙
P2P防火墙是一个提供了防火墙的功能的P2P代理,但是不进行地址转换.
P2P-NAT
P2P-NAT 是一个 P2P代理,提供了NAT的功能,也提供了防火墙的功能,一个最简的P2P代理必须具有锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。
回环转换
当NAT的私网内部机器想通过公共地址来访问同一台局域网内的机器的时,NAT设备等价于做了两次NAT的事情,在包到达目标机器之前,先将私有地址转换为公网地址,然后再将公网地址转换回私有地址。我们把具有上叙转换功能的NAT设备叫做“回环转换”设备。
 
二:NAT分类
可以分为基础NAT与网络地址和端口转换(NAPT)两大类
(一):基础NAT
基础NAT 将私网主机的私有IP地址转换成公网IP地址,但并不将TCP/UDP端口信息进行转换。基础NAT一般用在当NAT拥有很多公网IP地址的时候,它将公网IP地址与内部主机进行绑定,使得外部可以用公网IP地址访问内部主机。(实际上是只将IP转换,192.168.0.23 <-> 210.42.106.35,这与直接设置IP地址为公网IP还是有一定区别的,特别是对于企业来说,外部的信息都要经过统一防火墙才能到达内部,但是内部主机又可以使用公网IP)
(二):网络地址和端口转换 (NAPT)
这是最普遍的情况,网络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息,这样,更多的内部主机就可以同时使用一个公网IP地址。
请参考[RFC1631]和[RFC2993]及[RFC2663]这三个文档了解更多的NAT分类和术语信息。另外,关于NAPT的分类和术语,[RFC2663]做了更多的定义。当一个内部网主机通过NAT打开一个“外出”的TCP或UDP会话时,NAPT分配给这个会话一个公网IP和端口,用来接收外网的响应的数据包,并经过转换通知内部网的主机。这样做的效果是,NAPT在 [私有IP:私有端口] 和[公网IP:公网端口]之间建立了一个端口绑定。
端口绑定指定了NAPT将在这个会话的生存期内进行地址转换任务。这中间存在一个这样的问题,如果P2P应用程序从内部网络的一个[私有IP地址:端口]对同时发出多条会话给不同的外网主机,那么NAT会怎样处理呢?这又可以分为锥形NAT (CONE NAT)与对称NAT (SYMMTRIC NAT)两大类来考虑:
A.锥形NAT
(为什么叫做锥形呢?请看以下图形,终端和外部服务器,都通过NAT分派的这个绑定地址对来传送信息,就象一个漏斗一样,筛选并传递信息)
                               
  当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后,对于来自同一个[私有IP:端口]会话,锥形NAT服务器允许发起会话的应用程序 重复使用这个端口绑定,一直到这个会话结束才解除(端口绑定)。
  例如,假设 Client A(IP地址信息如上图所示)通过一个锥形NAT 同时发起两个外出的连接,它使用同一个内部端口(10.0.0.1:1234)给公网的两台不同的服务器,S1和S2。锥形NAT 只分配一个公网IP和端口(155.99.25.11:62000)给这个两个会话,通过地址转换可以确保 Client使用端口的“同一性”(即这个Client只使用这个端口)。而基础NATs和防火墙却不能修改经过的数据包端口号,它们可以看作是锥形NAT的精简版本。
进一步分析可以将CONE NAT受限制锥形NAT (RESTRICT CONE) 与端口受限锥形NAT (PORT RESTRICT CONE) 三大类,以下是详细论述: 分为全双工锥形NAT (FULL CONE) ,
1.全双工锥形NAT
当内部主机发出一个“外出”的连接会话,就会创建了一个公网/私网 地址,一旦这个地址对被创建,全双工锥形NAT会接收随后任何外部端口传入这个公共端口地址的通信。因此,全双工锥形NAT有时候又被称为"混杂"NAT。
2.受限制锥形NAT
受限制的锥形NAT会对传入的数据包进行筛选,当内部主机发出“外出”的会话时,NAT会记录这个外部主机的IP地址信息,所以,也只有这些有记录的外部IP地址,能够将信息传入到NAT内部,受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。
3.端口受限锥形NAT
端口受限制的锥形NAT,与受限制的锥形NAT不同的是:它同时记录了外部主机的IP地址和端口信息,端口受限制的锥形NAT给内部节点提供了同一级别的保护,在维持端口“同一性”过程中,将会丢弃对称NAT传回的信息。
B.对称NAT
对称NAT,与Cone NAT是大不相同的,并不对会话进行端口绑定,而是分配一个全新的公网端口 给每一个新的会话。
还是上面那个例子:如果 Client A (10.0.0.1:1234)同时发起两个 "外出" 会话,分别发往S1和S2。对称Nat会分配公共地址155.99.25.11:62000给Session1,然后分配另一个不同的公共地址155.99.25.11:62001给Session2。对称Nat能够区别两个不同的会话并进行地址转换,因为在 Session1 和 Session2中的外部地址是不同的,正是因为这样,Client端的应用程序就迷失在这个地址转换边界线了,因为这个应用程序每发出一个会话都会使用一个新的端口,无法保障只使用同一个端口了。
在TCP和UDP通信中,(到底是使用同一个端口,还是分配不同的端口给同一个应用程序),锥形NAT和对称NAT各有各的理由。当然锥形NAT在根据如何公平地将NAT接受的连接直达一个已创建的地址对上有更多的分类。这个分类一般应用在Udp通信(而不是Tcp通信上),因为NATs和防火墙阻止了试图无条件传入的TCP连接,除非明确设置NAT不这样做。
三:NAT对session的处理
以下分析NAPT是依据什么策略来判断是否要为一个请求发出的UDP数据包建立Session的.主要有一下几个策略:
A. 源地址(内网IP地址)不同,忽略其它因素, 在NAPT上肯定对应不同的Session
B. 源地址(内网IP地址)相同,源端口不同,忽略其它的因素,则在NAPT上也肯定对应不同的Session
C. 源地址(内网IP地址)相同,源端口相同,目的地址(公网IP地址)相同,目的端口不同,则在NAPT上肯定对应同一个Session
D. 源地址(内网IP地址)相同,源端口相同,目的地址(公网IP地址)不同,忽略目的端口,则在NAPT上是如何处理Session的呢?
A,B,C三种情况的都是比较简单的,可以很容易的实现.而D的情况就比较复杂了.所以D情况才是我们要重点关心和讨论的问题。
四:完全解决方案
以下针对四种SESSION与四种NAT的完全解决方案,为了方便将使用以下缩写形式:
C代表 CONE NAT
S代表SYMMETRIC NAT,
FC代表 FULL CONE NAT,
RC代表 RESTRICT CONE NAT,
PC 代表 PORT RESTRICT CONE NAT.
首先依据CLIENT (客户)端在NAT后 的个数不同可以分为两大类:
TYPE ONE :一个在NAT后 + 一个在公网中.
这种情况下可以分为两大类:
A. S VS 公网:此种情况下,由于公网的地址在一个SESSION内是不变的,所以可以打洞是可以成功的.
B. C VS 公网: 与上面类似,这种情口下打洞是可以成功的.
TYPE TWO:两个客户都在NAT后面.
这种情况下也可以细分为两大类:
A. 其中一个NAT 是 S(SYMMETRIC NAT) 型的,既:S VS C或者是S VS S .
下面论证这种情口下按照常规打洞是行不通的,在常规打洞中,所有的客户首先登陆到一个服务器上去.服务器记录下每个客户的[公网IP:端口],然后在打洞过程中就使用这个记录的值,然而对于S型的NAT来说,它并不绑定[私网IP:端口]和[公网IP:端口]的映射.所以在不同的SESSION中,NAT将会重新分配一对[公网IP:端口].这样一来对于S型的NAT来说打洞的[公网IP:端口]与登记在服务器上的[公网IP:端口]是不同的.而且也没有办法将打洞的[公网IP:端口]通知到另一个位于NAT下的客户端, 所以打洞是不会成功的.然而如果另一个客户端是在公网时,打洞是可以的.前面已经论证了这种情况.
这种情况下的解决方案是只能通过端口预测来进行打洞,具体解决方法如下:例如(以两个都是S型的为例) NAT A 分配了它自己的UDP端口62000,用来保持 客户端A 与服务器S的通信会话, NAT B 也分配了31000端口,用来保持客户端B与服务器S 的通信会话。通过与 服务器S的对话,客户端A 和 客户端B都相互知道了对方所映射的真实IP和端口。
  客户端A发送一条UDP消息到138.76.29.7:31001(请注意到端口号的增加),同时客户端B发送一条UDP消息到155.99.25.11:62001。如果NAT A 和NAT B继续分配端口给新的会话,并且从A-S和B-S的会话时间消耗得并不多的话,那么一条处于客户端A和客户端B之间的双向会话通道就建立了。
  客户端A发出的消息送达B导致了NAT A打开了一个新的会话,并且我们希望NAT A将会指派62001端口给这个新的会话,因为62001是继62000后,NAT会自动指派给 从服务器S到客户端A之间的新会话的端口号;类似的,客户端B发出的消息送达A导致了 NAT B打开了一个新的会话,并且我们希望 NAT B将会指派31001这个端口给新的会话;如果两个客户端都正确的猜测到了对方新会话被指派的端口号,那么这个 客户端A-客户端B的双向连接就被打通了。其结果如下图所示:
明显的,有许多因素会导致这个方法失败:如果这个预言的新端口(62001和31001) 恰好已经被一个不相关的会话所使用,那么NAT就会跳过这个端口号,这个连接就会宣告失败;如果两个NAT有时或者总是不按照顺序来生成新的端口号,那么这个方法也是行不通的。
如果隐藏在NATA后的一个不同的客户端X(或者在NAT B后)打开了一个新的“外出”UDP 连接,并且无论这个连接的目的如何;只要这个动作发生在客户端A 建立了与服务器S的连接之后,客户端A 与 客户端B 建立连接之前;那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以,这个方法变得如此脆弱而且不堪一击,只要任何一个NAT方包含以上碰到的问题,这个方法都不会奏效。
在处于 cone NAT 系列的网络环境中这个方法还是实用的;如果有一方为 cone NAT 而另外一方为 symmetric NAT,那么应用程序就应该预先发现另外一方的 NAT 是什么类型,再做出正确的行为来处理通信,这样就增大了算法的复杂度,并且降低了在真实网络环境中的普适性。
    最后,如果P2P的一方处在两级或者两级以上的NAT下面,并且这些NATS 接近这个客户端是SYMMETRIC NAT的话,端口号预言是无效的!
因此,并不推荐使用这个方法来写新的P2P应用程序,这也是历史的经验和教训!
B. 两个都是CONE NAT型的.
这种情况下可以分为六大类型:
A: FC + FC
B: FC + RC
C: FC + PC
D: PC + RC
E: PC + PC
F: RC + RC
虽然有这么多种情况,但是由于CONE NAT 的特性,所以还是很好办的,因为对于CONE NAT 来说,在同一个SESSION中它会绑定一对[私网IP:端口]和[公网IP:端口]的映射,所以它们打洞用的[公网IP:端口]与登记在服务器上的[公网IP:端口]是一致的,所以打洞是可以行的通的.
综上所述,就已经完全的概括了所有类型的NAT之间的可能的通信情况了.并且都提供了可行的解决方案.
五:对前一阶段的总结
1.前一阶段使用的打洞方法是有缺陷的,它只适应于两个都是FULL CONE NAT的类型的CLIENT(客户端).以下论证它不适应于两个都是CONE NAT的类型中的
B: FC + RC
C: FC + PC
D: PC + RC
E: PC + PC
F: RC + RC
这五种情况.
因为对于受限的NAT它登记了外出包的[IP地址&端口],它仅仅接受这些已登记地址发过来的包,所以它们报告服务器的端口只能接受来自服务器的包.不能接受来自另一客户端的包.所以前一阶段的打洞方法是不可行的.
六: 存在的问题
按照理论.NAT将在一定时间后关闭UDP的一个映射,所以为了保持与服务器能够一直通信,服务器必须要发送UDP心跳包,来保持映射不被关闭.这就需要一个合适的时间值