p2p打洞技术文章

英文地址：http://midcom-p2p.sourceforge.net/draft-ford-midcom-p2p-01.txt

互联网草案B.福特

文件：草案 - 福特 - 中间盒通信的P2P-01.txt麻省理工学院
到期日：2004年4月27日，第Srisuresh
                                                          Caymas系统
                                                                D.凯格尔
                                                               kegel.com
                                                            2003年10月




              对等网络（P2P）跨中间件通信




本备忘录的状态


   这个文件是一个Internet草案，并须遵守所有规定
   的RFC2026的第10节。互联网草案是文档
   互联网工程任务组（IETF），其领域及其
   工作组。请注意，其他团体也可以分配工作
   文档作为Internet草案。


   Internet草案的有效期最长为六个月文件草案
   并且可以更新，替换，或在任何其他文件废弃
   时间。这是不恰当的使用互联网的草稿作为参考
   材料或举他们比其它“进展中的工作。”


   当前Internet草案的列表可以在访问
   http://www.ietf.org/1id-abstracts.html


   Internet草案阴影目录的列表可以在访问
   http://www.ietf.org/shadow.html


   本文档的分发不受限制。


版权声明


   版权所有（C）互联网协会（2003年）。版权所有。




抽象


   本文定义由当前对等网络使用的方法
   （P2P）应用到在中间盒的存在下进行通信
   如防火墙和网络地址转换（NAT）。在
   此外，备忘录建议对应用程序设计指南
   他们可以采取的措施和中间盒实施者
   支持P2P应用，即时，广泛部署或
   而不需要使用特殊的代理，中继或中间盒通信
   协议。








福特，Srisuresh＆凯格尔[第1页]


跨中间件2003年10月互联网草案P2P应用






目录


   1.简介............................................... ..
   2.术语............................................... ...
   3.技术已有的P2P通信............
       3.1。中继...............................................
       3.2。逆向连接....................................
       3.3。打洞......................................
             3.3.1。不同的NAT后面的同行..................
             3.3.2。同样的NAT之后....................
             3.3.3。通过多层NAT分隔同行...............
             3.3.4。一致的端口绑定.......................
       3.4。 UDP端口号预测.............................
       3.5。同时TCP开放..................................
   4.应用程序设计指南................................
       4.1。什么跟P2P中间件.........................工作
       4.2。相同的NAT后面的应用........................
       4.3。同伴发现..........................................
       4.4。 TCP的P2P应用....................................
       4.5。利用中间盒通信协议..................................
   5. NAT设计指南........................................
       5.1。弃用采用对称NAT的.....................
       5.2。加入增量锥形NAT支持对称NAT设备
       5.3。维持UDP端口一致的端口绑定.....
             5.3.1。保留端口号........................
       5.4。维持TCP端口一致的端口绑定.....
       5.5。大超时P2P应用......................
   6.安全注意事项......................................




1.简介


   当今的互联网已经看到了无处不在的部署
   “中间件”，如网络地址转换（NAT），驱动
   主要由IPv4地址空间的持续消耗。该
   这些建立不对称寻址和​​连通性制度
   中间件，但是，已经创造了独特的问题，为对等网络
   （P2P）应用程序和协议，如电话会议和
   多人在线游戏。这些问题可能​​会甚至持续
   到IPv6的世界里，NAT通常用来作为IPv4兼容
   机制[NAT-PT]，并且防火墙将仍然是家常便饭，甚至
   后不再需要NAT。


   当前部署的中间件的设计主要是围绕
   客户机/服务器的范例，其中，相对匿名的客户机
   主动发起，以具有稳定良好连接的服务器的连接
   IP地址和DNS名称。大多数中间件实施非对称






福特，Srisuresh＆凯格尔[第2页]


跨中间件2003年10月互联网草案P2P应用




   其中通信模型承载专用内部网络上
   可以启动公共网络上的主机传出连接，但
   外部主机不能启动，除了内部主机连接
   作为具体由中间盒的管理员配置。在里面
   NAPT的常见情况下，内部网络中的客户端没有
   在公共互联网上唯一的IP地址，而是必须共享
   一个公网IP地址，由NAPT管理，与其他主机
   同一专用网络上。匿名性和交通不便
   层NAT内部主机不是客户端问题
   软件如Web浏览器，只需要启动传出
   连接。这交通不便有时被视为隐私
   效益。


   在对等网络模式，但是，互联网的主机会
   通常被认为是“客户”，需要建立通信
   彼此直接会话。在发起方和应答
   可能在于背后不同的中间件既没有终点
   有公网任何永久的IP地址或其他形式
   存在。一个常见的​​在线游戏架构，例如，
   为参与应用程序主机联系一个著名的
   服务器初始化和管理目的。随后
   对此，主机与对方建立直接连接
   对于游戏中的更新快速，高效的传播。
   同样，文件共享应用程序可能会联系一家知名
   服务器资源发现或搜索，而是直接建立
   与数据传输等主机的连接。中间件创建
   ，因为后面的主机对等网络连接问题
   中间盒通常对没有固定的端口
   互联网传入TCP或从其他同行UDP连接
   可定向。 RFC 3235 [NAT-APPL]简单地解决这个问题，
   但不提供任何的解决方案。


   在本文中，我们以两种方式解决P2P /代理的问题。
   首先，我们总结了已知的方法由P2P应用程序可以
   变通中间件的存在。第二，我们提供了一套
   基于这些做法的应用程序设计指南，使
   P2P应用在当前部署的工作更有力
   中间件。此外，我们为未来设计指南
   中间件，让他们支持P2P应用程序的更多
   有效。我们的重点是让直接和广泛部署
   P2P应用那些需要经过。


2.术语


在本节中，我们首先总结了一些术语。在这里，我们重点
对两种中间件的通常导致的P2P问题
应用程序。








福特，Srisuresh＆凯格尔[第3页]


跨中间件2003年10月互联网草案P2P应用




   火墙
      防火墙可以限制私人内部之间的沟通
      网络和公共互联网，通常由丢弃数据包
      这被认为是未经授权的。防火墙检查，但确实
      不修改的IP地址和TCP / UDP的端口信息
      包过关。


   网络地址转换（NAT）
      网络地址转换器不仅检查同时也修改
      在跨越边界流动的分组的标题信息，
      允许多个主机上的NAT后面共享使用较小
      公有IP地址的数量（通常一个）。


   网络地址转换器有两个主要品种：


   基本NAT
      一个基本的NAT内部主机的私有IP地址映射到一个
      在不改变TCP / UDP端口的公共IP地址
      号码穿越边界的数据包。基本NAT一般
      当NAT拥有公网IP地址池唯一有用
      这使代表内部主机的地址绑定。


   网络地址/端口转换（NAPT）
      到目前为止，最常见的，一个网络地址/端口转换检
      和修改都IP地址和TCP / UDP端口号
      分组域穿越边界，允许多个
      内部主机同时共享一个公用IP地址。


   请参阅[NAT-TRAD]和[NAT-TERM]更多一般信息
   NAT分类和术语。进一步分类的附加条款
   NAPT在最近的工作[STUN]中定义。当内部主机
   打开通过网络地址/端口传出TCP或UDP会话
   翻译时，NAPT分配会话的公网IP​​地址，
   端口号，使得从外部后续响应报文
   端点可以通过NAPT接收，翻译，并转发
   到内部主机。其效果是，在NAPT建立
   端口（私有IP地址，私有端口号）和之间的结合
   （公网IP地址，公网端口号）。端口绑定
   定义地址转换的NAPT将为执行
   会议持续时间。相关性P2P的问题
   应用程序是NAT的行为当内部主机启动
   从单一的（私有IP多个并发会话，私人
   口）对多个不同的终端在外部网络上。


   锥形NAT
      建立一个端口（私有IP之间的绑定后，私人
      口）数组和一个（公共IP，公共端口）的元组，一个锥形NAT会
      再将此端口用于后续会话绑定






福特，Srisuresh＆凯格尔[第4页]


跨中间件2003年10月互联网草案P2P应用




      应用可以由相同的私有IP地址发起和
      端口号，如只要至少一个会话使用的端口
      绑定保持活跃。


      例如，在图中假设客户A下面启动两个
      通过一个锥形NAT并发会话传出，从相同的
      内部端点（10.0.0.1:1234）两个不同的
      外部服务器，S1和S2。该锥形NAT只分配一个公
      端点元组，155.99.25.11:62000，为这两个会议，
      确保客户端的端口的“身份”维持
      跨越地址转换。由于基本的NAT和防火墙做
      不要修改端口号为分组流跨越
      在中间盒，这些类型的中间件的可以被看作是一个
      锥形NAT的退化形式。






           服务器S1 S2服务器
        18.181.0.31:1235 138.76.29.7:1235
               | |
               | |
               + ---------------------- + ---------------------- +
                                      |
          ^会话1（A-S1）^ | ^ 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
                                      |
                                   锥形NAT
                                 155.99.25.11
                                      |
          ^会话1（A-S1）^ | ^ 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
                                      |
                                   客户A
                                10.0.0.1:1234






























福特，Srisuresh＆凯格尔[第5页]


跨中间件2003年10月互联网草案P2P应用




   对称NAT
      对称NAT的，与此相反，不保持一致的
      端口（私有IP，私有端口）和（公网IP之间的绑定，
      公共端口）的所有会话。相反，它分配一个新的
      公共端口，每一个新的会话。例如，假设客户端A
      启动两个会议传出来自同一个端口如上一
      与S1和S2。对称NAT可能分配
      公共端点155.99.25.11:62000会话1，然后分配
      不同的公共端点155.99.25.11:62001，当
      应用程序启动会话2. NAT是能够区分
      翻译的目的两次会议之间，因为
      参与会议（S1那些外部端点
      和S2）不同，即使在客户端的端点标识
      应用程序通过地址转换边界丢失。






           服务器S1 S2服务器
        18.181.0.31:1235 138.76.29.7:1235
               | |
               | |
               + ---------------------- + ---------------------- +
                                      |
          ^会话1（A-S1）^ | ^ 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
                                      |
                                 对称NAT
                                 155.99.25.11
                                      |
          ^会话1（A-S1）^ | ^ 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
                                      |
                                   客户A
                                10.0.0.1:1234


   锥与对称NAT行为的问题同样适用
   TCP和UDP流量。


   锥型NAT是根据NAT如何宽松进一步分类
   接受定向到已经建立的（公共的传入流量
   IP，公共端口）对。这种分类一般仅适用于
   UDP流量，因为NAT和防火墙拒绝传入的TCP
   连接无条件尝试，除非专门配置
   不这样做。


   完全NAT






福特，Srisuresh＆凯格尔[第6页]


跨中间件2003年10月互联网草案P2P应用




      建立公共/私有端口，一个新的绑定后，
      即将离任的会议，一个完整的锥形NAT将随后接受
      传入流量从任何相应的公开端口
      在公共网络上的外部端点。完全锥形NAT
      有时也被称为“混杂”NAT。


   受限锥形NAT
      受限锥形NAT只转发传入数据包定向到
      公共端口，如果它的外部（源）IP地址相匹配的
      到内部主机先前发送节点的地址
      一个或多个传出的数据包。受限锥形NAT有效
      提炼拒绝未经请求的传入的防火墙原则
      交通，通过限制入站流量，以一套“已知”的
      外部IP地址。


   端口受限锥形NAT
      端口受限锥形NAT，反过来，只有转发传入
      包，如果它的外部IP地址和端口号相匹配的那些
      到内部主机之前有一个外部端点
      发送传出的数据包。端口受限锥形NAT提供
      内部节点的相同水平反对不请自来的保护
      传入通信，一个对称NAT确实，同时保持了
      跨翻译私有端口的身份。


   最后，本文中我们定义为分类新名词
   中间件的P2P相关的行为：


   P2P的应用
      如本文档中使用的P2P应用是在一个应用程序
      每个参与者的P2P与公共注册
      注册服务器，并分别利用其
      私有地址或公共端点，或同时，要建立
      对等会话。


   P2P-中间盒
      一个P2P的中间盒是一个允许遍历
      P2P应用。


   P2P防火墙
      一个P2P防火墙是一个P2P的中间盒，可提供防火墙
      功能，但不进行地址转换。


   P2P-NAT
      一个P2P-NAT是一个P2P的，提供了NAT功能和
      也可以提供防火墙功能。在最低限度，一个
      P2P的中间盒必须实现UDP流量锥形NAT的行为，
      允许应用程序使用，以建立强大的P2P连接
      在UDP打洞技术。






福特，Srisuresh＆凯格尔[第7页]


跨中间件2003年10月互联网草案P2P应用






   回环翻译
      当在NAT设备的私有域主机尝试
      连接使用相同的NAT设备后面的另一台主机
      主机的公共地址，NAT设备执行
      一个“两次的NAT”翻译等同于包作为
      如下。源主机的私有地址翻译
      到分配给它的公共端点，并且目标主机的公共
      端点被翻译成自己的私有地址，前
      该分组被转发到目标主机。我们称上述
      通过NAT设备为“环回译”进行翻译。
  
3.在中间件技术的P2P通信


   本节将详细回顾了目前已知的技术
   实施在现有中间件的对等通信，
   从应用程序或协议设计者的角度。


3.1。中继


   实现同行的最可靠的，但效率最低的方法
   在一个中间盒的存在等通信是使
   对等网络通信的样子的网络类似的客户机/服务器
   通过中继通信。例如，假设两个客户
   主机A和B，各有发起TCP或UDP的一个连接
   著名的有一个永久的IP地址服务器秒。客户端
   驻留在单独的专用网络，但是，它们各自的
   中间件妨碍任何客户端直接发起
   连接到其他。


                                服务者S
                                   |
                                   |
            + ---------------------- + ---------------------- +
            | |
          NAT通过NAT乙
            | |
            | |
         客户端A客户端B


   相反，在尝试直接连接，两个客户端可以简单地
   使用服务器S在它们之间传递消息。例如，要
   发送消息给客户B，客户端A只是将消息发送到
   沿着已经建立的客户机/服务器连接服务器S，和
   服务者S然后使用其现有的将消息发送到客户机B
   与B的客户机/服务器连接


   这种方法的优点在于，它将始终只要工作






福特，Srisuresh＆凯格尔[第8页]


跨中间件2003年10月互联网草案P2P应用




   两个客户端都连接到该服务器。很明显
   缺点是，它消耗的服务器的处理能力和
   网络带宽不必要，和之间的通信延迟
   两个客户端可能是服务器是否良好进行甚至增加
   连接的。转协议[TURN]定义了实现的方法
   中继在一个相对安全的方式。


























































































福特，Srisuresh＆凯格尔[第9页]


跨中间件2003年10月互联网草案P2P应用




3.2。连接逆转


   第二种技术工作，如果仅在客户端中的一个是后面的
   中间盒。例如，假设客户A是NAT但客户背后
   B具有全局路由的IP地址，如下面的图中：


                                服务者S
                            18.181.0.31:1235
                                   |
                                   |
            + ---------------------- + ---------------------- +
            | |
          NAT A |
    155.99.25.11:62000 |
            | |
            | |
         客户端A客户端B
      10.0.0.1:1234 138.76.29.7:1234


   客户A拥有私有IP地址为10.0.0.1，并且应用程序
   使用TCP端口1234。此客户端已经建立了一个连接
   在公网IP地址18.181.0.31和端口NAT 1235的服务器S有
   分配的TCP端口62000，在自己的公网IP​​地址155.99.25.11，
   担任临时公共端点地址为A的会话
   以S：所以，服务者S认为，客户A在IP地址
   使用端口62000.客户端B 155.99.25.11，但是，有它自己的
   永久的IP地址，138.76.29.7，和对等体的对等应用
   在B是在端口1234上接受的TCP连接。


   现在假设委托人B希望发起对等网络
   与客户端，A，B通信会话可能首先尝试
   联系客户机A的地址，客户端A认为自己
   有，即10.0.0.1:1234，或在地址通过观察
   服务器S，即155.99.25.11:62000。在这两种情况下，但是，
   连接将失败。在第一种情况下，交通定向到的IP
   地址为10.0.0.1将仅仅通过网络，因为被丢弃
   10.0.0.1不是公共可路由的IP地址。在第二种情况下，
   从B TCP SYN请求将到达NAT一个指向端口
   62000，但NAT A将拒绝连接请求，因为只有
   传出连接是允许的。


   尝试和失败建立到直接连接后，
   客户B可以使用服务器S键转发到客户端A请求启动
   一个“倒”连接到客户端B.客户端A，在接收到该
   到S中继的要求，开放时间为B的TCP连接到客户B
   公共IP地址和端口号。 NAT A允许的连接
   继续，因为它是在防火墙内部始发，与客户B
   因为它不是一个中间盒后面可以接收该连接。






福特，Srisuresh＆凯格尔[第10页]


跨中间件2003年10月互联网草案P2P应用






   各种电流对等网络系统，实现这种技术。
   其主要的限制，当然，是它只只要可以作为唯一的
   通信对等体之一是NAT后面：在日益
   其中两个同龄人NAT后面通常情况下，该方法失败。
   由于连接逆转是不是解决问​​题的通用解决方案，
   它是不推荐作为首要战略。应用程序可以选择
   尝试连接逆转，但应能回落
   自动上的另一机构，例如，如果没有一个中继
   “前进”，也不是“逆向”可以建立连接。


3.3。 UDP打孔


   第三种技术，并且在此主要感兴趣的所述一个
   文件，被广泛地称为“UDP打孔”。 UDP打孔
   依靠共同防火墙和锥形NAT的允许的属性
   设计合理的对等网络应用程序“打孔”
   通过中间盒，并与每个直接连接
   另外，即使在双方沟通的主机可能在于中间件后面。
   在RFC 3027 [NAT- 5.1节简要地提及这一技术
   PROT]，并已非正式地在互联网上别处描述
   [KEGEL]在最近的一些协议[TEREDO，ICE]使用。作为名称
   意味着，不幸的是，这种技术可以可靠地工作只与UDP。


   我们将考虑两个具体方案，以及如何应用程序可以是
   设计优雅地处理他们两个。在第一种情况下，
   较常见的情况，两个客户端渴望直接对于─
   点对点通信驻留后面两个不同的NAT。在第二，
   这两个客户端都处于相同的NAT后面，但不要
   一定知道，他们这样做。


3.3.1。不同的NAT后面同行


   假设客户A和B都具有私有IP地址和谎言的背后
   不同的网络地址转换。在对等网络应用程序
   对客户A和B的服务者S运行的每个使用UDP端口1234一
   和B具有与服务器s各自发起的UDP通信会话，
   导致NAT A到分配它自己的公共UDP端口62000为A的会话
   与S，并导致NAT B到其端口31000分配给B的会话
   与S，分别。


                                服务者S
                            18.181.0.31:1234
                                   |
                                   |
            + ---------------------- + ---------------------- +
            | |
          NAT通过NAT乙






福特，Srisuresh＆凯格尔[第11页]


跨中间件2003年10月互联网草案P2P应用




    155.99.25.11:62000 138.76.29.7:31000
            | |
            | |
         客户端A客户端B
      10.0.0.1:1234 10.1.1.3:1234


   现在假设客户端A希望建立一个UDP通讯
   会议直接与客户端B.如果只是简单的发送UDP
   消息B的公网地址，138.76.29.7:31000，那么NAT B就
   通常这些丢弃收到的消息（除非它是一个完整的锥形
   NAT），由于源地址和端口号不匹配的那些
   的S，与原来的传出会议正式成立。
   同样，在B只需发送一个UDP信息给A的公钥
   地址，NAT A将通常丢弃这些消息。


   假设不过，一个发送一个UDP信息到B的公网地址，
   同时通过S中转请求给B，问乙
   开始发送UDP消息到A的公共地址。 A的离任
   针对B的公网地址（138.76.29.7:31000）引起NAT消息
   一个开拓A的私有地址之间的新的通信会话
   与B的公网地址。同时，B的消息A的公用
   地址（155.99.25.11:62000）导致NAT B到开辟新
   B的私有地址和A的公众之间的通信会话
   地址。一旦新的UDP会话中的每个被打通
   方向，客户端A和B可直接互相通信
   没有“引进”服务器S上进一步负担


   在UDP打洞技术有几个有用的属性。一旦
   一个直接对等网络的UDP连接已经两者之间建立
   客户背后中间件，要么连接上一方可以在
   转接管的“介绍人”角色，帮助对方
   建立更多的同行对等网络连接，最大限度地减少
   初步引入服务器S的应用程序做的负载
   不必试图明确检测到它是什么样的中间盒的
   后面，如果有[STUN]，因为上面的程序将建立同行
   对等通信信道同样，如果一种或两种的客户
   不正好是一个中间盒的后面。该打孔技术
   即使使用多个NAT的，其中的一个或两个自动工作
   客户端从公共因特网经由两个或更多的水平除去
   的地址转换。


3.3.2。同样的NAT之后


   现在考虑的场景，其中两个客户端（可能
   不知不觉）恰好位于同一NAT后面，因此
   位于同一专用IP地址空间。客户端A
   建立了与服务者S UDP会话，到常见的NAT有
   分配公共端口号62000.客户端B也同样






福特，Srisuresh＆凯格尔[第12页]


跨中间件2003年10月互联网草案P2P应用




   建立了个会议，并在NAT已指派公
   端口号62001。


                                服务者S
                            18.181.0.31:1234
                                   |
                                   |
                                  NAT
                         一个-S 155.99.25.11:62000
                         B-S 155.99.25.11:62001
                                   |
            + ---------------------- + ---------------------- +
            | |
         客户端A客户端B
      10.0.0.1:1234 10.1.1.3:1234


   假设A和B使用UDP打洞技术所概述
   如上所述使用服务者S建立通信信道作为
   介绍人。然后，A和B将学习对方的公网IP​​地址，
   和端口号由服务者S观察，并开始发送各
   在这些公共地址的其他消息。两个客户端会
   能够相互这种方式，只要在NAT进行通信
   允许内部网络打开翻译UDP会话主机上
   与其他内部主机，而不仅仅是与外部主机。我们指
   这种情况称为“环回译”，因为数据包到达
   从专用网络的NAT被转换，然后“循环
   回“到专​​用网络而不是通过被传递到
   公共网络。例如，当A发送一个UDP数据包到B的公共
   地址，分组最初具有源IP地址和端口号
   的10.0.0.1:124和155.99.25.11:62001的目的地。该NAT
   收到此数据包，翻译它有源
   155.99.25.11:62000（A的公网地址）和目的地
   10.1.1.3:1234，然后将其转发到B.即使回环
   翻译是由NAT，这个翻译和转发支持
   步骤是在这种情况下显然不必要，并有可能增加
   潜伏期A和B之间的对话，以及负担的NAT。


   这个问题的解决方案是简单的，但是。当A和
   最初通过服务器S交换彼此的地址信息，他们
   应包括其自己的IP地址和端口号为“观察到”
   本身，以及它们的地址由S的所观察到的
   客户然后同时开始在发送数据包到对方
   每个他们了解替代的地址，并使用第一
   地址通向成功的沟通。如果两个客户端
   处于同一NAT后面，然后引导到他们的私人包
   地址是可能首先到达，产生一个直接
   沟通渠道不涉及NAT。如果两个客户端
   不同的NAT后面，然后引导到他们的私人包






福特，Srisuresh＆凯格尔[第13页]


跨中间件2003年10月互联网草案P2P应用




   地址将无法到达对方所有，但客户端将
   希望通过各自的公建立连接
   地址。重要的是，这些数据包在被认证
   一些方法，然而，由于在不同的NAT的情况下，这是完全
   可能直指B的私有地址A的邮件到达
   A的专用网络，或者反之亦然一些其他无关的节点。


3.3.3。通过多层NAT分隔同行


   在涉及多个NAT设备某些拓扑，这是不
   可能的两个客户端之间建立一个“最优”P2P路线
   它们而不拓扑的具体知识。考虑
   比如下面的情况。




                                服务者S
                            18.181.0.31:1234
                                   |
                                   |
                                 NAT点¯x
                         一个-S 155.99.25.11:62000
                         B-S 155.99.25.11:62001
                                   |
                                   |
            + ---------------------- + ---------------------- +
            | |
          NAT通过NAT乙
    192.168.1.1:30000 192.168.1.2:31000
            | |
            | |
         客户端A客户端B
      10.0.0.1:1234 10.1.1.3:1234


   假如NAT X是一个大型工业NAT通过互联网部署
   服务提供商（ISP），很多客户复用到一个很少公开
   IP地址和NAT A和B是小额消费NAT网关
   由两个ISP的客户复的独立部署
   他们的私人家庭网络到各自的ISP提供的IP
   地址。只有Server S和NAT X拥有公网IP路由
   地址;而NAT A和NAT B所拥有的“公网”IP地址
   实际上民营ISP的寻址区域，而客户​​A和
   B的依次地址是私有的NAT A的寻址领域
   和B，分别为。每个客户端发起的出站连接
   服务器之前为S，导致NATA和NAT B分别建立一个单一的
   公共/私人翻译，并导致NAT X要建立
   公共/私有转换为每个会话。


   现在，假设客户A和B试图建立一个直接的对于─






福特，Srisuresh＆凯格尔[第14页]


跨中间件2003年10月互联网草案P2P应用




   同行UDP连接。最佳的方法是客户端A
   在NAT B分别发送消息给客户B的公网地址，
   192.168.1.2:31000在ISP的寻址区域，并为客户B以
   在NAT B分别发送消息给A的公网地址，即
   192.168.1.1:30000。不幸的是，A和B都没有办法来学习这些
   地址，因为服务器仅S看到“全球”公网地址
   的客户，155.99.25.11:62000和155.99.25.11:62001。即使
   和B有一些方式来学习这些地址，仍然没有
   保证他们会使用，因为地址分配
   在ISP的私有寻址区域可能与冲突无关
   在客户的私人领域地址分配。客户端
   因此别无选择，只能利用自己的全球公共地址作为
   用S看到了自己的P2P通信，并依靠NAT X来提供
   回送的翻译。


3.3.4。一致的端口绑定


   该打洞技术有一个主要的警告：它只能当
   两者的NAT是锥形的NAT（或非NAT防火墙），其保持
   一致的端口给定之间的结合（私有IP，UDP私人）
   对和（公网IP，UDP公众）对，只要UDP端口
   正在使用中。分配为每个新会话的新的公共端口，作为
   对称NAT呢，就不可能对一个UDP应用程序
   再利用已经建立的翻译与通信
   不同的外部目的地。由于锥体的NAT是最
   广泛，UDP打洞技术是相当广泛
   适用;尽管如此部署NAT的一个相当大的部分是
   对称和不支持的技术。


3.4。 UDP端口号预测


   
   
   
   
   
   
   
   
   


                                  
                              
                                     |
                                     |
              
              | |
       
















   
              | |
              | |
           
        


   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   


                                  
                              
                                     |
                                     |
              
              | |
            
   
   
              | |
              | |
           
        


   
   
   
   
   
   失败。
   
   
















   
   
   


   
   
   
   
   
   
   
   
   
   
   


3.5。


   
   
   
   
   
   
   
   


   
   
   
   
   包。
   
   
   
   
   
   如果
   
   
   
   
   
   


   
   
   
















   
   
   
   
   
   
   
   
   
   为了这
   
   理由;应用
   
   








4.1。


  
  
  
  
  
  
  


4.2。


  
  在这些情况下，
  
  
  


4.3。
 
  
  
  
  
  
  
  


4.4。


















  
  在其
  
  端口。
  
  
  
  


  
  
  协议。
  
  


  
  
  
  
  
  
  
  
  
  
  
  
 
4.5。


  
  
  
  


  
  
  
  
  
  
  
  
  
  
























   
   


5.1。


   
   
   
   
   
   
   
   


   
   
   
   
   


5.2。


   
   
   
   
   会话。


   
   
   
   


5.3。


   
   
   
   
   
   
   
   
   
   
   
   
















   


5.3.1。


   
   
   
   
   
   
   
   
   
   
   
   


   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   
   


5.4。


   
   
   
   
   
   
   


















5.5。


   
   
   
   
   
   
   
   
   
   
   


5.6。


   
   
   
   支持
   
   
   
   
   
   
   
   








   
   
   
   
   
   
   
   
   


6.1。


   
   
   
   
















   
   
   
   域。
   
   


   
   
   
   
   
   
   
   好。
   
   
   
   
   显然，
   
   
   
   
   
   
   消息。


   
   
   
   
   
   
   
   
   
   
   


6.2。


   
   
   
   
   
   
















   
   
   
   
   


   
   
   
   
   
   
   
   
   
   
   
   
   
   


6.3。


   
   
   例如，假设
   
   
   请求。
   
   
   
   
   
   
   
   


   
   
   
   这个
   
   
   
   
   
   位置。
















   
   
   


6.4。


   
   例如，一个
   
   
   
   
   
   
   
   
   
   
   


   
   
   
   这个
   
   
   
   
   
   
   第一名。
   
   在这
   
   
   
   
   






   
   


8.参考


8.1。规范性引用文件




















           
           
           




           




           
           




           




           
           




           
           




           
           




           
           




           
           
           


8.2。




           
           
           
           




           




















           




           
           








           
           2002年9月。




           
           
           




           
           


9.作者地址


   
   
   麻省理工学院
   
   马萨诸塞州剑桥02139
   
   
   




   
   
   
   
   
   


   
   
   
   
   
   
   
























   版权所有。


   
   其他人，中方对此有何评论或以其他方式解释衍生作品
   或在其实施协助可制备，复制，出版
   和分布，在全部或部分，没有任何限制地
   
   包含在所有的拷贝和派生作品。但是，此
   文档本身可以不以任何方式被修饰，例如通过除去
   版权声明或引用互联网协会或其他
   
   开发Internet标准在这种情况下的程序
   
   其次，或根据客户要求把它翻译成比其他语言
   英语。


   上述有限许可是永久性的，不会
   


   本文档及其包含的信息提供上
   “原样”基础上，互联网协会和互联网工程
   IETF拒绝所有明示或默示的担保，包括
   
   在本文中将不侵犯任何权利或任何暗示的保证
   适销性或适用于特定用途。