穿越net 打洞原理（转）

转自：http://www.blogjava.net/duanzhimin528/archive/2010/07/12/325882.html

 

UDP"打洞"原理

1.       NAT分类

根据Stun协议(RFC3489),NAT大致分为下面四类

1)      Full Cone

这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口.然后外网的任何发到这个打开的端口的UDP数据报都可以到达A.不管是不是C发过来的.

例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88

A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)

任何发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)

2)      Restricted Cone

这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用任何端口和A通信.其他的外网机器不行.

例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88

A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)

任何从C发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)

 

3)      Port Restricted Cone

这种NAT内部的机器A连接过外网的机器C后,NAT打开一个端口.然后C可以用原来的端口和A通信.其他的外网机器不行.

例如 A:192.168.8.100 NAT:202.100.100.100 C:292.88.88.88

A(192.168.8.100:5000) -> NAT(202.100.100.100 : 8000) -> C(292.88.88.88:2000)

C(202.88.88.88:2000)发送到 NAT(202.100.100.100:8000)的数据都可以到达A(192.168.8.100:5000)

 

以上三种NAT通称Cone NAT.我们只能用这种NAT进行UDP打洞.

4)      Symmetic

对于这种NAT.连接不同的外部目标.原来NAT打开的端口会变化.而Cone NAT不会.虽然可以用端口猜测.但是成功的概率很小.因此放弃这种NAT的UDP打洞.

2.       UDP hole punching

对于Cone NAT.要采用UDP打洞.需要一个公网机器C来充当”介绍人”.内网的A,B先分别和C通信.打开各自的NAT端口.C这个时候知道A,B的公网 IP:Port. 现在A和B想直接连接.比如A给B发.除非B是Full Cone.否则不能通信.反之亦然.但是我们可以这样.

A要连接B.A给B发一个UDP包.同时.A让那个介绍人给B发一个命令,让B同时给A发一个UDP包.这样双方的NAT都会记录对方的IP,然后就会允许互相通信.

3.       同一个NAT后面的情况

如果A,B在同一个NAT后面.如果用上面的技术来进行互连.那么如果NAT支持loopback(就是本地到本地的转换),A,B可以连接,但是比较浪费带宽和NAT.有一种办法是,A,B和介绍人通信的时候,同时把自己的local IP也告诉服务器.A,B通信的时候,同时发local ip和公网IP.谁先到就用哪个IP.但是local ip就有可能不知道发到什么地方去了.比如A,B在不同的NAT后面但是他们各自的local ip段一样.A给B的local IP发的UDP就可能发给自己内部网里面的某某某了.

还有一个办法是服务器来判断A,B是否在一个NAT后面.(网络拓朴不同会不会有问题?)

--------------------------------------------------------------------------------------------------------------------------

From: http://hi.baidu.com/ligh0721/blog/item/0cbbc9384106252b96ddd872.html

前天编程做了一下UDP打洞的实验，今天特写了一篇文章总结一下。

我们知道网络上两个主机进行通信，如果其中一台主机拥有公网IP那么，那么进行会话是比较简单的，但是如果两台主机是位于不同内网之中的，那么应该如何进行通信呢。一种想法是再找一台公网的服务器，用来转发信息，但是这有一个问题，就是会给服务器带来压力，因此我们就来谈谈一种用于不同内网中的主机互相通信的一个解决方案——NAT打洞。

原理还是比较简单的，我们先了解一下什么是“NAT的洞”。当处于内网中的一台主机(ClientA/192.168.1.128)向一个公网的服务器 (Server)发送数据时，这时NAT(NAT1)将会打开一个临时性的端口用于与公网的服务器进行通信，并且会把那个内网主机发送出的IP数据报的头部中源IP地址改为NAT的公网IP(218.7.32.28)，将TCP或UDP数据报中源端口(2347)改为那个临时端口(26756)这样就实现了由 “192.168.1.128:2347”到“218.7.32.28:26756”的源地址源端口的转换。这个数据包到达公网服务器后，服务器就可以根据这个包的头部信息进行回复。当服务器的数据包到达NAT后，NAT在将这个数据发送到内网主机192.168.1.128的2347端口。那么这个 NAT上的26756端口我们就称作“洞”。如果这个NAT不是Full Cone NAT的话(其实大多数的NAT确实不是这种类型的)，那么我们说这个“洞”是有方向性的。一个洞应该会指向一个(也可以是多个)公网主机的IP地址。比如上面说的例子，在NAT1上打的洞是指向Server的IP地址。来自其他公网主机发向这个洞(也就是218.7.32.28:26756)的数据包会被非Full Cone类型的NAT所丢弃。所以如果有另一台处于另一内网的主机(ClientB/192.168.0.5)向218.7.32.28:26756直接发送数据的话，同样也会被NAT1丢弃。

那么如何建立ClientA和ClientB的直接会话呢？
网络环境描述:
内网1NAT:NAT1/218.7.32.28
内网1中一台主机:ClientA/192.168.1.128
内网2NAT:NAT2/218.7.31.221
内网2中一台主机:ClientB/192.168.0.5
公网服务器:Server

首先让ClientA和ClientB登录到服务器Server(假如两台主机都采用2347端口)，此时NAT1和NAT2会分别为ClientA和 ClientB打开一个指向Server的洞(NAT1上218.7.32.28:26756和NAT2上218.7.31.221:27550)。服务器应改记录这两个客户端的信息(关键是那两个洞的信息)。当ClientA与ClientB要建立会话时，ClientA首先用2347端口向NAT2的洞发送一个数据包，当然这个数据包会被NAT2所丢弃，但是由于这是从NAT1内部向外部发送数据，所以NAT1为ClientA打开了一个指向NAT2 的洞。而且这个新洞与原来NAT1上指向Server的旧洞的是同一个洞(因为是同一个端口26756)，所以这里可以说这个洞具有了两个方向，同时指向 Server和NAT2。这时ClientA应该通知Server，告诉ClientB，现在可以向NAT1的那个洞 (218.7.32.28:26756)发送数据包了。当ClientB向NAT1的那个洞发送数据以后，NAT2也为ClientB打了一个指向 NAT1的洞，这是可以说ClientA与ClientB的会话就建立完成了，他们可以不依赖Server进行通信了。如果以后ClientA和 ClientB还需要建立其他会话 ，那么这个牵线的“媒人”可以不是Server，而可以是ClientA或ClientB了。

UDP打洞可以实现不同内网内的主机进行通信，而且实施性比较高，一般用于P2P通信。这也就是为什么常会看见腾讯QQ在开始传输文件时会显示“UDP连接已经建立”了

 

但是不知道用java怎么实现