4.3.3　优化好的数据流像什么

在探讨WAN优化工作方式时我们已经隐含提到，经过优化处理后的数据流与原始数据流有一定差别，数据本身内容是肯定有差异的，但是包头又会发生什么变化呢？如4.3.2节中介绍的一样，一些优化器会使用隧道机制，而另外一些优化器会保留TCP连接以便它们能够匹配上预先定义好的包头。隧道可以实现在一条隧道中单点连接多个混合流操作，相反，TCP代理体系为每一个LAN连接维持一个基于WAN的TCP连接。当涉及加密以及在网络中实现包寻址操作也叫网络可视化等操作时，每种方法都有自己的优点，也有各自的不足。我们将对这些内容进行简单说明，探讨各种WAN优化器可以采用的寻址规则。要注意：许多WAN优化器支持多种可视化模式以及不同的终端，因此这是一个会让人产生困惑的领域。我们将在下节研究网络可视化操作问题，图4-7给出了一个简单的引导说明。前三种技术针对的是流行的TCP代理体系，紧跟着的是隧道机制。LAN传输在大多数环境中都不会发生变化，但是我们也会讨论某些例外。最后讨论软件究竟是安装在客户端还是安装在虚拟服务器环境中，这个问题没有统一答案，每种方法都有不同的取舍要考虑，我们将介绍虚拟模式，并简单探讨一下此方案的利弊。

网络透明寻址

某些网络可视化技术是为了保证包头不发生变化，也就是俗称的“透明”，在这种模式中，四部分（IP源地址、源端口、IP目标地址、目标端口）能够匹配上原始连接，此方法的最大优势在于它保留了WAN优化端拦截或控制设备的相似性。例如，在连接透明时，路由器的QoS实现不需要修改就可以使用IP地址和端口来区分不同的传输，类似地广播标准比如顶层会话或跟踪各部门退单，也不需要更改。这种模式最大的危险为包头有可能携带错误信息，IP网络的根本目的是根据包的不同地址将它们发往各自目的地，如果假设优化后的内容对终端主机毫无意义，透明发布就不应该支持这样的传输。通常终端连接的一致性是通过序列编号验证维护的，它有点像守门员。任何错误譬如未识别的异步路由，将导致终端用户会话被错误重置，维护人员却很难跟踪用户的这个抱怨而产生。在大多数情况下，WAN能够意识并报告异步操作，但是这种部署方法就像一把锐利的刀——有用但存在潜在风险。

图　4-7　不同网络可视模式的包结构

端口透明和透明隧道

由于透明模式的风险，一些厂商开发了半透明模式产品，以保存部分四重端点的优势，但又不完全一样。

首先要完成IP地址与WAN优化器的匹配工作，除了端口与终端的匹配，这样的端口透明还支持包能够匹配一些规则，包括：QoS规则、大部分防火墙规则以及一些统计系统（尽管不是大多数）的规则，同时保留了包应被发送至它们所标签的地址这一性质。这一做法避免了异步或其他传输意外而产生的重置操作，减轻了部署的风险。但是这一方案仍然没有完全解决像顶层会话发布、指定IP的内部防火墙等这样一些控制问题，这些问题都与包有关。

另一解决方案是当在包头中保留端点IP地址时，改变端口个数（或者变成一个），此方法同样能够降低错误传送的概率（尽管有时候有可能匹配会出错，但出错概率很低）。如果服务器端口被保留下来，那么大多说WAN系统都能正常工作，包括基于IP端口的QoS、网络使用报告和防火墙，也不需要为优化环境改变什么。这类方法（某种程度上有些混乱）被某个厂商称为透明隧道。它的不利之处仍然是不应该根据IP头来决定包的发送地址，因为有时候目标客户/服务器无法识别这些信息。

说明：终端的WAN优化没有约定的术语表示，像in-path、inpath以及inline都可以互换使用，不同的厂商可能会使用像正确地址和隧道来表示同样的概念以及类似信息。使用者自己要注意。

优化器寻址

最直白的设计是利用WAN传输的头包来取得产生这一信息的设备地址。此时，WAN优化器将确定上述四项主要内容。优化器寻址方法的优点很多，首先也是最重要的，只要发送包是正确的，路由基础设施将永远执行正确的操作。此外，这种方式也为中间交换系统（如报文、QoS等）区别对待优化数据流与普通数据流创造了机会。不利之处在于需要对现有交换系统进行一些改造或移植，才能让它们处理数据流，例如，指定服务的QoS设置要移植到WAN优化器上，或者原本由中间路由收集的网络流信息将改为由WAN优化器完成，因为原始的统计信息在TCP头包里再也不是显而易见的了。

隧道解决方案

正如名字所隐含的一样，隧道解决方案是将原始包加密封装成新的包，对优化器寻址产生的影响也和之前所讨论的差不多，只是改变更大，多个数据流被封装进单一不透明的隧道中，原始数据流更加难以识别。以上所有探讨的网络可视化模式都是针对每一个原始LAN连接，在WAN上也有一个类似的会话，保证大量的网络功能可以正确执行——QoS能够识别会话，每个会话都能和其他会话公平竞争（至少和未优化前一样公平），防火墙可以阻止单个会话等。采用隧道后，这样的会话轮廓将消失，所有的会话都会被混合在一起，WAN端的智能处理将被强制移植到WAN优化器或LAN上。隧道的优势在于它能够支持对网络传输进一步的优化，例如，一旦在隧道中创建了TCP/IP头包，还可以再次使用更少的字节重编码，此外，隧道简化了转发错误纠正技术，有助于如微波连接或战略卫星连接等松散连接环境提高效率。有了隧道，非TCP会话的优化也变得简单了，最后要解释的是隧道不用处理透明发送带来的问题。

不过，隧道也带来了一些之前未曾探讨过的潜在问题。首先，它将一个静态IP地址引入了一个动态网络。很显然优化器必须要被配置成能够识别哪个子网是在哪个地点，因此增加了网络管理者的负担。其次，在一个网状网络中，每一个站点之间都存在隧道，使得配置开销随着站点数目增加，以O（n²）倍数增长。在动态基础设施上架构的相互交叉的隧道，尽管复杂性已经有所降低，但是要正确配置所有隧道的传输速率将是让人困惑的难题。集中式设置将能够起到很大作用，但也仍然不是万能的。为了快速理解配置的复杂度，设想一个简单的网络，区域机构拥有一个路由和两条上行链路：一条接到Hub，一条接到不定的卫星站点上。下行带宽与上行带宽需要分开计算，下行链路带宽既需要单独计算但又要计算汇聚带宽。如果两条链路都成为了站点的终端，而仅仅是上下通道的差别，情况就更糟糕了。此外，这些错误事件将占用一些正确的设计，导致多条隧道被迫建立在同一链路上，由于每个隧道都认为自己能够独占链路，从而导致了在隧道之间产生对带宽的争夺战。最后，别忘了那些仅仅临时借用路径的数据流，它们是否能够公平地与隧道竞争资源——未经过优化的能不能拥有和隧道相同的权重？隧道本身的权重应该和连接数目相关联吗？设备该怎么了解这些信息？当需要对一个隧道覆盖网络进行优化时，上述问题都需要仔细研究。

LAN传输

到目前为止，我们还未启动对LAN传输的讨论，在客户端与WAN优化器之间，几乎所有基于网络的WAN优化器都会保持LAN透明，也就是说头包信息与优化前状态是一致的（能想到的唯一例外就是一个显示定义的HTTP代理将被看成一个WAN优化器）。在服务器这端，类似地也可以把它当成一个代理，使用WAN优化器的地址与服务器通信。这看起来有点特别，但是当数据中心网络特别复杂时，WAN优化器将很难或根本无法拦截所有与WAN有关的数据流，这样的处理方法就具备很大的优势。这一方法的不利之处在于服务器会把所有优化后的网络传输都看成来自WAN优化器，而潜在地增加了日志和授权操作的混乱。因此，如果需要在这样的环境中部署系统，这些情况都必须事先了解清楚。

软件WAN优化环境中的网络可视化

如果优化软件被装载在客户端自身，进行设备集成时，网络可视化的操作并不是特别麻烦。此时，优化软件寻址将会直接映射到客户端，因此至少在客户端不用为“如果包没有被正确转发给WAN优化器该怎么办”这样的问题操心。除了常见的分割优化器寻址模式外，建立一条或多条从客户端到远程WAN优化器间的隧道也是常见解决方法。

对于大多数终端客户优化软件而言，它们要面临的挑战并非寻址或端口重映射而是配置。大部分客户端优化解决方案会配置工作被“推送”到网络边缘完成。这样，管理员就有可能需要确定服务器方所有的WAN优化器、全部的潜在服务器子网，以及终端用户设备上所有需要优化的服务（难以置信吧）。有些时候由于无法识别不同配置组之间的差异，导致所有客户端不得不无视它们在位置、角色、硬件平台等方面的差别，而被迫共享一个统一的配置方案。因而，与厂商基于设备的解决方案相比，很多软件优化方案看起来更像是对各类基础代码的一个事后补救，这一任务非常棘手，因为与管理像WAN优化设备或VM这类固定的网络基础设施相比，管理众多相距遥远的客户端难度更大。

如果从云的视角考虑，基于软件的客户端优化解决方案要比利用硬件设备优化更合适云平台，基于软件的客户端优化解决方案提供了任意时间、任意地点接入云的可能性。不过，基于两点考虑，本章我们将更多关注WAN优化设备，一方面是因为通常WAN优化设备优化效果更好，优化设备可以利用用户操作来提高之后的访问速度，比方说，节约下来的带宽足够用来提高一个群发邮件的附件传输速度。另一方面是因为目前优化设备的销售总量已远远超过终端软件或VM，随着云科技与企业IT架构结合的愈加紧密以及企业中类型II终端用户的不断增加，探讨它们对部署方式的影响是件很有意思的事情。

综合考虑优化设备与现有优化软件，我们需要考虑一个架构问题：那些拥有优化软件的用户该如何接入或脱离带优化硬件的LAN网络。首先，必须确保只有一个优化连接，要么是通过终端软件优化到服务器的连接，要么是利用硬件设备优化。从客户端到本地LAN的优化以及从本地LAN到远程WAN优化器的优化效率不高，通常也会产生性能问题，而更糟糕的是：这一方案阻止了终端到本地优化器之间的独立优化，使得WAN链路实际上变成非优化链路了。

某些WAN优化器厂商会通过加重配置要求的权重以确保正确优化能被强制进行，但是我们也可以找到更佳的解决方案。首先，自发现机制避免了在每一个终端用户PC机上都要标注隧道终端的做法。其次，自发现机制的探测算法使得优化软件能够发现本地的WAN优化器并且自动让位于它，不过虽然这种方法避免了双重优化，但是它也会生成一些奇怪的配置文件，这是因为当用户离开办公室后，手提电脑的WAN优化软件是识别不了局域网络的数据格式的。因此，为了防止移动办公的性能受到影响，需要增加一个探测附件，目前只有Riverbed公司能够提供，使得软件能够主动与优化设备交互，以掌握WAN的数据格式。当用户再出门时，网络性能就不会因为提前预约软件而重新配置。

说明：让我们用一个案例来说明上述所有相关技术。去办公室前，Ben下载了一个项目，一边喝咖啡一边工作（使用软件加速方法访问数据中心）；回到办公室，他把它上传至文件共享服务器，当天有三个同事修改了这份文件（使用本地LAN优化器加速）；Ben回到家，晚上继续工作，当他第一次在家里打开这份文件时，操作的速度仍然和在办公室一样快，就像软件优化器一直在关注这个优化连接一样；第二天午餐后，Ben完成了这个项目，通过email将结果发送个整个小组，由于文件共享机制，所以文件上传至邮件服务器的速度非常快，而因为WAN优化器通常都能识别这样的需求（同时通过协议和用户），所以30名接收者下载邮件的速度就像光速一样快。

虚拟环境寻址

直到最近，数据中心均采用基于硬件的WAN优化，基本上没什么必要需要在它们的服务器上运行优化软件，解决它们高标准性能需求的理想方法看起来就是采用专门的硬件设备，而且服务器管理员也因此不必考虑负载问题。然而，完全的虚拟环境不断增多改变了这一现象，能够实现虚拟环境集成任务的新技术也随之出现。分割终端在VM上安装了一个叫“发现引擎”的小程序，这个代理能够探测到新出现的优化请求和当前的优化连接，还能将包重定向到另一VM的WAN器。在WAN中，这个连接看起来没什么特殊（上述说的每个连接），但是现在在WAN优化器和代理之间多了一个LAN跳，这个传输是不透明的，但是为了保证传输正确，它会在地址域保留服务器IP和优化器IP地址。代理可以在服务器软件发现包之前重新封装包的地址，因此在混合私有云这样比较难以或根本无法直接路由的环境中就可以实施有效集成。