ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [转载]恢复透明的网络,第 2 部分

[转载]恢复透明的网络,第 2 部分

原创 Linux操作系统 作者:dinner1007 时间:2019-06-19 22:33:05 0 删除 编辑

恢复透明的网络,第 2 部分


本文为“ Restoring the transparent network”的续篇,Todd Sundsted 在本文中主要讲述了 Java 应用程序在遇到许多常见类型的网络障碍时可以用来恢复网络透明性的面貌的技术。本文所提供的框架可以被 Java 应用程序用来使应用程序的更高级部分看不见网络障碍。

无论您是美国公司的雇员还是在运行家庭网络,您很可能非常熟悉端到端因特网透明性的两个最大障碍:NAT 设备(这种技术在微软的世界中被称为“因特网连接共享”)和防火墙。这些设备流行的原因是它们为家庭用户和网络管理员提高了安全性并简化了连接性和网络管 理。不幸的是,它们给在 P2P、移动代理和网格计算空间中的细粒度分布式应用程序带来问题,因为这些应用程序必须跨越这些设备所定义的网络边界。

在这个系列的 第 1 部分中, 您了解了网络透明性的常见障碍分为两类:单向玻璃墙(通常由类似 NAT 机器的设备来创建)和黑洞或盲点(通常由防火墙来创建)。单向玻璃墙阻止位于墙的一侧(外侧)的实体与另一侧的实体开始通信会话。但是,一旦会话被建立, 消息就可以双向流动。黑洞和盲点的约束更多。防火墙过滤规则可以根据源 IP 地址或目的地 IP 地址和端口来阻拦进站流量和出站流量,实际上为防火墙的每一侧的实体创建了网络黑洞。

与之类似的障碍破坏了完全透明的网络的两个重要特征:单一的统一寻址模式,它可以用来标识每个网络实体;完全透明的通信,它允许一个网络实体在只知道另一个实体的地址的情况下与它开始直接通信。

进行修补

在应用层,直接修补在网络层和传输层引入的障碍对网络透明性造成的破坏是不可能的。但是,我们可以构建能有效地使更高级的应用层看不见这些障碍的应用软件基础结构层。事实上,我们可以定义并构建许多不同种类的分布式应用程序可以插入并利用的基础结构。

图 1 是这样的应用程序的高级的概念示意图。这个图说明的是一个由一个或更多个目录和一个或更多个目录客户机组成的松散耦合的分布式应用程序。我有意创建相同数量的目录和目录客户机,以强调一个实体可以同时扮演两个角色,您应该看到这一点。


图 1. 高级的概念网络
高级的概念网络

在这个模型中,客户机表示分布式应用程序的构件。它们实现应用程序的特征功能 ― 如果应用程序是分布式消息传递应用程序,那么它的特征功能包括管理有关用户的信息(例如首选项)和处理警告和其它消息传递事件。这些目录是作为解决透明性问题的基础结构的一部分独立存在的。

类似前面描述的网络障碍使得我们无法实现绝对的、统一的标识模式。一个客户机无法用单个静态指定(例如 URL)来可靠地表示另一个客户机的位置。在没有可靠的标识方式的情况下是无法进行通信的。

目录可以跟踪客户机。它们也有助于客户机绕过分隔客户机的网络障碍。目录存储着有关客户机相对于目录的位置的信息。它还存储着它与客户机间的网络障碍的性 质和在一般情况下客户机周围的障碍的有关信息。目录可以用目录与客户机间的通信链路来推测这些信息中的一部分。例如,目录可以比较客户机所认为的它自己的 IP 地址与位于套接字连接的另一端的 IP 地址。如果两者不匹配,那么它们之间可能有 NAT 设备。




回页首


示例:NAT 设备

图 2 说明了 NAT 设备对设备寻址的影响。这个图描绘了一个客户机和两个目录。某个客户机和一个目录运行在内部网环境中,这个环境中有一个提供对更大的网络(可能是因特网, 但不一定是)的访问的 NAT 设备。另一个目录运行在 NAT 设备的另一侧。IP 地址被用来标记每个组件。NAT 设备有两个:表示外部网络的 IP 地址和表示内部网络的 IP 地址。每个目录看到的客户机的情况是不同的。内部目录可以看到客户机的真实 IP 地址并可以直接联系客户机。外部目录可以看到 NAT 设备的 IP 地址,但是看不到客户机的 IP 地址。此外,除非通过配置 NAT 设备使它把入站连接转发给客户机,外部目录无法直接联系客户机。


图 2. NAT 设备障碍
NAT 设备障碍

因为目录处于特权位置且在解决它们所服务的客户机的寻址问题和通信问题中扮演着主要角色,所以目录非常适合于管理有关客户机的更多信息。目录可以跟踪有关客户机的更多信息,例如客户机上存储的内容或客户机提供的资源和服务。但是,这种配角与当前的讨论无关。

在接下来的部分中,我们将分析基础结构设计的粗粒度的类图。(在 参考资料部分中有基础结构的源代码。)然后,我们将考虑高级的应用层在与这个基础结构交互时看到的 API。最后,我们将分析涉及客户机和目录的几种情况和它们之间发生在幕后的交互。




回页首


设计

类似前面描述的网络障碍是各种细粒度分布式应用程序遇到问题的主要根源。在这部分中,我们将讨论如何解决基于 Java 的分布式应用程序所遇到的问题。

图 3 中的设计以两个核心类为基础: Directory 类和 Client 类。目录服务实例化 Directory 类并与 Directory 类的实例交互。客户机实例化 Client 类并与 Client 类的实例交互。在许多应用程序中,分布式组件使用这两个类并且既作为目录也作为客户机。


图 3. 基础结构的类图
基础结构的类图

Directory 类和 Client 类都使用 MessageManager 类。 MessageManager 类管理入站和出站消息队列,提供把消息放入出站队列的方法和把消息从入站队列中取出的方法。

MessageManager 类为它的客户机提供了完全异步的接口。一个或多个线程可以使用这个类的实例与通信通道的另一端的实例通信并且可以同时发送和接收消息。 MessageManager 类具体负责消息的多路复用和多路分用。

对于每个与 Directory 实例之间存在有效的、打开的连接的客户机,Directory 实例在它的数据库中维护着一个记录。连接的客户机可以请求这些记录的列表,也可以请求由其中一个记录所表示的某个 Client 实例的连接信息。 Directory 实例理解它与每个 Client 实例的关系并存储着可能影响客户机通信自由的网络障碍的有关信息。 Directory 实例使用这些信息来指导一个客户机如何以最佳方式来联系另一个 Client 。

根据 Directory 实例所了解的它与两个 Client 实例间的网络的知识,Directory 实例可以告诉第一个 Client 实例直接与第二个 Client 实例连接。Directory 实例也可以告诉第一个 Client 实例在指定的端口期待来自第二个 Client 实例的入站连接(也被称为 连接)。第一个 Client 应该立即开始在这个端口上侦听连接。这个侦听服务由 Listener 类来提供。

客户机并不直接使用 MessageManager 类和 Listener 类。相反,客户机通过 ClientDirectoryInterface 类与目录交互并请求与其它客户机连接。这个类的方法驱动着由 MessageManager 类与关联的类所组成的机器。表 1 列出了 ClientDirectoryInterface 类的重要方法并描述了它们的用途。

表 1. ClientDirectoryInterface

方法 描述
void hello() 在关联的目录中注册
Iterator list() 列出与目录连接的客户机
ClientClientInterface connect(Identifier) 与指定的客户机连接

客户机通过 ClientClientInterface 与其它客户机交互。表 2 列出了 ClientClientInterface 类的重要方法并描述了它们的用途。

表 2. ClientClientInterface

方法 描述
void link(String) 注册与关联客户机的被推连接
String identify() 返回客户机的身份

在典型的情况下,客户机用先前与目录建立的连接来实例化 ClientDirectoryInterface 类。这个框架并不对这个连接是如何的产生的作任何假设。这个连接可能来自对另一个目录的请求。 ClientDirectoryInterface 实例负责在目录中注册客户机。它还创建并启动必需的后端机器。 ClientDirectoryInterface 实例被创建后,客户机可以请求关联的目录所知道的其它客户机的列表。返回的列表为不透明的身份的列表的 Iterator 。身份是不透明的,因为客户机无法使用它们来推断另一个客户机的实际位置(IP 地址和端口)。

在给出其中一个不透明的身份后,客户机可以请求与这个身份所表示的客户机连接。在幕后,通过使用目录提供的信息, ClientDirectoryInterface 实例或者直接连接另一个客户机,或者要求目录来要求目标客户机把连接推回至请求的客户机。从请求的客户机的角度来看,这个方法的调用返回一对输出流和输入流。这就是返回给客户机的一切。




回页首


常见情况

我们以能检测前面描述的 NAT 设备是否存在的目录为例,讲述这个基础结构在常见的情况下是如何工作的。

没有障碍

在第一种情况下(如图 4 所示),所有的网络实体位于同一个局部透明的网络。在这种情况下,所有的实体可以直接与其它实体建立连接。


图 4. 第一种情况
第一种情况

一个受阻的客户机

在第二种情况下(如图 5 所示),目录和一个客户机位于同一个局部透明的网络中,另一个客户机位于网络障碍的后面,网络障碍使这个客户机无法接收到建立网络连接的入站尝试。但是,这个客户机建立网络连接的出站能力没有受到破坏。


图 5. 第二种情况
第二种情况

如前所述,通过分析障碍后的客户机的请求 IP 地址和实际 IP 地址,目录可以推断网络障碍的存在并引导这个客户机在这两个客户机间的所有对话中打开连接,无论哪个客户机想开始对话。

两个受阻的客户机

在第三种情况下(如图 6 所示),目录位于网络的透明部分,两个客户机都在不同的障碍后面。任一个客户机都不能与另一个客户机直接建立连接,但是这两个客户机都可以与目录建立连接。


图 6. 第三种情况
第三种情况

为了使这两个客户机通信,它们必须都打开与目录的连接且目录必须支持这两个客户机间的通信。至少从客户机的角度来看,前面描述的框架使这种情况与其它情况没有区别。提供的代码不处理这种情况。

两个受阻的客户机,第二个版本

在最后一种情况下(如图 7 所示),目录位于网络的透明部分,两个客户机在相同的障碍后面。如果它们都通过相同的 NAT 设备与目录通信,那么它们似乎有相同的 IP 地址。目录可以指示客户机直接与对方连接。


图 7. 第四种情况
第四种情况



回页首


结束语

参考资料部分中有框架源代码的链接,还有两个可运行的 JAR 文件(一个是目录,另一个是客户机)的链接。 如果您从命令行启动包含在 JAR 文件中的应用程序(不加参数),这些应用程序将说明它们的命令行选项。

如果本文中描述的框架正常运行,细粒度分布式 Java 应用程序可以完成它们的任务且在运行时许多常见类型的网络障碍似乎并不存在。这里提供的框架能解决 NAT 设备。您可以容易地扩大它的适用范围,使其它设备(例如防火墙)也能利用这个框架。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/374079/viewspace-130740/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-08-23

  • 博文量
    1714
  • 访问量
    1290845