级别： 初级 Todd E.Sundsted (todd-p2p@etcee.com), 副总裁, Facts and Figures, Etcee LLC
2002 年 10 月 02 日 分布式应用程序得益于网络透明性。遗憾的是，许多常见的网络设备（如防火墙和 NAT 网关）破坏了网络透明性，通常是在对创新的分布式应用程序而言潜力最大的地方 ― 网络边缘造成了破坏。在本文中，经验丰富的 Java 程序员 Todd Sundsted 解释了这些设备是如何损害网络透明性的，然后为解决方案奠定了基础。
极细颗粒度的分布式应用程序领域包括对等（P2P）、移动代理和网格计算应用程序，这些技术仍然充满了活力、日趋成熟并且不断地发展着。这个领域的应用程序在很多方面都存在着差异，但它们有一个共同的特征：他们都利用网络边缘可用的处理能力和存储器。
成功的分布式应用程序体系结构的一个通常未明确说明而又基本的假定是：当构成应用程序的组件可以彼此自由地通信时，这些体系结构工作得最好。这意味着
任何组件都可以任意建立与其它组件的会话。网络（组件通信的媒介）是一团透明的云，它不知道也不关心通信的内容和目的。
遗憾的是，事实与这种假定并不符合。大多数大型网络（尤其是因特网）实际上是由各自独立控制和管理的较小的网络组成的，它们通过防火墙、网关、代理以及类似的设备彼此连接。这些设备拼命破坏网络透明性，通常是在对创新的分布式应用程序而言潜力最大的地方 ― 网络边缘造成了破坏。
端对端论点
1981 年，Jerry Saltzer、David Reed 和 Dave Clark 发表了一篇文章，提出一个称为
端对端论点的网络设计原则。端对端论点强调将尽可能多的功能放在通信系统的端点上。
他们主张：最好在通信系统的端点上，而不是系统中间的设备上处理类似安全性、抑制重复消息和从系统故障中恢复这样的功能，因为这些功能仅能在端点上得到完全实现。在中间设备中构建对这些功能的支持可能会增强性能，但它迫使不需要这些功能的应用程序为支持它们而付出代价。随着时间的推移，为了支持过去的应用程序而构建到网络中的优化与现在的应用程序的关联变得越来越少。
现代因特网的成功充分说明了这一原则的价值。如果强制我们今天使用的应用程序在为哑终端和大型机（过去的典型应用程序）通信而优化的网络上运行，它的性能将减弱。
端对端论点与网络透明性有关。它为思考网络和使用网络的应用程序之间关系的方式创造了条件。
相关案例：WAP 技术
要找到忽视端对端论点的设计示例并不难。如果您希望看到当忽视端对端论点时会发生什么，只要看 WAP（无线应用协议（Wireless Application Protocol））就行了。
WAP 是无线设备技术家族中最著名的成员，这个家族还包括 WML（无线标记语言（Wireless Markup Language））、WCSS（无线级联样式表（Wireless Cascading Style Sheets））、WDL（无线数据报协议（Wireless Datagram Protocol））、WCMP（无线控制消息协议（Wireless Control Message Protocol））、WTLS（无线传输层安全性（Wireless Transport Layer Security））以及其它几种协议。
由于多种原因，包括设备资源和网络带宽限制，当开发移动设备的通信基础结构时，WAP Forum 摒弃了诸如 HTTP、HTML 和 SSL（安全套接字层（Secure Sockets Layer）) 这样的现有标准。他们没有遵循业界原有的标准，而是自行开发了与原有标准集几乎平行但不可互操作的标准集。
当访问无线供应商网络上的内容和服务以及访问因特网上支持 WAP 的服务器时，支持 WAP 的设备（如移动电话）自然地使用 WAP。当这些设备需要访问不支持 WAP 的服务器时，它们通过 WAP 网关进行访问。WAP 网关将 WAP/WML 数据转换成更常见的 HTTP/HTML 形式，或反向进行转换。除非系统要求很高的端对端安全性，否则这种方法就有效。
支持 WAP 的设备使用 WTLS 而不是 SSL。当支持 WAP 的设备需要与用 SSL 保护的站点（例如，您的在线银行）通信时，它必须通过 WAP 网关进行交互。WAP 网关解密 WTLS 数据并在传送之前将它重新加密为 SSL。这种方案有效地防止了支持 WAP 的设备不经过 WAP 网关就直接（同时也是安全地）与不支持 WAP 的设备通信。
一大堆障碍
因特网是网络的网络。在网络级别，数据通过许多中间设备在应用程序之间传递。尽管网络透明性意味着这些中间设备不会干扰应用程序之间的信息流，但许多设备并不那么理想。让我们研究一下干扰透明信息流的部分流行技术。
防火墙
防火墙将一个网络分隔成以防火墙为界的两个网络。任何从一个网络传递到另一个网络的信息都必须通过防火墙。防火墙所处的关键性位置允许它监视和控制网络间的流量。防火墙是安全网络不可或缺的部分。以下是几种防火墙。
最简单的一种防火墙在网络层过滤信息。这种类型的过滤称为
包过滤，因为它从通过防火墙的包流中除去与某种标准匹配的包。删除是根据寻址信息（包的源地址和目的地址）或协议类型（IP、IPX 等）进行的。包过滤防火墙的主要缺点是它们不检查通过防火墙的包的内容。
应用程序网关（也称为
应用程序代理或
应用程序级代理）比包过滤防火墙更复杂。应用程序网关担任驻留在防火墙后面的应用程序的代理。首先应用程序建立一个与应用程序网关的连接，然后，应用程序网关建立到应用程序的最终目的地的连接。接着，应用程序和目的地之间的流量从网关流过。应用程序级网关理解数据并能根据数据进行过滤决策。
还有其它类型的防火墙，但它们由相同的目标所支配：控制在两个网络之间传递的信息流。
网络地址转换
最近几年
网络地址转换（Network Address Translation）（NAT）变得很流行。NAT 允许多台机器使用唯一 IP 地址访问因特网。通常，从为内部网保留的地址块中为 NAT 网关后面的机器分配一个 IP 地址。NAT 网关是该网络中唯一拥有因特网可访问 IP 地址的机器。NAT 网关透明地重写来自内部网上机器的包，这样对于外部主机来说，它们就象是来自 NAT 网关本身。NAT 网关重写返回的包，以便它们流回到内部网上适当的机器。对于因特网上其它设备而言，只有一台主机和一个 IP 地址，并且所有的流量看起来都是来自这台机器的。
NAT 很流行，因为它为网络管理员提供两个重要的优点：方便和安全性。因为内部网使用的 IP 地址都来自于一个保留的子网，所以管理员可以在他们的网络中添加和删除机器而不会与其它组织使用的 IP 地址冲突，也不必从外部实体申请新的 IP 地址。此外，NAT 网关通过对因特网隐藏内部 IP 地址和内部机器来担任某种类型的防火墙。仅当向某个外部地址发送过出站包时，NAT 才允许来自该地址的流量入站。
遗憾的是，从应用程序开发的立场来看，后一个特性是令人讨厌的。NAT 网关后面的应用程序可以任意与外部应用程序联系，但外部应用程序却不能同样方便地与 NAT 网关后面的应用程序联系。还有，不同 NAT 网关后面的应用程序之间彼此不能直接联系。
其它障碍
还有许多其它障碍，但它们对分布式应用程序的影响往往相对较小，如 WAP（前面提到过）。WAP 正面临着极大的压力，要求与更常用的协议互操作得更好，因此将来对 WAP 的争议有可能越来越少。
透明高速缓存（很有讽刺意味）也威胁着网络透明性。透明高速缓存截取向远程目的地发送的请求，并透明地使用本地高速缓存的数据为这些请求服务。它们根据这条原理进行操作 ― 某些类型的数据（如静态网页）的更改并不频繁，所以本地副本几乎和实际数据一样好。尽管如此，实际上对于分布式应用程序而言，透明高速缓存并不是问题。
将多台服务器隐藏在同一 IP 地址后面的负载均衡设备也干扰了网络透明性，不过它们对分布式应用程序的影响也是有限的。
网络障碍的概念模型
尽管有许多实际障碍影响着网络透明性，但可以将它们中的大部分抽象成一组类似的案例。每种案例都以特定的方式妨碍透明性并影响应用程序。
让我们从研究图 1 中所示的理想的、完全透明的网络开始。我将以此作为研究我们必须绕开的网络障碍的起点。
图 1. 透明网络
理想情况下，分布式应用程序组件之间的网络就象玻璃：完全透明。端对端论点提出理想的网络必须表现出两个特征：单一通用的寻址方案和开放的通信。
单一、通用的寻址方案意味着应用程序组件可以明确地标识网络上的其它应用程序组件。开放的通信意味着应用程序可以与网络上它知道其地址的任何其它应用程序连接并开始会话。前面描述的障碍削弱这两个特征中的一个或全部。
流的方向
NAT 网关和某些种类的防火墙创建了孤岛（也称为
内部网），在孤岛中只能从出站方向开始通信。意外的入站连接被拒绝。这些产品创建了一堵单向玻璃的墙，如图 2 所示。内部的应用程序可以看到外面，但外部的应用程序不能看到里面。
图 2. 单向玻璃
在 NAT 的案例中，NAT 网关注意到创建了到目的地的出站 TCP 连接，然后就允许来自和发向该目的地的入站和出站流量双向通过，如图 3 所示。并非来自该原始目的地的入站流量则被丢弃（有些 NAT 网关允许将包转发到内部网中的特定主机）。当应用程序组件位于不同 NAT 网关后面时，会产生其它问题。
图 3. 两面玻璃
两个 NAT 网关的存在阻止了两边的应用程序与对方建立连接。
黑洞和盲点
许多防火墙根据流量的端口、源地址或目的地地址过滤流量。公司、政府和教育机构常用这种类型的过滤来限制将其网络和带宽用于不受支持的活动。
这种类型的过滤创建了网络黑洞和盲点：可以向这些地方发送流量，但来自这些地方的流量永远也不返回。
解决方案需求
如果除去先前描述的障碍就好了。遗憾的是，我认为这永远不会发生。公共基础结构和生产力应用程序中糟糕的安全性状态以及访问公司网络的方式的细颗粒度控制的渴望，都强制规定了对许多此类网络障碍的需求。但是，成功的设计会让应用程序以对开发人员透明的方式绕开这些障碍。
首先要牺牲单一、通用寻址方案的观念。如果您回忆一下，NAT 以及相关技术的一个副作用就是一个 IP 地址不再唯一地和统一地标识网络上的一个应用程序组件。我们需要更好的寻址方案，一个接受大型网络实际上是较小网络的集合这一事实的方案。它必须要求资源标识符包含关于网络结构的足够信息，以便允许应用程序组件彼此可靠地进行标识。
其次要牺牲开放的通信。由 NAT 创建的单向玻璃和由防火墙创建的盲点和黑洞阻止了应用程序组件建立与其它应用程序组件的连接。我们需要使应用程序更容易绕开此类问题的基础结构。不能直接通信的应用程序组件必须依靠中间组件来架设越过沟壑的桥梁。
当组成分布式应用程序的组件可以开放地进行通信时，分布式应用程序得益于透明网络并工作得最好。遗憾的是，因特网的许多部分并不透明。在本系列的第 2 部分中，我将演示恢复透明网络的方法。
参考资料
关于作者  | | | Todd Sundsted 自从台式计算机首次出现以来就一直在编写软件。他对安全性、分布式计算和极细颗粒度分布式系统中的动态行为以及突发的行为感兴趣。除了写作以外，Todd 还做一些编码工作。可通过
todd-p2p@etcee.com与 Todd 联系。
|
对本文的评价
| 
