Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1520394
  • 博文数量: 114
  • 博客积分: 10010
  • 博客等级: 上将
  • 技术积分: 1357
  • 用 户 组: 普通用户
  • 注册时间: 2006-11-19 18:13
文章分类
文章存档

2010年(8)

2009年(9)

2008年(27)

2007年(62)

2006年(8)

我的朋友

分类: LINUX

2008-01-30 11:51:15

北京理工大学  20981  陈罡
 
继续。。。
 
3.5 p2p客户端位于多层NAT设备后面
 
有的网络拓扑结构包含了多个NAT设备,如果没有掌握该拓扑结构的详细信息,两个客户端
之间是无法建立“最优化”的p2p路由的。现在我们来讨论最后一种情况,如图6所示。假定
NAT C是由ISP(Internet Service Provider)提供的工业级的NAT设备,NAT C提供将多个
下属的用户NAT或用户节点映射到有限的几个公网IP的服务,NAT A和NAT B做为NAT C的内网
节点将把用户的家庭网络或内部网络接入NAT C的内网,然后用户的内部网络就可以经由NAT C
访问公网了。从这种拓扑结构上来看,只有服务器S与NAT C是真正拥有公网可路由IP地址的
设备,而NAT A和NAT B所使用的“公网”IP地址,实际上是由ISP服务提供商设定的(相对于NAT C
而言)内网地址(本位的后续部分我把这个由ISP提供的内网地址相对于NAT A和NAT B称之为
“伪”公网地址),同理隶属于NAT A与NAT B的客户端,相对与NAT A,NAT B而言,它们处于
NAT A,NAT B的内网,以此类推,客户端可以放到到多层NAT设备后面。客户端A和客户端B
发起对服务器S的连接的时候,就会依次在NAT A和NAT B上建立向外的session,而NAT A、
NAT B要联入公网的时候,会在NAT C上再建立向外的session。
(图 6)
现在假定客户端A和B希望通过UDP“打洞”完成两个客户端的p2p直连。最优化的路由策略是
客户端A向客户端B的“伪公网”IP上发送数据包,即ISP服务提供商指定的内网IP,NAT B的
“伪”公网endpoint,10.0.1.2:55000。由于从服务器S的角度只能观察到真正的公网地址,
也就是NAT A,NAT B在NAT C建立的session的真正的公网地址155.99.25.11:62000以及
155.99.25.11:62005,所以非常不幸,客户端A与客户端B是无法通过服务器S知道这些
“伪”公网的地址的。而且即使客户端A和B通过某种手段可以得到NAT A和NAT B的“伪”公网
地址,我们仍然不建议采用上述的“最优化”的打洞方式,这是因为这些地址是由ISP服务
提供商提供的或许会存在与客户端本身所在的内网地址重复的可能性。(例如:NAT A的
内网的IP地址域恰好与NAT A在NAT C的“伪”公网IP地址域重复,这样就会导致打洞数据包
无法发出的问题)
 
因此客户端别无选择,只能使用由公网服务器S观察到的A,B的公网endpoint进行“打洞”
操作,用于“打洞”的数据包将由NAT C进行转发,这里NAT C是否支持“发夹”转换或“环路”
转换非常重要,否则数据包将无法由NAT C转发给NAT A和NAT B,进而无法到达客户端A和B。
当客户端A向客户端B的公网endpoint(155.99.25.11:62005)发送UDP数据包的时候,NAT A
首先把数据包的源endpoint由A的内网endpoint(10.0.0.1:4321)转换为“伪”公网endpoint
(10.0.1.1:45000),现在数据包到了NAT C,NAT C应该可以识别出来该数据包是要发往
自身转换过的公网endpoint,如果NAT C可以给出“合理”响应的话,NAT C将把该数据包的
源endpoint改为155.99.25.11:62000,目的endpoint改为10.0.1.2:55000,即NAT B的
“伪”公网endpoint,NAT B最后会将收到的数据包发往客户端B。同样,由B发往A的数据包
也会经过类似的过程。也有很多NAT设备不支持类似这样的“发夹”转换,但是已经有越来
越多的NAT设备生产厂商开始加入对该转换的支持。
 
3.6 UDP在空闲状态下的超时问题
 
由于UDP转换协议提供的“洞”不是绝对可靠的,多数NAT设备内部都有一个UDP转换的空闲状态
计时器,如果在一段时间内没有UDP数据通信,NAT设备会关掉由“打洞”操作打出来的“洞”,
做为应用程序来讲如果想要做到与设备无关,就最好在穿越NAT的以后设定一个穿越的有效期。
很遗憾目前没有标准有效期,这个有效期与NAT设备内部的配置有关,最短的只有20秒左右。
在这个有效期内,即使没有p2p数据包需要传输,应用程序为了维持该“洞”可以正常工作,也
必须向对方发送“打洞”维持包。这个维持包是需要双方应用都发送的,只有一方发送不会维持
另一方的session正常工作。除了频繁发送“打洞”维持包以外,还有一个方法就是在当前的“洞”
有效期过期之前,p2p客户端双方重新“打洞”,丢弃原有的“洞”,这也不失为一个有效的方法。
 
未完待续。。。
阅读(3030) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~