通过middlebox实施P2P通讯一[传]

类别:编程语言 点击:0 评论:0 推荐:
http://www.blogcn.com/User6/caimouse/index.html
我是一边看一边随手翻的,翻的很差,本来不好意思贴出来的,可能大家看原文更明白些。

 我的MSN:[email protected]

 QQ: 27443675

 希望对大家有一些帮助,我的目的是希望能和有兴趣和正在做P2P的程序员们结交朋友,谢谢大家支持。

 1. 介绍
 今天的Internet的"middleboxes"已经普遍存在, 比如象网络地址转换(NAT),主要是因为IPv4的地址空间消耗危机中产生的一个解决方案。然而,由这些"middleboxes"建立的不对称寻址和连接,已经成为点对点 (P2P)应用和协议中独特的问题, 这些应用和协议包括例如网络电话和多人在线游戏。这些话题甚至可能在使用 IPv6 协议后继续存在, 比如说在 NAT 常被当作兼容 IPv4 机制[NAT-PT]的地方,还有当NAT 不再需要之后,防火墙将会依然存在(这些问题)。

 当前发展的"middleboxes"最初计划用在C/S结构中,即在那些相关的匿名客户端主动去连接有着固定IP地址和DNS域名的可连接主机。大多数的"middleboxes"实现一个不对称的沟通模型,即那些私有的内部网络上的主机可以和公网上的主机连接通讯,但是公网上的外部主机不能够和内网上的主机通讯除了被 middlebox''s 的管理者明确地配置之外。 在 NAPT 的通常情形中,在内部网络上的一位客户机在公网上并没有一个唯一独特的IP地址,但是可以在同一私网上的其他客户机一样,分享一个公网IP地址,并有NAPT管理。 这些在一台"middlebox"后的不知道名称和不易访问的内部主机对客户端软件比如网页浏览器并不是一个问题,它们之需要向外连接。而且这种不易访问的特性有时候被视为对保护隐私有利。 

 但是,在点对点的应用中,英特网上的主机通常会考虑要和"客户"建立直接和彼此访问的通话连接。呼叫者和被叫者可能会在不同的"middleboxes" 后面,两者都可能没有任何的固定IP地址或者其他的公网存在表现。举例来说,一个通常的在线游戏架构,是让参加游戏的主人连接到一个大家都知道的服务器上设定一些初识值,以及连接后的使用目的。然后,为了在游戏期间有更加快速和有效的游戏速度,需要建立彼此直接的连接。同样地,一个可共享的文件可能可以让一个大家都知道的资源搜索引擎发现或者查找到,但如果需要文件数据传输,就需要和那台共享文件的主机建立直接的连接了。在点对点连接时,"middlebox"就生成了一个问题。因为在"middlebox"后面的那些需要用TCP或者UDP和其他机器连接的主机通常没有固定可用的公网端口可以进行连接。 RFC 3235[ NAT-APPL]简短地说明了这个问题,但是没有提供任何的通常解决方案。 

 在这一份文档中,我们就 P2P/ middlebox 问题有2点说明。 首先,我们总结那些在middleboxes存在时P2P应用程序可以工作的已知方法。其次,我们提供基于这些实践的一套应用程序设计指导方针使P2P在middleboxes下应用的更健康。更进一步,我们提供的设计指导方针可以让将来的 middleboxes 更有效率的支持支援 P2P 应用。 我们的重点是要能够穿透 middleboxes,以提供更广阔和更直接的P2P 应用。 

 2. 术语
 在本章中我们首先简要描述一下一些"middlebox"术语,我们这里的重点是两种常导致P2P应用出现问题的middlebox.

 防火墙
 一个防火墙限制私人内网和公众英特网之间的通讯,典型地防火墙就是丢弃那些它认为未经许可的数据包。在数据包穿越一个防火墙时,它检查但是不修改包里的 IP地址和TCP/ UDP 端口信息。
   
 网络地址转换(NAT)
 当数据包穿过NAT时,NAT不仅检查同时也修改数据的包头信息,并且允许更多的在NAT后的主机分享少数公网IP地址(通常只有1个)。

 NAT通常有2种主要类型:
 Basic Nat
 一个Basic NAT映射一个内在的私有IP地址到一个公网IP地址,但当数据包穿过NAT时,不更换它的TCP/UDP端口号。Basic Nat通常是只用在一些具备公共IP地址池的NAT上,通过它可以地址绑定,即代表一台内部主机。

 Network Address/Port Translator (NAPT)
 但是最通常的,当数据包穿过NAT时,一个NAPT检查并修改它的TCP/UDP端口,那么就可以允许多台内网主机同时共享一个单独的公网IP地址了。

 关于 NAT 的分类和术语,[NAT-TRAD] 和 [NAT-TERM]中有更多的信息。那些将来分类的NAPT的附加术语在较近的工作[STUN]中被定义。当一个内网的主机经过一个NAT和外部进行TCP或者UDP连接的期间,NAPT分配一个公网IP 住址和端口,以便来自外部终端响应的数据包能被NAPT接收,解释,并转发给内网的主机。这个结果是由 NAPT 建立一个(私有IP地址,私有端口)和(公网IP地址,公网端口)之间的端口绑定实现的。在这个期间NAPT将为绑定的端口执行地址翻译。一个关于P2P应用的问题是,当一个内部主机从一个私有IP,私有端口同时与外网上的多台不同的主机建立多个连接时,NAT是如何运作的。

 Cone NAT
 建立一个端口,把一个(私有IP,私有端口)和(公用IP,公用端口)绑定后,对于以后来自同一私有IP和端口号的应用连接,cone NAT将重复使用这个绑定的端口,只要有一个连接会话,这个绑定端口就会保持激活状态。
 例如,下面图表中,推想一下客户端A通过一个cone NAT同时建立2个外部会话,从同样的内部网络终端(10.0.0.1:1234)到2个不同的外部服务器,S1和S2。cone NAT只会分配一个公用的终端,155.99.25.11:62000,都会到两个会话,并在地址转换期间确保客户端端口的一致。Basic NAT和防火墙不修改通过middlebox的数据包中的端口号,这些类型的middlebox可以被认为是一种特殊的Cone Nat。

  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

 Symmetric NAT
 对称的NAT(Symmetric NAT),与Cone NAT有明显差别,在所有会话期间中不会保持绑定(私有IP,私有端口)和(公共IP,公共端口)的端口不变。相反,它会为每个新对话重新分配一个新的公共端口。
 举例来说,设想客户A从同样端口上要发起两个外部对话,一个和S1连接,另一个和S2连接。Symmetric NAT可能会为第一个会话分配一个公共的端点 155.99.25.11:62000,而为第二个会话分配一个不同的公共端点155.99.25.11:62001。为了地址转换,NAT可以区分这两个会话传输的目的,因为和这些会话有关的外部端点(就是S1、S2)是不同的,甚至在通过地址转换时丢失了客户端的目的标示。(即丢了S1、S2的IP地址NAT也知道如何区分,我是这么理解的,可能有误。)

            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:62001 v
                                       |
                                  Symmetric 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

 Cone NAT和Symmetric NAT之间的比较与TCP/UDP之间的比较有些类似。(TCP需要绑定,UDP不需要,Cone NAT需要绑定,Symmetric NAT不需要)

 按照NAT从已知的公共IP,公共端口接收的数据限制,Cone NAT可以更进一步的进行分类。这种分类通常都是UDP连接的,因为NAT和防火墙会拒绝任何无条件的TCP连接,除非明确地以别的方式配置。 

 Full Cone NAT
 在给一个新的外部会话建立了一个公共/私有的端口绑定后,一个full cone NAT就可以通过这个公共端口从公网上的任何外部端点接收数据通讯了。Full cone NAT也常常叫做"混合"NAT。

 Restricted Cone NAT
 当网络主机发一个或者几个数据包给外部主机后,一个受限的cone NAT(Restricted Cone NAT)才会接受来自这个外部(源)IP地址的数据包。受限的cone NAT有效的运用了防火墙的原理,拒绝没有要求的数据,只接收已知道的外部IP地址传来的数据。(偏开原文,大意就是网络主机需要发一个请求给外部IP地址要求要数据,NAT才会接收这个外部IP地址传来的数据,不然不接收。)

 Port-Restricted Cone NAT
 一个端口受限的cone NAT(Port-Restricted Cone NAT),也是这样,只接收那些网络主机曾经发给一个外部IP地址和端口相匹配的数据。一个Port-Restricted cone NAT可以和对称 NAT一样(symmetric NAT),保护内部节点不接收未被请求的数据包,但是保持一个私有端口在连接过程中不变。
 (偏开原文,即不仅请求的IP和外部发来数据的IP是一样的,PORT也要是一样,这样才接收数据。对称NAT也有这个效果,但这种cone NAT保持端口不变,而对称NAT要变端口号的)。

 最后,在这篇文档中我们定义一些新的术语来给middleboxes中有关P2P的行为进行分类:

 P2P-Application
 在这篇文档中P2P-Application被当做一个应用程序,在那些参与P2P连接的并在一个公共的登录服务器注册的终端运行,可以是一个私有端点,也可以是一个公共端点,或者两者都是,并建立一个初步的会话。

 P2P-Middlebox
 P2P- Middlebox就是允许P2P应用程序交换数据的的middlebox。

 P2P-firewall
 一个P2P-防火墙就是提供防火墙功能的P2P- Middlebox,但不具备地址映射功能。

 P2P-NAT
 P2P-NAT就是提供NAT功能,也提供防火墙功能的P2P- Middlebox。一台P2P- Middlebox必须为UDP传输至少提供Cone NAT功能,允许应用程序使用UDP建立完整的P2P连接。
    
 loopback translation(自环映射)
 当一台位于私有域的主机,它的NAT试图用此主机在公网的映射地址连接其他位于同样NAT后的其他主机,相当于NAT装置在数据包上做了两次NAT转换。在数据报到达目标主机之前,源主机的私有端点被转换成NAT分配的公共端点,然后把目标主机的公共端点转换成目标主机的私有端点。我们在上面提到的地址转换用一台NAT装置完成就称为"Loopback translation"。

 3. 用middleboxes进行P2P通讯的技术
 这段文章详细的回顾一下使用现有的middlebox实现P2P通讯的技术,主要从应用程序或协议设计上来述说。

 3.1 Relaying(传输)
 最可靠的,但是效率最低的,实现P2P通讯的方法就是在传输过程中,把P2P通讯看成向C/S通讯的网络一样。例如,推想2个客户主机,A和B,各自发起一个TCP或UDP的连接,连接到一个大家都知道的拥有固定IP地址的服务器S上。客户主机都在各自的私有网络中,但是它们各自的middlebox不允许自己的客户端可以直接和其它主机连接。
                                 Server S
                                    |
                                    |
             +----------------------+----------------------+
             |                                             |
           NAT A                                         NAT B
             |                                             |
             |                                             |
          Client A                                      Client B

 不能直接连接,两个客户端就使用S服务器进行消息的传递。例如,要发送一条信息到客户端B,客户端A以C/S连接方式简单的发送一条信息到S服务器,然后S服务器使用已经和客户端B建立的C/S连接发送这条信息到客户端B。

 这种方法的优势在于只要两个客户端都连在服务器上,它就是有效的。它的明显缺点是它需要了服务器的处理并占用了带宽,而且即使服务器的网络状况良好,也有一定的通讯滞后问题。TRUN协议[TURN]定义了这种P2P应用的相关方法。

 

本文地址:http://com.8s8s.com/it/it27336.htm