首先先介绍一些基本概念:
NAT(Network Address Translators)
,网络地址转换:网络地址转换是在IP
地址日益缺乏的情况下产生的,它的主要目的就是为了能够地址重用。NAT
分为两大类,基本的NAT
和NAPT(Network Address/Port Translator)
。
最开始NAT
是运行在路由器上的一个功能模块。
最先提出的是基本的NAT
,它的产生基于如下事实:一个私有网络(域)中的节点中只有很少的节点需要与外网连接(呵呵,这是在上世纪90
年代中期提出的)。那么这个子网中其实只有少数的节点需要全球唯一的IP
地址,其他的节点的IP
地址应该是可以重用的。
因此,基本的NAT
实现的功能很简单,在子网内使用一个保留的IP
子网段,这些IP
对外是不可见的。子网内只有少数一些IP
地址可以对应到真正全球唯一的IP
地址。如果这些节点需要访问外部网络,那么基本NAT
就负责将这个节点的子网内IP
转化为一个全球唯一的IP
然后发送出去。(
基本的NAT
会改变IP
包中的原IP
地址,但是不会改变IP
包中的端口
)
关于基本的NAT
可以参看
RFC 1631
另外一种NAT
叫做NAPT
,从名称上我们也可以看得出,NAPT
不但会改变经过这个NAT
设备的IP
数据报的IP
地址,还会改变IP
数据报的TCP/UDP
端口。基本NAT
的设备可能我们见的不多(呵呵,我没有见到过),NAPT
才是我们真正讨论的主角。看下图:
Server S1
18.181.0.31:1235
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 155.99.25.11:62000 v |
|
NAT
155.99.25.11
|
^ Session 1 (A-S1) ^ |
| 18.181.0.31:1235 | |
v 10.0.0.1:1234 v |
|
Client A
10.0.0.1:1234
有一个私有网络10.*.*.*
,Client A
是其中的一台计算机,这个网络的网关(一个NAT
设备)的外网IP
是155.99.25.11(
应该还有一个内网的IP
地址,比如10.0.0.10)
。如果Client A
中的某个进程(这个进程创建了一个UDP Socket,
这个Socket
绑定1234
端口)想访问外网主机18.181.0.31
的1235
端口,那么当数据包通过NAT
时会发生什么事情呢?
首先NAT
会改变这个数据包的原IP
地址,改为155.99.25.11
。接着NAT
会为这个传输创建一个Session
(Session
是一个抽象的概念,如果是TCP
,也许Session
是由一个SYN
包开始,以一个FIN
包结束。而UDP
呢,以这个IP
的这个端口的第一个UDP
开始,结束呢,呵呵,也许是几分钟,也许是几小时,这要看具体的实现了)并且给这个Session
分配一个端口,比如62000
,然后改变这个数据包的源端口为62000
。所以本来是(10.0.0.1:1234->18.181.0.31:1235
)的数据包到了互联网上变为了(155.99.25.11:62000->18.181.0.31:1235
)。
一旦NAT
创建了一个Session
后,NAT
会记住62000
端口对应的是10.0.0.1
的1234
端口,以后从18.181.0.31
发送到62000
端口的数据会被NAT
自动的转发到10.0.0.1
上。(注意:这里是说18.181.0.31
发送到62000
端口的数据会被转发,其他的IP
发送到这个端口的数据将被NAT
抛弃)这样Client A
就与Server S1
建立以了一个连接。
呵呵,上面的基础知识可能很多人都知道了,那么下面是关键的部分了。
看看下面的情况:
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
的端口是顺序分配的,那么我们或许可以猜测这个端口号,可是由于可能导致失败的因素太多,我们不推荐这种猜测端口的方法)。
看更多:http://www.cppblog.com/shootingstars/archive/2007/06/12/26140.html
分享到:
相关推荐
UDP打洞(P2P)C++实例,配有详细的注释,可以在此基础上继续进行二次开发。
就是非常有名的“UDP打洞技术”,UDP打洞技术依赖于由公共防火墙和cone NAT,允许适当的有计划的端对端应用程序通过NAT“打洞”,即使当双方的主机都处于NAT之后。这种技术在 RFC3027的5.1节[NAT PROT] 中进行了重点...
一个模拟p2p聊天的过程的源代码,过程很简单,p2pserver运行在一个拥有公网ip的计算机上,p2pclient运行在两个不同的nat后(注意,如果两个客户端运行在一个nat后,本程序很可能不能运行正常,这取决于你的nat是否...
TCP UDP 打洞技术,作为基础了解,值得一看。
这是关于UDP打洞技术的资料,通过UDP打洞技术,可以更快更好的通信,对程序员帮助很大
演示了vb中如何使用UDP协议进行UDP“打洞”,其中还含有代理服务器的演示代码
NAT可以分为很多种,但是最为普遍的是传统NAT,或者称为向外NAT。向外NAT在默认情况下只允许向外的Session穿越NAT,这就是我们最为常见的情况。
P2P技术,UDP打洞,穿越NAT,服务器与客户端程序源码。学习P2P技术,UDP打洞的非常好的资料。 《[WINDOWS网络与通信程序设计].王艳平》第十章源码
UDP打洞程序包的c#源码.虽然打洞技术的实现源码在网上也可以找到,但用C#实现的源码并不多见。另外下面的代码为了达到功能与界面的分离,采用了事件进行消息通信,程序具有一定的可移植性和可扩展性.
想通过UDP套接字,实现互联网的通讯,不可避免的要实现打洞技术.这是UDP打洞技术的原理及实现.
UDP打洞实现了子网间的穿透功能,首先在一台拥有公网IP服务器上运行server,在不同的两个子网PC上运行client,输入服务器IP,即可进行打洞,实现不同子网的通信。
UDP实现P2P技术打洞实例源码,测试过的,百分百有效
可以用eclipse运行,有服务器端和客户端,可实现即时对话。
UDP打洞代码.pdf
最近正在做穿墙技术,集各种资料,这篇算是介绍得最全面最清楚的,分享给各位朋友。
C# UPD打洞技术 P2P通信 P2P聊天
C# udp NAT打洞客户端,可以实现不能局域网的通信,亲测,测试请需要设置一个IP地址,这个IP地址为外网的IP地址,如果没有外网的IP地址,请通过路由器设置DMZ主机地址,也可以实现外网的功能,UDP NAT的原理可以在我...
P2PChat(使用UDP打洞技术实现P2P聊天) ======本机调试方法1.启动P2pUdpServer服务端[main] INFO io.itit.p2p.P2pUdpServer - Server Start port:99992.启动P2pUdpClient客户端1 [main] INFO io.itit.p2p.P2...
P2P-NAT 是一个 P2P代理,提供了NAT的功能,也提供了防火墙的功能,一个最简的P2P代理必须具有锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。 回环转换 当NAT的私网内部机器想通过公共...
基于UDP,P2P的通信示例,通过UDP打洞技术实现,可获取到局域网内机器的对外IP和路由映射IP和端口号,实现类似QQ的两个局域网内机器的通信