P2P之UDP穿透NAT原理

首先先介绍一些基本概念:
    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 SNAT B给此次Session分配的端口是40000,那么Server S收到的B的地址是187.34.1.56:40000
    
此时,Client AClient 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 BClient A方向打洞。呵呵,是不是很绕口,不过没关系,想一想就很清楚了,何况还有源代码呢(侯老师说过:在源代码面前没有秘密 8)),然后Client A就可以通过Client B的外网地址与Client B通信了。

    
    
注意:以上过程只适合于Cone NAT的情况,如果是Symmetric NAT,那么当Client BClient A打洞的端口已经重新分配了,Client B将无法知道这个端口(如果Symmetric NAT的端口是顺序分配的,那么我们或许可以猜测这个端口号,可是由于可能导致失败的因素太多,我们不推荐这种猜测端口的方法)。

另外在网上找到了UDP打洞的不错的代码,希望和大家分享一下。首先声明一下,很多文章都是以前收集的,很多出处已经不知道,望原作者原谅,如有不变请告诉我。
服务器的代码:
Imports  System.Net
Imports
 System.Net.Sockets
Imports
 System.Text
Imports
 System.Threading
Imports
 System.Collections

Module myUDPServer

全局变量


参数

#Region "方法"

    
'主函数,程序入口
    Sub Main()

    
'打印在线用户
    Sub showUser()

    
'服务器监听函数
    Sub listen()

    
'转发P2P连接请求
    Private Sub questP2PConn()

    
'函数.返回所有在线用户.其格式:用户名+|+用户IPEP+|
    Private Function getUserList()

    
'用户登陆,直接返回登陆是否成功的值
    Private Function userLogin()

    
'用户登出
    Private Sub userloginout()

    
'保持用户在线的过程
    Private Sub holdOnLine()

    
'用户超时退出
    Private Sub onLineTimeOut()

    
'发送消息的函数
    Sub sendMsg()

#End Region


End Module

客户端的代码:
Imports  System.Net
Imports
 System.Net.Sockets
Imports
 System.Text
Imports
 System.Threading


Module Module1

参数


#Region "全局全量"

    
Delegate Sub myMethodDelegate()


#Region "方法"

    
'主函数,程序入口
    Sub Main()

    
'登陆函数
    Private Function Login()

    
'登出函数
    Private Sub exitApp()

    
'请求好友列表的函数
    Private Function getU()

    
'登陆时用来异步的接收服务器发送的消息
    Sub recvLogin()

    
'请求好友名单时用来异步接收服务器发送的消息
    Sub recvGetU()

    
'处理收到的在线用户信息
    Private Sub getUserList()

    
'显示在线用户
    Private Sub showUserList()

    
'客户程序监听的函数
    Sub listen()

    
'发送聊天消息
    Private Sub sendChatMsg()

    
'处理聊天消息
    Private Sub showChatMsg()

    
'处理打洞函数
    Private Sub makeHold()

    
'处理用户上线的函数
    Private Sub addOnLine()

    
'处理用户下线的函数
    Private Sub removeOnLine()

    
'发送消息的函数
    Public Function sendmsg()

    
'用保持在线状态的函数
    Private Sub holdonline()

#End Region


End Module

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
P2P技术揭秘:P2P网络技术原理与典型系统开发》从一个全新的视角向读者展示了从P2P初步入门到应用实践的学习之路。《P2P技术揭秘:P2P网络技术原理与典型系统开发》从理论到实践,从基础到项目,循序渐进地讲解了P2P技术的基本知识体系,同时配合开发案例引导读者进行P2P应用实战开发。书中对每一个知识点、原理思想、应用方法及实例都进行了深入浅出的阐述和分析,力求让读者读完《P2P技术揭秘:P2P网络技术原理与典型系统开发》后有所学、有所悟、有所得。 《P2P技术揭秘:P2P网络技术原理与典型系统开发》共14章,分为3篇。主要内容包括P2P概述、P2P网络拓扑结构、P2P网络搜索技术、P2P关键技术及应用、P2P网络中的nat穿透技术、基于P2P的bittorrent(后文简称bt)技术、基于P2P的emule文件共享技术、基于P2P的skype即时通信技术、基于P2P的流媒体技术、基于java的P2P开发平台搭建、sloape的开发包及插件开发技术、基于P2P的即时通信系统的开发与实现、bt系统分析及客户端开发、jxta技术等。另外,《P2P技术揭秘:P2P网络技术原理与典型系统开发》配书光盘中收录了专门为《P2P技术揭秘:P2P网络技术原理与典型系统开发》录制的多媒体教学视频及书中涉及的源代码,便于读者更加直观、高效地学习。 《P2P技术揭秘:P2P网络技术原理与典型系统开发》适合P2P技术入门人员及网络视频、网络电话、多线程下载等网络软件开发人员。另外,《P2P技术揭秘:P2P网络技术原理与典型系统开发》对于大中专院校相关专业的学生和老师也有很好的借鉴意义。 ——《豆瓣读书》

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值