4.2.3　TCP加速

尽管有海量的企业应用协议在使用TCP，但某些协议确实不具备聊天功能，或者不是通过聊天机制实现大批量数据传输，如果是这样，那么TCP层的协议颠簸就会因WAN环境变得更加明显。众所周知，由于TCP使用窗口算法来判断一次可以安全传输的数据大小，所以为了公平，也为了能够满足Internet上大量不同吞吐量和不同的硬件实现，TCP协议需要避免拥塞，因此当时延增加时，这样的颠簸会导致性能成指数下降。WAN优化器可以采用多种方式解决这一问题。

说明：本章焦点为基于TCP的协议以及使用这些协议的应用程序，因为大量的企业网络和基本上所有终端用户的应用程序，包括文件共享、email、FTP、远程桌面以及Web，都是基于TCP实现的。非TCP协议在企业网络中应用比较多的只有VOIP和网络流媒体直播传输这两种，其中，VOIP协议由于协议本身特性可以实现压缩处理，也不支持重复数据删除机制，唯一能优化的对象就是协议的包头部分，该协议底层为UDP，不会遇到本章所讨论的那些TCP协议会遇到的性能瓶颈，至少没有颠簸。流媒体直播与VOIP在许多方面都比较相似，唯一不同点在于流媒体直播通常会消耗大量网络带宽，甚至有可能要占用整条链路。可以使用一些处理视频的方法，比如将流划分给LAN内的多用户，达到类似重复数据删除的效果，对预先录制好的视频也可以采用本章介绍的重复数据删除（比如多个用户观看同一视频的情况）方法。

一般的复杂网络中都会存在多操作系统、多版本以及多型号设备问题，因此在设备之间，比如一台性能优化后的NAS服务器与一个已经工作了10年底工作组，存在极大性能差异，更不用提在过去十几年里，客户端设备的内存和CPU性能所发生的变化，均使得在不同的Microsoft Windows系统（或其他系统）上设备实施配置都不同。许多基于老版本TCP协议开发的设备，不支持新协议中减轻拥塞的功能，而WAN优化器因为是在广域范围的私有云服务之上工作，所以可以不受上述这些问题的影响。

图　4-5　WAN优化将一个端到端连接实际分成了三部分

WAN优化器将原来的TCP连接切割成3部分，使得这些新的WAN连接在各自范围内都能支持现代TCP操作。图4-5解释了WAN优化如何将客户端机器与云平台上的应用之间连接分割成3部分，使得WAN优化器调优后更具有有针对性，连接的WAN分支部分也可以节约更多的带宽并降低有效时延。我们没有必要在这详细探讨RFC的效率，总的一句话，不需要使用特殊的优化方法，就能依靠自身局部优化而显著提高整个广域范围网络性能。

TCP连接分割不但支持了现代TCP技术升级，TCP连接分割结合WAN连接上的数据缩减，也为网络提速带来了令人惊讶的可能。滑窗机制支持一次发送多个数据包，但发送的数据量不能超过当前窗口大小，除非收到接收端的确认消息，当时延增加时，窗口就不能及时滑动，所以发送方在一次往返应答中只能最多发送一个窗口大小的数据。因而，当WAN优化器对TCP连接实施分割后，在不同的连接上就可以产生很多新的有效窗口，LAN这端的连接就可以高速完成，持续支持WAN这端的数据发送，虽然WAN这端的连接仍然受限于窗口，但别忘记此时数据已经是经过压缩处理的，因此理论上系统吞吐量将更高（例如，一个有4倍压缩能力的64KB的WAN窗口，代表了来自客户和服务器端原始数据量为256KB，这种情况下，连接速度将是原来的4倍）。

说明：让我们简单了解一下采用TCP加速的客户端用户案例。一个制造企业希望将所有工业设计移植到云平台上，工作流非常简单：早上上班时，工程师通过FTP将任务从云端下载到本地工作站（封锁在PLM系统中），在本地开始工作，然后在下午下班前再将结果上传（并解锁），但是存在性能问题。即便是物理位置最靠近云中心的办公室，用FTP传输一个200M左右的文件，需要5～25分钟时间，就算这行得通，但如果办公室在印度，就不行了（仅一个工程师需要3.5小时传输时间，还没考虑网络拥塞）。使用了Riverbed Steelhead设备后，在E1（2M）链路上，印度这边的客户端只需5分钟就可以完成传输（数据缩减了87%），而对本地用户，感觉不到1分钟就搞定了。这都是因为采用了重复数据删除或单独的TCP应用加速技术，因为FTP这一层时延并不明显。

最后，TCP连接通常不能满足在高速带宽链路上传输大量数据的需求，TCP性能受限的根本原因在于Van Jacobson最早提出的避免网络拥塞的算法与高带宽延时网络（这种网络有时被称为长肥网络或LFN）相互影响。因为每一次成功的往返应答只能处理一个包，所以拥塞避免机制增大了TCP的窗口规模，当窗口比较小时，增大单个包的尺寸是合理的，但是当窗口尺寸太大时（比如几百个包），每次附加往返应答都会对窗口尺寸有微弱的影响。当这样的累加达到一定次数时，若发生包丢失，要重新发送一个包所需的往返时延就变得非常庞大——导致TCP应答非常迟缓。例如，要维持一个吞吐量为1Gbps，延时为100毫秒的WAN网络能力，发送端TCP窗口大约应为8000个包，对半开的窗口尺寸为4000个包，所以在发送和接收端需要4000次成功的往返应答才能完成8000个包的传输，而每次100毫秒的延时，还要累加！

同样，WAN优化器提供了一个理想的平台来解决这个问题，即支持一种广域范围链路的“高速”模式将缓和或消除这个难题，此类方法特别适合需要往数据中心传输大量数据，或数据中心之间大量数据互相复制的情况，具体实现包括Riverbed Steelhead设备支持的高速TCP（RFC 36497/3742）、Citrix’s Branch Repeater VPX提出的硬启动或者是Cisco WAAS上的传输流优化（Transport Flow Optimization,TFO）。

QoS为TCP加速

只支持服务质量（Quality-of-Service,QoS）或者同时支持LZ压缩的QoS设备经常会被当成WAN优化设备，但是这种做法已经过时了，因为它们无法实现对应用层或LFN网络优化，这些设备只能够满足极小部分企业网络环境需求：中等带宽时延链路，不需要使用聊天协议，拥塞也不明显。实际上，QoS自身并不具备优化功能，它只是简单地赋给队列前部的包较高的优先级而已，这种处理相应就会降低其他协议速度。QoS更适合被看成一个自身需要WAN优化的设备，我们将在4.3.4节中讨论这一问题。