P2P 之 UDP穿透NAT的原理与实现(附源代码) 论坛上经常有对P2P原理的讨论,但是讨论归讨论,很少有实质的东西产生(源代码)。呵呵,在这里我就用自己实现的一个源代码来说明UDP穿越NAT的原理。 首先先介绍一些基本概念:
有一个私有网络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时会发生什么事情呢? 呵呵,上面的基础知识可能很多人都知道了,那么下面是关键的部分了。
接上面的例子,如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包,那么这个UDP包在通过NAT时会怎么样呢? 呵呵,现在该轮到我们的正题P2P了。有了上面的理论,实现两个内网的主机通讯就差最后一步了:那就是鸡生蛋还是蛋生鸡的问题了,两边都无法主动发出连接请求,谁也不知道谁的公网地址,那我们如何来打这个洞呢?我们需要一个中间人来联系这两个内网主机。
首先,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。 工程下载地址:upload/2004_05/04052509317298.rar ----------------------------------------------------------------------------------------------------------------------- 基于UDP的P2P问题拾遗UDP协议包经NAPT透明传输的说明: NAPT为每一个Session分配一个NAPT自己的端口号,依据此端口号来判断将收到的公网IP主机返回的TCP/IP数据包转发给那台内网IP地址的计算机。在这里Session是虚拟的,UDP通讯并不需要建立连接,但是对于NAPT而言,的确要有一个Session的概念存在。NAPT对于UDP协议包的透明传输面临的一个重要的问题就是如何处理这个虚拟的Session。我们都知道TCP连接的Session以SYN包开始,以FIN包结束,NAPT可以很容易的获取到TCP Session的生命周期,并进行处理。但是对于UDP而言,就麻烦了,NAPT并不知道转发出去的UDP协议包是否到达了目的主机,也没有办法知道。而且鉴于UDP协议的特点,可靠很差,因此NAPT必须强制维持Session的存在,以便等待将外部送回来的数据并转发给曾经发起请求的内网IP地址的计算机。NAPT具体如何处理UDP Session的超时呢?不同的厂商提供的设备对于NAPT的实现不近相同,也许几分钟,也许几个小时,些NAPT的实现还会根据设备的忙碌状态进行智能计算超时时间的长短。 现在来看一下NAPT是依据什么策略来判断是否要为一个请求发出的UDP数据包建立Session的主要有一下几个策略: A. 源地址(内网IP地址)不同,忽略其它因素, 在NAPT上肯定对应不同的Session D的情况正式我们关心和要讨论的问题。依据目的地址(公网IP地址)对于Session的建立的决定方式我们将NAPT设备划分为两大类: Symmetric NAPT: Cone NAPT: 客户端都处于相同的NAT之后 我们假设,Client A 和 Client B 要使用上一节我们所描述的 “UDP打洞技术”,并通过服务器S这个“媒人”来认识,这样Client A 和Client B首先从服务端S得到了彼此的公网IP地址和端口,然后就往对方的公网IP地址和端口上发送消息。在这种情况下,如果NAT 仅仅允许在 内部网主机与其他内部网主机(处于同一个NAT之后的网络主机)之间打开UDP会话通信通道,而内部网主机与其他外部网主机就不允许的话,那么Client A 和Client B就可以通话了。我们把这种情形叫做“loopback translation”(“回环转换”),因为数据包首先从局域网的私有IP发送到NAT转换,然后“绕一圈”,再回到局域网中来,但是这样总比这些数据通过公网传送好。举例来说,当 Client A发送了一个UDP数据包到 Client B的公网IP地址,这个数据包的报头中就会有一个源地址10.0.0.1:124和一个目标地址155.99.25.11:62001。NAT接收到这个包以后,就会(进行地址转换)解析出这个包中有一个公网地址源地址155.99.25.11:62000和一个目标地址10.1.1.3:1234,然后再发送给B,虽说NAT支持“loopback translation”,我们也发现,在这种情形下,这个解析和发送的过程有些多余,并且这个Client A 和Client B 之间的对话可能潜在性地给NAT增加了负担。 UDP打洞技术有很多实用的地方: 第一,一旦这种处于NAT之后的端对端的直连建立之后,连接的双方可以轮流担任 对方的“媒人”,把对方介绍给其他的客户端,这样就极大的降低了服务器S的工作量;第二,应用程序不用关心这个NAT是属于cone还是symmetric,即便要,如果连接的双方有一方或者双方都恰好不处于NAT之后,基于上叙的步骤,他们之间还是可以建立很好的通信通道;第三,打洞技术能够自动运作在多重NAT之后,不论连接的双方经过多少层NAT才到达Internet,都可以进行通信。 UPD端口号预言 如果隐藏在NAT A后的一个不同的客户端X(或者在NAT B后)打开了一个新的“外出”UDP 连接,并且无论这个连接的目的如何;只要这个动作发生在 客户端A 建立了与服务器S 的连接之后,客户端A 与 客户端B 建立连接之前;那么这个无关的客户端X 就会趁人不备地“偷” 到这个我们渴望分配的端口。所以,这个方法变得如此脆弱而且不堪一击,只要任何一个NAT方包含以上碰到的问题,这个方法都不会奏效。 最后,如果P2P的一方处在两级或者两级以上的NAT下面,并且这些NATs 接近这个客户端是 symmetric的话,端口号预言 是无效的! 保持端口绑定 伴随着 cone NAT 的推广,“UDP打洞技术”也被越来越广泛的应用。然而,仍存在一小部分使用 symmetric NAT 的网络,那么在这小部分网络环境中,就不能使用“UDP打洞技术”。 利用“同时开放TCP连接”建立基于TCP的P2P Simultaneous TCP open 同时开放TCP连接这里有一种方法能够在某种情况下建立一个穿透NAT的端对端TCP直连。我们知道,绝大多数的TCP会话的建立,都是通过一端先发送一个SYN包开始,另一方则回发一个SYN-ACK包的过程。然而,这里确实存在另外一种情况,就是P2P的双方各自同时地发出一个SYN包到对方的公网地址上,然后各自都单独地返回一个ACK响应来建立一个TCP会话,这个过程被称之为:“Simultaneous open”(“同时开放连接”)。 如果一个NAT接收到一个来自私有网络外面的 TCP SYN 包,这个包想发起一个“引入”的 TCP 连接,一般来说,NAT会拒绝这个连接请求并扔掉这个SYN 包,或者回送一个TCP RST(connection reset,重建连接)包给请求方。但是,有一种情况,当这个接收到的 SYN 包 中的源IP地址和端口、目标IP地址和端口都与NAT登记的一个已经激活的TCP会话中的地址信息相符时,NAT将会放行这个SYN 包,让它进入NAT内部。特别要指出,如果NAT恰好看到一个刚刚发送出去的一个SYN包也和上面接收到的SYN包中的地址信息相符合的话,那么NAT将会认为这个TCP连接已经被激活,并将允许这个方向的SYN包进入NAT内部。如果 Client A 和 Client B 能够彼此正确的预知对方的NAT将会给下一个TCP连接分配的公网TCP端口,并且两个客户端能够同时地发起一个“外出”的TCP连接,并在对方的 SYN 包到达之前,自己刚发送出去的SYN包都能顺利的穿过自己的NAT的话,一条端对端的TCP连接就成功地建立了。不幸的是,这个诡计比3.4节所讲的UDP端口预言更容易被粉碎,并且对时间的敏感性的依赖更多!首先,除非双方的NAT都是Simple firewalls 或者都像cone NAT那样处理TCP通信,否则两个客户端还是无法建立这个TCP直连,因为它们无法预知对方的NAT会分配给新的会话的端口号是多少。 另外,如果双方的 SYN 到达对方的NAT 速度太快(举例来说,就是SYN A的还未穿过NAT A时,SYN B已经提早到达了NAT A),对方的NAT会将这个SYN扔掉,并返回一个 RST 包,这样就使得这个发快了的一方NAT关闭原来的会话,又重新建立一个新的会话,再利用这个新的会话重发一个SYN,这时端口预言就失效了,因为再次分配到相同的端口地址的几率太小了。 最后,尽管在“TCP规范”中说明了“Simultaneous open”是一种支持的标准技术,但是在一些公共操作系统中,对这种技术的支持并不好。基于这个原因,我们也在这里郑重申明,并不推荐使用这个技术。如果您的应用程序想要穿透NAT并进行高效率高性能的P2P的通信,应该使用UDP技术!
过程详细描述: Client A发送一个TCP SYN包给 Client B,我们把这个SYN包叫做SYN A,包含的信息如下: SrcAddress:10.0.0.1 Tcp port:1234 DestAddress:138.76.29.7 Tcp port:310000 同时,Client B发送一个TCP SYN包给Client A,我们把这个包叫做SYN B,包含的信息如下: SrcAddress:10.1.1.3 Tcp port :1234 DestAddress:155.99.25.11 Tcp port:620000 SYN A首先通过NAT A(必须在SYN B到达NAT A之前),NAT A看到这个包并将其地址信息进行转换为: SrcAddress:155.99.25.11 Tcp port :620000 DestAddress:138.76.29.7 Tcp port:310000 我们把这个经过 NAT A转换的包叫做SYN A’ 同样,SYN B首先通过NAT B(也必须在SYN A到达NAT B之前),NAT B看到这个包并进行地址转换为: SrcAddress:138.76.29.7 Tcp port:310000 DestAddress:155.99.25.11 Tcp port :620000 我们把这个经过NAT B转换的包叫做SYN B’ 这时,NAT A和NAT B都在自己的TCP连接表中存储了含有上面两个公网IP地址和端口信息,因此,只要看到包含这两个信息的SYN包,都会让其通过。 就在这个瞬间,SYN A’到达了NAT B,NAT B检查了一下SYN A’,发现它的地址信息和自己TCP连接表中的信息相符,便让SYN A’通过了,并将SYN A’的地址信息转换为:我们称这个包为SYN A’’ SrcAddress:155.99.25.11 Tcp port :620000 DestAddress:10.1.1.3 Tcp port:1234 以使这个包能够到达内部网中Client B上 也就在这个瞬间,SYN B’到达了NAT A,NAT A检查了一下SYN B’,发现它的地址信息和自己TCP连接表中的信息相符,便让SYN B’通过了,并将SYN B’的地址信息转换为:我们称这个包为SYN B’’ SrcAddress:138.76.29.7 Tcp port :310000 DestAddress:10.0.0.1 Tcp port:1234 以使这个包能够到达内部网中Client A上 http://wltiger.spaces.live.com/blog/cns!FEEA53769C20623!342.entry |
P2P之UDP穿透NAT的原理与实现(附源代码)
P2P之UDP穿透NAT的原理与实现(附源代码)
2010-09-27 9:39
|