p2p通信 nat打洞设计文档.docVIP

P2P设计文档 版本 日期 内容 作者 1.0 09-10-2012 Yuehui.lu  系统总体架构及关键流程 1.客户端服务器分布 打洞方案一 P2P穿越nat可以分为两步： 识别通信双方是哪种类型的nat。需要得到NAT的类型和以下一些数据UDP是否通过：UDP是否被防火墙干掉了？本机在公网上还是在NAT之后映射是否相同：映射相同则为Cone NAT，否则就是对称型IP是否受限：如果是Cone NAT，那么是否存在受限IP的特性PORT是否受限：如果是Cone NAT，那么是否存在受限端口的特性?设通信双方为A、B，NAT分别是Na和Nb，S是服务器。NAT类型简写对应：全锥形-FC，限制锥形-RC，端口限制锥形-PC，对称型-SN其中一个具有公网地址的情况假设具有公网地址的为A，那么，A通知S：A希望与B建立通信，然后S转告B，让B主动连接A的公网地址，当B连接到A之后，A就可以通过B向A打的洞与B进行通信了，而无论B是何种类型的NAT全锥形假设Na是FC，由于FC的特性：内网中同主机同端口与外部的所有通信都使用同一个洞，当这个洞被打开后，所有外部主机都可以使用这个洞向这个内网地址（IP:PORT）发送数据。所以只要其中一方是FC，就可以实现双方的直接通信。 这些组合的打洞流程如下：A通知S，让S通知B向A已经存在的那个洞发送数据。那么A是肯定可以收到B发来的这个包的，这时A再回复B，则AB间的链路成功建立。而不论Nb是什么类型（原因同“其中一个具有公网地址的情况“）。RC-FC属于“其中一个属于FC的情况“，上面已经证明过，跳之。 RC-RC：令B发包给A(锥形NAT对于所有会话都使用同一个端口，所以现在他们是互相知道彼此在NAT上映射的外网地址的)，此时将会被Na丢掉，因为在这个时候Na之上的洞认为：此洞为S而开（此洞在A登陆S的时候就打好了），只有S的端口可以往此洞发包（Na是受限型NAT）。但这个操作将使Nb上的洞改变属性为：此洞已向A发包，以后就可以接收来自A和S的包了。那么接下来A再向B发包，B将收到。同理，在A向B发包之后，Na上的洞也修改了属性：此洞已向B发过包，以后将可以接收来自A和S的包，然后B再回复给A，则连接成功建立。（考虑到说明的简洁性，描述中省去了双方和S的交互过程，实际编码流程中需要自行加上，下同） ?????? RC-PC：B向A发包，那么将被Na丢弃，同时Nb的洞会改变属性为：此洞已向A在Na上的地址（IP:PORT）发过包（注意这里带上了端口，因为Nb是PC型，只能接收来自曾经向外打过洞的IP和端口数据），然后A向B发包，B将收到（Nb已经记录了通向Na是合法的，同样，来自Na的数据也就是合法的了，同时Na也就改变属性认为：以后来自B的数据是合法的），这时B再回复A，连接就成功建立了。其实这个过程和RC-RC是一样的，只是为了说明第一步B向A发包之后NAT B对洞B做出了不同的解释，同时这也是Nb（端口限制锥型）对于外来数据更为严格的限制。RC-SN：PC-PC的情况B向A发包，被Na丢弃，同时Nb的洞修改为：以后可接收来自Na的数据 A向B发包，B收到，同时Na的洞修改为：以后可接收来自Nb的数据 B向A发包，A收到，连接成功建立 SNSN的情况：无法建立连接 以上的用udp进行nat打洞，使用tcp进行打洞的原理和udp是一样的。但是实现方法会有一点不同，这是因为伯克利socket（标准socket规范）的API造成的。UDP的socket允许多个socket绑定到同一个本地端口，而TCP的socket则不允许自XP Service Pack 2之后的Windows系统和所有Unix或linux系统的 socket都有属性SO_REUSEADDR，这就可以实现。对于不支持socket SO_REUSEADDR属性的系统，可以采用顺序连接来打洞的方式。即A与S连接通信之后，断开连接，然后尝试与B连接，失败后listen and AccpetB的连接。 流程 类型识别两个公网IP其中每个公网IP绑定两个UDP端口，所以，服务端一共有4个UDP套接口，假设为：A1:P1、A2:P2、B1:P1、B2:P2。发送消息给A1:P1，测试是否能收到响应，以验证UDP是否能通过A2:P2，MappedAddress1和步骤2中收到的MappedAddress2进行比较。如果相同则表明是Cone NAT，否则是对称型nat（验证NAT是否对不同的目的地址进行了相同的映射A1:P1发送消息，然后S端用A2:P1回复。测试是否能收到，以验证IP是否受限A1:P1发送消息，然后S端用A1:P2回复。测试是否能收到，以验证是否受限设通信双方为