4.2　WAN优化的好处

很难比较得出整合并维护一种新技术与仅仅是“购买更多带宽”这两类方法之间的优劣。为什么WAN优化值得我们费这么大力气？它又将如何克服上述瓶颈问题？本节将面向WAN优化技术以及这些技术如何充分发挥高性能云应用展开探讨。讨论将由问题的根本——节约带宽开始，接着转而探讨如何克服应用层延迟，一旦这个问题得以解决，网络性能将得到极大改善。并且，两者会产生一种叠加效应——减少延迟意味着防止网络发送冗余数据，网络负载也将随之降低。最后一节将分析哪些技术能单独应用于TCP层。

4.2.1　借助压缩和重复数据删除节约带宽

当带宽有限时，WAN优化者将在纯数据发送层使用两种调整技术：无损压缩和重复数据删除。

Lempel Ziv，简称LZ，是最具代表性的无损数据压缩算法，可以将要发送的数据压缩到原来大小的一半或三分之一左右（即客户端发送数据若为100KB，通过压缩，实际在WAN上的传输数据量只为30～50KB）。算法对内存和CPU要求都不高，适合底层实现以及数千并发连接同时工作的环境。LZ算法通常会单独应用在某些设备上，但这些设备主要任务并不是为了优化，例如面向QoS设备或那些希望节约少许字节的存储单元。

重复数据删除技术相对更复杂一些，它要求能够在识别出“从前”已经被发送过的那些数据实例，然后引用这些实例的位置，而不再重新发送原始数据，重复删除可以应用在不同的数据粒度级别。例如，细粒度的重复数据删除也许能够一个字节一个字节去判别两个文件的不同之处，而基于块的重复数据删除算法则只会注意两个块之间的差别。精细粒度重复数据删除可以识别只有几个字节长度的实例，而不用受到诸如块边界这样的限制，能够达到更高的数据压缩比率。WAN优化设备首先应用重复数据删除技术，然后再对处理后的无重复数据流进行压缩。

重复数据删除的一个示例

在各类重复数据删除算法中，最为人们熟悉的莫过Riverbed Steelhead产品提出的可扩展数据简化（Scalable Data Referencing,SDR）算法，它为我们学习如何实现这一功能提供了一个很详细的案例。尽管试图用不到1章的篇幅完成对全部SDR算法内容的介绍并不可行，不过简单了解一下也有助我们理解重复数据删除与数据压缩之间的差别，以及为什么更复杂的重复数据删除能为整个企业网络带来良好的效果。

认真观察横跨企业WAN的数据流，你将发现其中充斥着大量冗余数据：同一份email被发送给不同的接收者，由于一点点细小的更改而使得文件不断重复备份至远程文件共享设备上，数以百计或成千上万雇员访问同一Web应用等。压缩可以减少一部分网络流量，但是它的应用范围仅局限于单个应用内，当遇到位于多个代理之间应用或者随时间变化的多个应用，压缩就无能为力了。假如能够对重复的数据进行并且以比LZ算法更好的压缩效率实现传输的话，将取得惊人的缩减效果。为了得到最好的性能，算法需识别数据流的细节，而不是仅仅针对消息整体，否则像因重复编辑导致的这类冗余就会被忽视。这样的匹配检索必须是持续的，而非只处理单个包或者是某一个网络连接生命周期内的数据。与此同时，不单只有因协议带来的缩减，还存在跨协议的缩减，例如编辑一个文件然后被Email或者上传至Microsoft SharePoint，再被其他用户下载。

设想一些简单操作产生的包的流动过程，例如，从Microsoft SharePoint下载一个文件，当包沿线缆传输时，从一个用户处下载文件到另一用户过程中产生的冗余能够被探测出来，但是这些探测会受到那些非冗余字节的干扰，比如TCP/IP协议的包头部分。可以将检测限制在仅仅对内容——数据有效负载的检索，而不必考虑头部的噪声（如顺序号）。但是有效负载内部也存在一些令人烦恼的噪声，譬如HTTP协议的包头。为了便于讨论，假设我们举起一只魔杖，使得我们可以只关注那些传输到某一方向的纯数据，而不必去考虑这些应用的头文件，在某种程度上，这就是文件自身，即通过对包的重组，将它们变成我们在服务器上能够直接读到的文件，我们可以想象已经将它存放在缓存中，稍后再进行检查。只是我们的目标是当这些文件被更新并再次发送后，能找到内容变化的部分，因此需要更深入地研究文件的内容。

假设我们能够使用分段算法以某种特定方式将文件分割成小的片段（例如，如果下一次文件内容未发生改变，算法能确保文件分割结果与前次相同），这样就可以检查这些片段并确定它们之前是否已经传输过。如果片段足够小，那么在编辑过程中就较容易保持不变，并且即便确实有一部分字节流被修改，也很容易回溯回去并匹配到最近一次传输的片段。

有好几种技术可以完成这一任务。其中，比较简单的方法可以通过将文件内容划分成尺寸固定的区域或块，然后把每一块当成一个片段，但是，通常这种方法的压缩效率很低，因为一个很小的改变可能会产生级联效应。例如，在一个拥有1000个块的数据流第2位中插入一个字母，所有1000个数据块的内容都将发生因此改变，这意味着因为一个字符的变化，所有1000个块都将重传！

更好的解决方法是构建可视数据窗口，窗口大小可按需调整，由当前窗口内容变化情况确定判别函数的结果。如果数据没有发生变化，则函数值保持不变，即相同的数据片段会产生相同的“cut point”。如果数据发生了更新，就会影响到1个或更多数据片段，但当接下来没更新过的数据经过数据窗口时，系统会按照同样方法继续进行分段判断。基于窗口的类SDR方法中，窗口尺寸是不固定的，这使得在处理插入、删除及更新操作时，可以更加灵活地处理片段。

如何完成某个给定数据片段的重复删除呢？我们可以采用序号或标签方法对片段进行标注。尽管标注本身需要占用一定空间，但与存储数据片段相比，这些空间就变得微不足道了（例如，一个16字节的标签可以标注128个字节）。当判断两个数据片段相同时，为节约空间，系统只传输片段的标签。那么，片段和标签采用多少位存储合适呢？对于数据片段，有一个固有的平衡问题需要考虑。采用大尺寸数据片段，会得到很好的压缩效果，比如，假设用16字节标签来标注8000字节的数据片段，那么只传输片段标签的方法所能获得的压缩比则为512:1！但相应地，随着数据片段的规模不断增加，片段内数据更新的可能性也将不断增加，导致片段间匹配成功的概率将直线下降。如果片段尺寸足够小，数据片段匹配成功的概率会非常高，只是这种方法又会大大降低压缩比率。同时，我们还需考虑用来标签片段的标签范围应足够大，以免WAN优化器会发生溢出问题，所以标签算法应确保任何时候都能生成新标签，且不会与之前标签产生重复冲突。另外，也必须保证数据片段与标签间1：1的映射方式，在删除重复数据时不会影响正在传输的数据，这样当标签全局唯一时，数据片段匹配判断也不再是个难题了。

那么该怎么办才能解决尺寸选择的困惑呢？数据片段的尺寸最好是既能足够小同时也能足够大，显然这是不可能的。可以从调整位置信息来提出解决方案。设想某个文件有两个内容看似相差甚远的版本，但只要有部分内容相同，这些数据片段的顺序一定是相同的。因此我们可以借助这样的位置信息，将小尺寸数据片段不断组合形成大尺寸数据片段，增大有效数据片段的规模。通过不断重复编码游戏就可以完成这一任务，首先取出数据片段的标签序列，将标签序列放入新的数据片段中，如果片段已经存在，就用标签代替它，否则为新片段生产一个新的标签并替代片段。当反复几次编码操作后，大量的原始数据将被一个简单的标签代替，即便原始数据片段非常小，也能得到一样的处理结果。

图4-3展示了一个十分简化的可扩展数据引用的样例，Alyssa发送的信息被分割成7个基本数据片段归至3档不同的数据片段层，分好层的数据片段被发送给文件服务器，Alyssa重新编辑该文件，原来的片段8和片段4可以被重用，系统会将它们重新打包成一个新的片段，Alyssa最后定稿时将产生一些新的数据片段。而对消息接收这方的Ben而言，他看见的是一个完整的只采用了一个标签标注的数据片段。

使用SDR机制后，原始数据将被转换成一组对原始数据的引用以及新的标签定义（如果传送内容是底层的原始数据，标准压缩LZ可以更进一步地缩减传输数据的规模）。为了保持数据压缩级别足够高，必须获得数据片段的相关信息，为此标签和片段之间的映射关系要在硬盘上保存。当系统发现已经被处理过的数据再次出现时，就可以通过引用删去重复。类似的，当数据被发送或返回时，其他Riverbed Steelhead设备也可以使用同样的标签来发现这些数据，从而节省了定义的空间。如果能在整个系统范围内，包括相同用户间不同的连接之间，不同的协议之间，不同的站点之间，以及不同时间段连接，都应用SDR机制，则可以获得重复数据删除的最佳效果。

图　4-3　可扩展数据简化的简单示例

以上举措将对整个网络带来怎样的影响呢？最关键一点，重复的数据将不会再和原始数据混在一起，从而带来一些数据保护方面的优势，当然还有数据压缩方面的好处，但是这样也会影响到系统架构。例如，在已经消除重复的数据流之上不建议运行病毒检测或侵入探测程序，因为它们无法发现匹配的模式。同样，在处理后的无重复数据流之上使用Cisco基于网络的应用程序识别（Network Based Application Recognition,NBAR）实施深度包检测（deep packet inspection,DPI）对数据流分类也是没什么意义的。这些变化也适用于网络管理系统中监测及流量记录设备。其他像这样的附加设备，必须部署在能够探测到原始数据的网络环境中，因此要么将它们部署在网络优化范围之外，要么必须在WAN优化器中考虑集成设备的功能。