UDP 打洞技术

P2P之UDP穿透NAT原理并有UDP打洞的源码

首先先介绍一些基本概念：
    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