P2P之UDP穿透NAT

mhz-ada

                                                                                                在P2P下使用NAT，一直对这个很感兴趣，最近特意上网找了下资料
英文版的：
Peer-to-Peer (P2P) communication across middleboxes
http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
还有中文版的：
源码下载:
http://www.ppcn.net/upload/2005_08/05080112299104.rar
参考：
http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt
P2P之UDP穿透NAT的原理与实现(作者：shootingstars)
http://www.ppcn.net/n2422c38.aspx
P2P之UDP穿透NAT的原理与实现--增强篇（作者: Hwycheng Leo(
FlashBT@Hotmail.com
)）
再次对以上网友的早期贡献表示感谢
我的学习主要是在Cone NAPT下的
我理解的p2p下面的UDP穿透NAT，主要是分成三类：
Peers behind different NATs
Peers behind the same NAT
Peers separated by multiple NATs
先介绍下第一类吧，在不同NAT的Client
                                Server S
                            18.181.0.31:1234
                                   |
                                   |
            +----------------------+----------------------+
            |                                             |
          NAT A                                         NAT B
    155.99.25.11:62000                            138.76.29.7:31000
            |                                             |
            |                                             |
         Client A                                      Client B
      10.0.0.1:1234                                 10.1.1.3:1234
其中第一类又分为一个是公网IP，一个是私网IP的客户端
这个时候嘛，一台外网IP地址的计算机想和NAPT后面的内网计算机通讯的条件，
就是要求NAPT后面的内网计算机主动向外网IP地址的计算机发起一个UDP数据包。
外网IP地址的计算机利用收到的UDP数据包获取到NAPT的外网IP地址和映射的端口，
以后就可以和内网IP的计算机透明的进行通讯。
然后是最重要的两个都是NAPT内网的客户端，这个时候就需要一个Server S来辅助下了，因为这两个客户端是
互相的不知道对方的私网IP跟公网IP的映射关系的，假设两个客户端，一个为A，一个为B，A和B都从S上获取了
对方的映射关系，A想跟B连接，这个时候呢，A会先告诉S，自己想要跟B连接，这时候需要S告诉B，A想要连你，
你去连接A吧，同时A会发起向B的公网IP以及那个映射端口号的连接，当然这个时候A自身会在NAPT上面建立一个
session，保存下A's private address and B's public address的通信映射，同时，B向A发送连接，所以
本机有了B's private address and A's public address的映射关系，这样就建立了UDP通信连接了，A和B就
可以直接通信了。
注释下：A->B是在A的NAPT上面建立一个从映射，这个映射能将从A的数据发送到B的NAPT上那个端口，将B的NAPT
       上那个端口发送过来的数据，有A的NAPT转发到A的本机上，B->A也是一个道理。
第二类，在同一个NAT子网内
                                Server S
                            18.181.0.31:1234
                                   |
                                   |
                                  NAT
                         A-S 155.99.25.11:62000
                         B-S 155.99.25.11:62001
                                   |
            +----------------------+----------------------+
            |                                             |
         Client A                                      Client B
      10.0.0.1:1234                                 10.1.1.3:1234
A，B，还是会从S上获取响应的信息，那么A发送到NAPT上，NAPT又发送到B上，相当于一个环回传输，这个走NAPT
的步骤明显没有必要，且加大了NAPT的负荷，解决办法如下，A或者B用两个地址分别进行通信，使用第一个成功
建立连接的地址，当在一个NAT内，明显是用内网地址，就不用走NAPT了，省时省力没负荷，如果不在一个NAT内
那么内网地址通信肯定会失败的，后面就还是按照第一类的流程走下去了
注：这种数据包最好还是验证下，因为完全可能在不同的NAT时，A发向B的数据包，结果送到另外的Client上了
第三类,多重NAT
                                Server S
                            18.181.0.31:1234
                                   |
                                   |
                                 NAT X
                         A-S 155.99.25.11:62000
                         B-S 155.99.25.11:62001
                                   |
                                   |
            +----------------------+----------------------+
            |                                             |
          NAT A                                         NAT B
    192.168.1.1:30000                             192.168.1.2:31000
            |                                             |
            |                                             |
         Client A                                      Client B
      10.0.0.1:1234                                 10.1.1.3:1234
很明显，最佳方法是A直接发送消息给NAT B的public address,但是由于S看到的是A和B的public address，
所以A和B互相之间也了解的是这个，即使互相晓得了，ISP在一个NAT里面分配的private address也可能会与
A和B的造成冲突（ISP's private addressing realm might conflict with unrelated address assignments
in the clients' private realms）
               
               
               
               
               
               
               
               
               
               
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u2/80823/showart_1305907.html