P2P communication across middleboxes

P2P communication across middleboxes

作者： hxhbluestar翻译 | 日期： 2004-12-16 | 已阅： 1941次

原文版权：Copyright (C) The Internet Society (2003).All Rights Reserved.

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

<script type="text/javascript"> <!-- google_ad_client = "pub-7197438303445134"; google_ad_width = 300; google_ad_height = 250; google_ad_format = "300x250_as"; google_ad_channel ="2769598146"; google_color_border = "336699"; google_color_bg = "FFFFFF"; google_color_link = "0000FF"; google_color_url = "008000"; google_color_text = "000000"; //--> </script><script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> </script>

译文版权申明：请引用此文的作者或网站注明出处：http://blog.csdn.net/hxhbluestar，以尊重译者的劳动成果！

    随着IPv6时代的到来，我也一直怀疑，是不是还有必要再去学习NAT技术——因为网络的资源不再如IPv4时代匮乏，而NAT技术正是为解决IP地址的紧缺而存在的，如此，NAT便没有存在的必要了。

但是，随着这篇文章的翻译，我的怀疑慢慢变成庆幸，渐而又变为肯定，通过翻译所学到的东西，不再仅仅是翻译第一手资料带来的成就感，更多的是通过翻译，去领悟技术前辈们的智慧与经验，也通过翻译，养成自己从第一手资料获得信息的习惯，从而将视野放得更宽，让理解更为透彻——至少，很多东西都是要经过仔细斟酌才真正转化为自己思想的一部分的。正是如此，我才坚定的要把这篇文章翻译完，也如之前所提到的，如果时间允许的话，我会用C#来写一些例子，让大家更好的理解NAT技术，掌握NAT技术（主要涉及到即时通讯、文件对等传输和语音应用三个方面）。

这篇文章主要是介绍一下“代理”机制的起因以及给P2P应用带来的不便，不需要任何基础知识：）

1. Introduction

1、简介

 

关键词：

middleboxe(s) —— 我翻译成“代理”，也许有更好的翻译

host             —— 我翻译成“主机”，希望大家不要理解成服务器了，主机就是一台普通的终端机

在当今的Internet中，普遍存在使用“代理”设备来进行网络地址转换（NAT），导致这种现象的原因是 IPV4 地址空间的资源耗尽危机。虽然不对称 asymmetric 的地址分配和连通性制度已经在代理中被定义，但是却给端对端应用程序和协议制定造成了一些特殊的问题。像电话会议和多媒体网络游戏。这些问题即使在IPV6世界中还是会存在，因为NAT作为IPV4的一种兼容性机制经常被使用[NAT-PT]，并且防火墙将仍然将普遍存在，即使不再需要NAT技术。

当前使用的“代理”技术主要是为 客户端/服务端 C/S 结构设计的，为了实现那些需要连接但是又没有固定IP地址的客户端能够连接到一台配置好的拥有固定IP和DNS域名的服务器。
    大多数的“代理”使用一种 asymmetric 通信模型，即 私网（局域网） 的主机能发起一个“外出”连接去连接公网上的主机。 但是公网上的主机却无法发送信息给私网上的主机（除非对“代理”进行特殊的配置），NAPT（网络地址端口转换）的普通情况是，一个私网客户端不需要一个公网的固定的IP地址，但是必须要共享一个由NAPT控制的公网的固定IP地址（当然这个NAPT是处于同一个私网内部的）。这样的话，这些匿名的并且看起来难以触及的藏在NAT之后的内网主机对于像 Web浏览器 这种软件来说就不是一个问题,因为内网的主机只需要发起向外部的连接就可以了。这样一来，无法触及也还是有他的优点的——那就是具有保密性。

然而，在P2P的应用中，Internet上的“客户机”之间是需要建立一个通信会话直连的。邀请者和响应者也许会处于不同的NAT之后，也许他们都没有固定IP或者即使有也不是公网的IP地址。举例来说，在一个普通的网络游戏体系结构中，都是通过客户端向一个具有公网固定IP的服务器发起申请进行初始化并通过验证的。同时，客户端之间也要建立直连，才使网络间传输的速度加快，保证数据即时更新（不然抢不到装备啊，呵呵）。

同样的，一个文件共享应用程序也必须通过到一个服务器上去查找它想要的资源，然后再到拥有这个数据的主机上去下载（BT网站，走了一个中介），“代理”造成了很多P2P直连的问题，因为藏在“代理”之后的的主机通常没有固定的端口来使其他的客户端发起的TCP或UDP连接能够最终到达。

RFC 3235[NAT-APPL] 简要的提到了这个问题，但是没有给出任何的解决方案。

 在这篇文章中，我们用两种方式讨论 P2P/代理 的问题。首先，概要的讲叙已有的P2P应用程序能够在现有的代理机制中的工作原理。然后，我们提供一组应用程序设计指南，基于已有的实践，在现有的配置好的代理上，来使得P2P应用程序操作更加有条理。最后，我们提供了设计指南，为以后的代理机制能够更方便支持P2P应用程序。讨论的焦点是如何 直接的、广泛的 配置那些需要经过“代理”的P2P应用程序。

P2P communication across middleboxes（术语篇） 作者： hxhbluestar翻译 | 日期： 2004-12-16 | 已阅： 2066次 2. Terminology 2. 术语 在这一章节中，首先概要的介绍一下“代理”技术的一些术语。然后集中讨论两种造成P2P应用问题的代理机制。   防火墙 防火墙限制了私网与公网的通信，它主要是将（防火墙）认为未经授权的的包丢弃，防火墙只是检验包的数据，并不修改数据包中的IP地址和TCP/UDP端口信息。   网络地址转换（NAT） 当有数据包通过时，网络地址转换器不仅检查包的信息，还要将包头中的IP地址和端口信息进行修改。以使得处于NAT之后的机器共享几个仅有的公网IP地址（通常是一个）。网络地址转换器主要有两种类型：   基础NAT 基础NAT 将私网主机的私有IP地址转换成公网IP地址，但并不将TCP/UDP端口信息进行转换。基础NAT一般用在当NAT拥有很多公网IP地址的时候，它将公网IP地址与内部主机进行绑定，使得外部可以用公网IP地址访问内部主机。（译者注：实际上是只将IP转换，192.168.0.23 <-> 210.42.106.35,这与直接设置IP地址为公网IP还是有一定区别的，特别是对于企业来说，外部的信息都要经过统一防火墙才能到达内部，但是内部主机又可以使用公网IP）   网络地址和端口转换 （NAPT） 这是最普遍的情况，网络地址/端口转换器检查、修改包的IP地址和TCP/UDP端口信息，这样，更多的内部主机就可以同时使用一个公网IP地址。 请参考[NAT-TRAD]和[NAT-TERM]两个文档了解更多的NAT分类和术语信息。另外，关于NAPT的分类和术语，[STUN]在最近做了更多的定义。当一个内部网主机通过NAT打开一个“外出”的TCP或UDP会话时，NAPT分配给这个会话一个公网IP和端口，用来接收外网的响应的数据包，并经过转换通知内部网的主机。这样做的效果是，NAPT在 [私有IP:私有端口] 和[公网IP:公网端口]之间建立了一个端口绑定。 端口绑定指定了NAPT将在这个会话的生存期内进行地址转换任务。这中间存在一个这样的问题，如果P2P应用程序从内部网络的一个[私有IP地址:端口]对同时发出多条会话给不同的外网主机，那么NAT会怎样处理呢？请看以下几种方案。   锥形NAT （译者注：为什么叫做锥形呢？请看以下图形,终端和外部服务器，都通过NAT分派的这个绑定地址对来传送信息，就象一个漏斗一样，筛选并传递信息）     当建立了一个 [私有IP:端口]-[公网IP:端口] 端口绑定之后，对于来自同一个[私有IP:端口]会话，锥形NAT服务器允许发起会话的应用程序 重复使用这个端口绑定，一直到这个会话结束才解除（端口绑定）。     例如，假设 Client A（IP地址信息如上图所示）通过一个 锥形NAT 同时发起两个外出的连接，它使用同一个内部端口（10.0.0.1:1234）给公网的两台不同的服务器，S1和S2。锥形NAT 只分配一个公网IP和端口（155.99.25.11:62000）给这个两个会话，通过地址转换可以 确保 Client使用端口的“同一性”（译者注：即这个Client只使用这个端口）。而基础NATs和防火墙却不能修改经过的数据包端口号，它们可以看作是锥形NAT的精简版本。           对称NAT 对称NAT，与Cone NAT是大不相同的，并不对会话进行端口绑定，而是分配一个全新的 公网端口 给每一个新的会话。 还是上面那个例子：如果 Client A (10.0.0.1:1234)同时发起两个 "外出" 会话,分别发往S1和S2。对称Nat会分配公共地址155.99.25.11:62000给Session1，然后分配另一个不同的公共地址155.99.25.11:62001给Session2。对称Nat能够区别两个不同的会话并进行地址转换，因为在 Session1 和 Session2中的外部地址是不同的，正是因为这样，Client端的应用程序就迷失在这个地址转换边界线了，因为这个应用程序每发出一个会话都会使用一个新的端口，无法保障只使用同一个端口了。 在TCP和UDP通信中， （到底是使用同一个端口，还是分配不同的端口给同一个应用程序），锥形NAT和对称NAT各有各的理由。当然锥形NAT在根据如何公平地将NAT接受的连接直达一个已创建的地址对上有更多的分类。这个分类一般应用在Udp通信（而不是Tcp通信上），因为NATs和防火墙阻止了试图无条件传入的TCP连接，除非明确设置NAT不这样做。这些分类如下：   全双工锥形NAT 当内部主机发出一个“外出”的连接会话，就会创建了一个 公网/私网 地址，一旦这个地址对被创建，全双工锥形NAT会接收随后任何外部端口传入这个公共端口地址的通信。因此，全双工锥形NAT有时候又被称为"混杂"NAT。   受限制的锥形NAT 受限制的锥形NAT会对传入的数据包进行筛选，当内部主机发出“外出”的会话时，NAT会记录这个外部主机的IP地址信息，所以，也只有这些有记录的外部IP地址，能够将信息传入到NAT内部，受限制的锥形NAT 有效的给防火墙提炼了筛选包的原则——即限定只给那些已知的外部地址“传入”信息到NAT内部。   端口受限制的Cone NAT 端口受限制的锥形NAT，与受限制的锥形NAT不同的是：它同时记录了外部主机的IP地址和端口信息，端口受限制的锥形NAT给内部节点提供了同一级别的保护，在维持端口“同一性”过程中，将会丢弃对称NAT传回的信息。   最后，在这篇文档里我们将定义一组新的术语 ，以便更好的对P2P代理相关的行为进行分类。   P2P应用程序 P2P应用程序是指，在已有的一个公共服务器的基础上，并分别利用自己的私有地址或者公有地址（或者两者兼备）来建立一个端到端的会话通信。 P2P代理 P2P代理是一个允许 P2P应用程序进行通信的代理机制   P2P防火墙 P2P防火墙是一个提供了防火墙的功能的P2P代理，但是不进行地址转换. P2P-NAT P2P-NAT 是一个 P2P代理,提供了NAT的功能,也提供了防火墙的功能,一个最简的P2P代理必须具有 锥形NAT对Udp通信支持的功能,并允许应用程序利用Udp打洞技术建立强健的P2P连接。   回环转换 当NAT的私网内部机器想通过公共地址来访问同一台局域网内的机器的时，NAT设备等价于做了两次NAT的事情，在包到达目标机器之前，先将私有地址转换为公网地址，然后再将公网地址转换回私有地址。我们把具有上叙转换功能的NAT设备叫做“回环转换”设备。