4.2.2　应用层加速

带宽缩减去掉了网络传输中每一个重复的字节，但仍然存在另外一个性能瓶颈，因光的传输速度所导致的一个内在时延，WAN优化器也必须能够应对这一类性能挑战。许多客户-服务器模式的应用程序和协议是为本地局域网设计的，这类环境中的时延往往较低，对性能影响并不明显，应用程序和协议因此并未专门针对高时延环境进行优化。往返应答模式在LAN环境中耗费的时间及性能代价并不高，因此早期开发人员并未考虑到当有效往返应答增多时将对吞吐量和应用程序性能带来怎样影响。当用户与服务器相距遥远时，聊天类的通信协议性能将产生非常严重的下滑。

在WAN环境中，依据每次连接的距离远近、跳转次数以及在路径中遇到的处理延时不同，单次往返应答需要大约30毫秒至1秒的时间完成，这样的时延是普通LAN环境中时延的千倍，将对文件系统或诸如CIFS、MAPI和NFS等协议性能带来极大破坏，导致这些服务变得非常缓慢甚至在某些情况下根本无法访问。为了解决这一网络性能难题，WAN优化器奇迹般地改变了协议的请求，优化了WAN延迟对性能的影响，为应用程序提供加速服务。

缓存策略

在端点或网络中间设备上实施缓存策略是最初用来缩减带宽以及加速应用程序策略之一。缓存机制能够识别对象及它们的元数据，并可以依据元数据判断出这些对象之前是否已经传输过，而不必再发出申请。HTTP是缓存机制应用最成功的案例，访问单个页面的一个简单HTTP请求比较合适拿来当做样例以说明此问题。HTTP协议将页面和一个HTTP头信息一起发送，在头包里可以存放如代码清单4.1所示的一些有关当前页面对象生命周期信息，用来告知缓存当前对象何时曾被修改，也可以存放显示的缓存指向位置信息，如代码清单4.2所示。服务器可以要求客户端不要缓存对象，当像PNG、JPEG、HTML页面等类型的对象被再次请求时，本地缓存检查核实对象存在合法副本后（要求副本未超过生命周期规定时间，且允许缓存），则可以应用缓存。

代码清单4.1　HTTP头包片段示例

代码清单4.2　HTTP头包中缓存指向信息

要注意的是，这两组代码是2011年3月下载的，由此可以发现将缓存作为解决方案的一个风险：这个页面自2008年就再未更新过，而且头包是显示与缓存绑定的（缓存控制），这意味着此页面早就过期了。尽管这样，基本上每一个Web服务器都会采用缓存机制来帮助提高性能。

HTTP协议外的缓存机制又是怎样的呢？这些方法很难实现也很难有效使用。HTTP的优势在于它本身就是为远距离通信设计的，对缓存控制、过期时间等信息都有明确说明。而大多数非HTTP协议，比如文件系统是获取不到这样的信息的。比方说，当一个CIFS服务器通过Windows文件共享机制传输一个文件时，该怎么设置过期时间呢？有些文件从来未更新过，有些大概一年更新一次，而有的可能短短几个小时内就会发生多次更新。为了缓存某个文件，缓存控制机制要么假设某种场景，要么就要检查每一个访问。即便是有显示的元数据检查，还是得不到明确的结果，因为一般文件服务器只会提供时间戳和文件大小这些信息。这样的信息用来明确是用户还是程序访问过当前文件已经足够了（比如两个用户同时改变了文件内容但没影响文件大小这类行为的可能性有多大，而多个访问同一文件的程序，都由同样的外部事件触发，可能它们时间戳都相同，也不会改变文件的长度）。而且，很自然地，管理员通常会对缓存环境能提供的一致性有多可靠心存疑问，相当一部分数量的管理员更倾向得到一个响应慢一点但精确而非响应非常快但也可能并不正确的文件版本。下节将讨论一种能够得到响应快结果也精确的新型优化器。

缓存体系还面临另一个挑战，就是缓存到底是否需要为所有对象服务。这是个看起来并不起眼的小问题，但对工程实现却有着巨大的影响。举一个最简单的例子，可以要求用户使用本地缓存而非直接使用文件服务的缓存，不但要考虑许多配置选项（包括像如何在每一个办公点完成配置，如何服务移动办公的用户，或者那些希望直接使用文件服务器缓存的用户，以及缓存出错时该怎么处理等），工程实现也面临更大的挑战。当把缓存控制器当成一个具备控制权威的服务器使用时，就必须百分百实现协议的所有部分，而如果是一个无须承担服务器角色的设备而言，则可以不用考虑很多没有太多价值的协议规则，这样能够极大简化实现（包括维护）的工作量。尽管这种差别看起来并不明显，但如果考虑到网络上所有可用协议，还是极有价值的。每一个想提速的协议，为了执行正确，基本上都应在缓存中实现所有的服务（更新产生时也是一样）。而某些类似服务的参数也必须为每一个缓存环境单独配置（例如Squid缓存服务有多至350个配置参数），这些对管理员都是操作时需要考虑的问题，在网络部门和服务器部门进行机构边界划分时会变得更为复杂。

端点用户之间可以通过多协议连接也暴露了缓存机制的另一效率问题。使用缓存避免重复的数据发送因而能够节约带宽，前提是能够识别对象元数据。假设用户通过email接收了文件，在windows文件共享环境中进行编辑和保存，并上传至Microsoft SharePoint的服务器——这意味着需要调用三级缓存（email、CIFS以及HTTP）。由于每一级缓存都是在对象级别单独地完成重复判别，因此三级缓存意味着对象要分别在每级缓存中被存储一次，共要存储三次。另外，如果缓存机制支持跨协议带宽缩减，这意味着系统将在所有缓存层之上再多存储一次对象，也就是一共存储四次，这种低效操作将给缓存设备的说明带来极大负担。

应用加速

毫无疑问，WAN控制器还有比缓存更好的办法来克服应用延迟。应用加速这类技术可以提前预测客户及服务的行为，当实际行为发生时，只需去掉预定义中不需要的操作，直接执行预定义好的事务。由于操作已经预先定义好，一旦客户端启动这些操作，马上就可以从本地得到操作的返回结果，从而避免了在WAN因为往返应答而产生的延迟。为了实现加速，WAN优化器必须充分深入理解协议才能明确哪些元素能被安全地修改。因为服务总是数据的权威来源，所以不同于缓存控制器，WAN优化器不需要实现协议的所有要求。为了更有效率，应用加速必须加载在像SDR这样具备高效重复数据删除和数据压缩能力的平台之上，这样的平台将要负责大部分有效的数据传输，而不是仅仅依靠对缓存后的数据局部传输。

这种机制与之前讨论的传统缓存机制有着截然不同的功能，尽管在一个有着良好设计的应用加速系统，有时也可以看到缓存的影子。简单的缓存机制要求在本地存储大量的对象副本（如文件、文件块、HTTP对象、email消息等），然后通过安全协议、封锁策略等措施，保证多个客户端能访问和修改这些副本，且能与原始数据保持一致，使得整个系统结构变得复杂难以维护。在应用加速环境中，有时也可以结合缓存机制，例如一个完全封锁的文件，当用户正在使用当前文件时，如果WAN优化设备检索到这样的阻塞，就不需要再去服务器获取更新消息。

在多协议环境中实施应用加速，必须要求对每一个协议都编写说明代码，这个任务可以通过改变体系架构而被适当简化，例如将一些模糊不清的协议元素放到服务端处理，整个系统只存储一个公用数据副，在设备中则不用再存储多个数据副本。这种只存储一个统一的数据副本的方式，不但可以达到和原来一样甚至更好的协议加速及数据缩减，也简化了跨协议带宽的实现，同时还能降低对存储空间和RAM的占用。要知道WAN优化所面临的基本挑战之一就是能够支持更广范围的协议，以尽可能满足企业需要用到的所有协议。

说明：应用层的改变将可能获得非常棒的优化效果，使得云集中管理变为可能。设想一个MAPI（（Microsoft Exchange/Outlook协议）的场景，用户向它们的本地邻居发送接收Email，操作延时很小，但如果服务器移植集中到云平台，使用100毫秒RTT T1链路（1.5Mbps），一封发到邻居桌面的邮件就需耗时2分钟（假设附件大小为6.3M）。借助应用程序加速（数据有64%的压缩），耗时缩短至40秒左右，如果需要再次转发（比如，发给另外一个用户），SDR保证只需6秒钟就能完成（速度提高了近23倍）。

另一个挑战是如何处理通用型协议，像FTP或MAPI这样一些协议是与某些特定应用程序绑定的，而像CIFS和HTTP这类协议是为应用程序搭建了一个平台，应用加速设备如果只盯着HTTP协议本身，则对其上应用不会有任何改进。必须从跟不上了解应用是如何使用HTTP——特定的优化可能会极大提高某种应用，而对另外的应用产生不良影响，比方说，如果能够研究Microsoft Office应用是怎么使用CIFS，那么就可能比使用一个通用的CIFS模块，对网络流量优化效果更好。因此，仅关注你的云平台所支持的协议的范围是不够的，还必须深入了解这其中的某些核心协议。

提前读应用加速案例

顺序读文件是一个简单但可以充分说明应用加速工作方式的案例。设想某一个应用需从文件中读取数据，进行计算后再写回文件尾部，使用广域文件协议，简化后的操作在某种程度上可以表示成如下几个步骤：

1.验证用户拥有访问文件的权限

2.封锁文件

3.读文件尺寸

4.打开文件

5.更新读时间属性

6.读数据库0

7.读数据库1

8.……

1000.读到文件尾部

1001.写数据块

1002.关闭文件

上述操作展示了两种不同的优化选择。图4-4展示了当一个文件被封锁时，服务器这端的网络在返回锁状态时，还能够同时检查文件的大小并返回。这是一种探测性的预报，检查文件尺寸没什么危害，而且还可以避免一次往返请求，就像这个案例一样。另外一个优化的时机是在打开和更新文件序列时，在这个协议中，有可能这些操作彼此都是关联的，如果这个协议在设计时比实现更注重普遍性，这样的情况是有可能发生的。WAN优化器知道这些操作总是一个接一个进行，因此能提前一次性完成。

图　4-4　优化的文件读操作顺序图

最重要的环节是序列读操作优化，文件的读操作是同步顺序执行，如WAN连接中的高时延一节所介绍，这些相互依赖的序列请求会因窗口尺寸产生时延，并且当时延增大时将对系统性能带来潜在危害。如果对锁的权限进行监测，WAN优化器可以得知客户端对文件是排他占用，但在客户端操作开始前对文件读取是不受限的（因为没有其他客户端可以更改文件）。网络服务器这端的WAN优化器将一次性读取多个数据块，并一次性发送给客户端。如果窗口尺寸大到足以弥补WAN时延，那么操作性能将重新回到LAN级别。在极端情况下，一旦上锁，WAN优化器将可能读取整个文件内容，并通过网络发送给客户端，使得网络这头的客户端能够利用文件印象满足所有本地读操作的访问。

图4-4解释了上例中应用加速后事务序列，对客户端和服务器而言，看见的只是普通的WAN之上的操作序列，实际上这些操作都是预先交叉发送的，这种方法降低了用户实际等待时间。

应用加速后对结构的影响

为了启动加速技术，WAN优化器需要在WAN协议层改变传输内容，这样才能使客户端和服务端的WAN优化器就优化后的协议进行沟通，这类沟通有时称为协议翻译。理解了应用层的协议后，WAN优化器可以把数据和包头分开，如重复数据删除一节所述一样，和消除重复类似，经过优化后的网络流会发生一定变化，导致协议翻译设备将没法按正常情况进行翻译，例如，负责探测连接的防火墙软件会将优化后的HTTP协议作为非法HTTP流。例外，这样的紧密联系也会对操作产生限制。比方说，软件的版本信息需要保存在优化后的光纤或类似级别信息中，以确保更改后的协议能被正确理解。