2023年H3COAA之WAN优化技术经典白皮书【精选推荐】
下面是小编为大家整理的2023年H3COAA之WAN优化技术经典白皮书【精选推荐】,供大家参考。
A H3COAA 之 之 N WAN 优化技术经典白皮书 H3C OAA之WAN优化技术白皮书 目 录 目 录 OAA WAN 优化解决方案技术白皮书 1. 概述 1.1 背景 广域网的带宽比局域网带宽差很多，同时广域网带宽的增加会带来成本大幅度上升。与此同时还会带来一定影响的网络延迟。广域网应用大幅度增加，除了语音、视频外，传输文件、图片与海量数据的分析与处理，这些都是困扰用户正常使用的重要因素。
另外信息的集中化管理，对各分部与总部之间的高质量信息转送也提出了越来越高的要求，这就需要增加各地的分支机构。与此同时企业分支网络逐步出现了数据集中趋势，通常情况下企业会将大部分共享数据库放到总部的数据中心，给每一个分支机构访问，但随着分支机构的迅速增加且多数员工外出办公时的访问量也在上升，这种一对多的数据服务给企业总部的服务器与带宽带来了巨大的压力，影响了数据交换的速度。企业尽管也能够向运营商购买更高的带宽，只是成本费用较高同时效果不明显。
广域网性能低下关于用户的影响要紧包含下列几个方面：
大多数企业管理、应用软件均使用 C/S 结构进行编写，虽逐步在进行 B/S 的更换，但是大部分企业的应用仍然基于 C/S 结构，关于 C/S 到 B/S 结构的更换仍然是一个重要的课题 增加带宽并不能解决访问及应用慢速的问题，问题存在与 TCP 自身，TCP 自身慢启动问题仍然是阻碍企业业务正常开展的要紧问题 广域网行业纵向网的分支机构众多，全部使用高带宽连接投资非常巨大，合作伙伴之间带宽通常采取的是临时建立的连接，带宽极低，又要传输大量的数据，造成传输速度难以忍耐 基本语音视频业务没有最佳的 QoS 策略来进行保证，造成质量不佳，最终导致应用开展不起来；大量非法应用堵塞了现有正常应用开展，占据的带宽造成了正常带宽的缩减。
1.2 广域网优化简介 广域网（WAN）带宽昂贵，绝大多数用户也因此只能拥有有限的广域网带宽。如何以最小的投入提高网络性能？如何为远程用户提高访问速度与服务效率？如何确保随时召开异地视频会议而不被打断？一种方式是“扩出口买带宽”，事实上有更合理的方法解决。数据压缩、动态缓存、IP 流量管理与 QoS 等都能够一定程度上解决广域网传输加速的问题。但压缩仅仅解决了带宽资源的问题，关于延迟非常大的链路，仅靠压缩是无法完全解决问题的。为解决系统性能与应用系统数据传输受 WAN 通信限制的问题，有关技术开始浮出水面，并逐步形成一个细分的市场—这就是 WAN 优化技术市场。其中包含：应用加速、数据压缩、动态缓存、IP 流量管理、QoS 保障、带宽管理、延时缩减、序列缓存、路径优化与应用管理可视化等。要解决的核心问题是应用与广域网之间的矛盾，由于传统的网络资源限制了多种应用的性能。随着网络优化技术的进展，诸如操纵网络应用（操纵 QQ、MSN、IM）、限制 P2P（限制 BT、eMule、PPLive、eDonkey）软件占用带宽、通过 QoS 合理分配带宽、Web 缓存、数据压缩、动态缓存等网络加速方法与解决方案已经能够满足多数用户的需要了。
为什么广域网优化会受到如此青睐呢？原因是它的确能解决广域网目前存在的几大关键弊病。首先，带宽问题。广域网的带宽比局域网带宽差得太多，如一条 T1 线路的带宽只相当于千兆网的千分之一，许多帧中继线路的带宽只有 256Kbps，同时广域网带宽的增加会带来成本大幅度上升。其次，延迟问题。打过跨国 IP 电话的人或者许都有这样的体验，当你说完话后，对方的回音总是过一小段时间才能听到，这就是延迟的最好例子，在进行视频通话时就更明显了。目前广域网应用剧增，除了语音、视频外，传输图形或者图像文件、海量数据的处理，都是困扰用户的实际应用。再有，协议问题。一些目前使用的协议并不是为广域网而设计的（如 TCP 协议），协议效率低下，性能不够理想。
2. 广域网优化原理介绍 广域网优化的技术有很多，但核心的技术要紧包含：数据压缩、动态缓存、TCP 加速、应用加速、QoS 等几个方面。
2.1 数据压缩原理介绍 迄今为止大多数网络压缩系统都是基于数据包。基于数据包的压缩系统缓冲数据包都通过解压器引导至远程网络。此后，用户可一次压缩一个数据包，或者一次压缩多个数据包，然后再发送至在其中反向进行该流程的解压器。
图1 数据压缩原理 基于数据包压缩应用的要紧问题是压缩时它将多种数据类型混合在一起。所有压缩例程在处理同类数据时将获得更大的压缩比。在处理异质数据时（比如，多种协议的大量数据包），压缩比率会大大降低。
基于数据包的压缩系统会存在其它问题。压缩数据包时，这些系统务必在网络中编写小数据包，并进行其它工作以集合并封装多个数据包。仅有其中一项操作不可能达到最佳效果。在网络中编写小数据包会增加 TCP/IP 标头的开销。另外，集合并封装数据包会为该数据流增加封装标头。
先进的压缩算法支持在处理所有应用类型时能够在完全同类的数据之间进行压缩。随之而来的结果是，与同类基于数据包的系统相比，压缩比更高。
图2 同类数据压缩原理 2.2 缓存原理 2.2.1 基本原理 所有压缩例程共同存在的局限性是存储空间有限。许多例程，比如 gzip，只能存储 64 Kb 的数据。其它技术，比如基于磁盘的压缩系统，能够存储 1 TB 的数据。为了懂得字典大小的作用，需要对高速缓存管理内容有一个基本的熟悉。
请求 web 站点类似，并非所有网络中传输的字节会在同一个频率下重复。有的时候系统会通过高频率传输一些字节，由于这些字节是常用文件或者通用网络协议中的一部分。其它字节只会出现一次同时不可能重复出现。压缩与堆积定律 (Zipf’s Law and Heaps’ Law) 中描述了频繁重复字节序列与非频繁重复字节序列之间的关系。
所有基于当前字典的压缩系统会通过存储频繁访问的数据并删除非频繁访问的数据以进行不均等的分配。通过这种优化方式，存储少于 10% 的所有字节方式会使命中率超过 50%。这种字节方式的不均等分布效果充分证明了公共压缩程序的效率。Gzip 仅存储 64kb 的历史记录，但平均能够压缩近 64% 的内容。Bzip2 能够存储 100kb 至 900kb 的历史记录，平均压缩了 66% 的内容。尽管数据存储空间不足，但 Gzip 与 Bzip2 仍能出色运行的原因在于频繁出现的字节序列能够表示网络中的大多数字节。
2.2.2 数据块缓存原理 基于块的系统可存储往常在广域网中传输数据流部分。再次遇到这些块时，其参考数据会传送到远程设备中，该远程设备继而会重组原始数据。
基于块的系统要紧缺点是反复出现的数据与块的长度永远不可能完全相同。因此，匹配仅是部分匹配，还会留下一些重复数据不被压缩。下图全面描述了使用 256 字节块大小压缩 512 字节数据时的情况。
图3 基于块的数据缓存 为了提高缓存效率，字节级粒度的缓存技术出现了。匹配并发送带有字节级粒度 (byte level granularity) 的数据。下图说明了处理数据的过程。
图4 字节级数据缓存 与基于块的系统相比，字节粒度级别不管关于文档还是关于应用层协议标头，均能提高其压缩级别。
2.3 P TCP 加速原理介绍 TCP 协议原理较为复杂，影响 TCP 性能的因素很多，但有一个关键的因素是 TCP 会降低带宽的利用率，这关于带宽极其有限的广域网来说是非常致命的。影响 TCP 带宽利用率的要紧因素包含下列几个方面：
窗口大小通告与滑动窗口 拥塞避免 慢启动 窗口调节技术 除了提高带宽利用率之外，减少确认重传次数，缩短 TCP 连接的握手过程时间等也是 TCP加速的重要技术点。
选择性确认 3 次握手过程的优化 下面简单介绍这几个方面的原理。
2.3.1 窗口大小通告与滑动窗口 通信双方接收模块需要根据各自的缓冲区大小，相互通告还能同意对方数据的尺寸。双方发送模块则务必根据对方通告的接收窗口大小，进行数据发送。这种机制称之谓滑动窗口，它是TDP 接收方的流量操纵方法。它同意发送方在停止并等待确认前能够连续发送多个分组（根据滑动窗口的大小），由于发送方不必每发一个分组就停下来等待确认，因此能够加速数据的传输。
滑动窗口在排序数据流上不时的向右移动，窗口两个边沿的相对运动增加或者减少了窗口的大小，关于窗口边沿的运动有三个术语：窗口合拢（当左边沿向右边沿靠近）、窗口张开（当右边沿向右移动）、窗口收缩（当右边沿向左移动）。
当遇到快的发送方与慢的接收方的情况时，接收方的窗口会很快被发送方的数据填满，如今接收方将通告窗口大小为 0,发送方则停止发送数据。直到接收方用户程序取走数据后更新窗口大小，发送方能够继续发送数据；另外，由于 ACK 报文段有可能丢失，发送方可能没有成功接收到更新的窗口大小，因此发送方将启动一个坚持定时器，当坚持定时器超时，发送方将发送一个字节的数据到接收方，尝试检查窗口大小的更新。
2.3.2 慢启动 假如发送方一开始便向网络发送多个报文段，直至达到接收方通告窗口大小为止。当发送方与接收方在同一局域网时，这种方式是能够的。但假如在发送方与接收方之间存在多个路由器与速率较慢的链路时，就可能出现问题。一些中间路由器务必缓存分组，并有可能耗尽存储器的空间，将来得降低 TCP 连接的吞吐量。因此需要一种叫“慢启动”的拥塞操纵算法。
慢启动为发送方增加一个拥塞窗口，记为 cwnd，当与另一个网络的主机建立连接时，拥塞窗口被初始化为 1 个报文段。每收到一个 ACK，拥塞窗口就增加一个报文段（cwnd 以字节为单位，但慢启动以报文段大小为单位进行增加）。发送方取拥塞窗口与通告窗口中的最小值作为发送上限。拥塞窗口是发送方使用的流量操纵，而通告窗口是接收方使用的流量操纵。
发送方开始时发送一个报文段，然后等待 ACK。当收到该 ACK 时，拥塞窗口从 1 增加到 2,即能够发送两个报文段。当收到这两个报文段的 ACK 时，拥塞窗口就增加为 4。这是一种指数增加的关系。
2.3.3 拥塞避免 慢启动算法增加拥塞窗口大小到某些点上可能达到了互联网的容量，因此中间路由器开始丢弃分组。这就通知发送方它的拥塞窗口开得太大。拥塞避免算法是一种处理丢失分组的方法。该算法假定由于分组受到损坏引起的丢失是非常少的（远小于 1％），因此分组丢失就意味着在源主机与目标主机之间的某处网络上发生了拥塞。有两种分组丢失的指示：发生超时与接收到重复 的确认。拥塞避免算法与慢启动算法是两个独立的算法，但实际中这两个算法通常在一起实现。
图5 拥塞避免与慢启动 拥塞避免算法与慢启动算法需要对每个连接维持两个变量：一个拥塞窗口 cwnd 与一个慢启动门限 ssthresh。算法的工作过程如下：
1) 对一个给定的连接，初始化 cwnd 为 1 个报文段，ssthresh 为 65535 个字节。
2) TCP 输出例程的输出不能超过 cwnd 与接收方通告窗口的大小。拥塞避免是发送方使用的流量操纵，而通告窗口则是接收方进行的流量操纵。前者是发送方感受到的网络拥塞的估计，而后者则与接收方在该连接上的可用缓存大小有关。
3) 当拥塞发生时（超时或者收到重复确认），ssthresh 被设置为当前窗口大小的一半（cwnd与接收方通告窗口大小的最小值，但最少为 2 个报文段）。此外，假如是超时引起了拥塞，则 cwnd被设置为 1 个报文段（这就是慢启动）。
4) 当新的数据被对方确认时，就增加 cwnd，但增加的方法依靠于我们是否正在进行慢启动或者拥塞避免。假如 cwnd 小于或者等于 ssthresh，则正在进行慢启动，否则正在进行拥塞避免。慢启动一直持续到我们回到当拥塞发生时所处位置的半时候才停止（由于我们记录了在步骤2 中给我们制造烦恼的窗口大小的一半），然后转为执行拥塞避免。
慢启动算法初始设置 cwnd 为 1 个报文段，此后每收到一个确认就加 1。这会使窗口按指数方式增长：发送 1 个报文段，然后是 2 个，接着是 4 个……。拥塞避免算法要求每次收到一个确认时将 cwnd 增加 1/cwnd。与慢启动的指数增加比起来，这是一种加性增长。我们希望在一个往返时间内最多为 cwnd 增加 1 个报文段（不管在这个 RT T 中收到了多少个 ACK），然而慢启动将根据这个往返时间中所收到的确认的个数增加 cwnd。
处于拥塞避免状态时，拥塞窗口的计算公式如下（引公式参照 BSD 的实现，segsize/8 的值是一个匹配补充量，不在算法描述当中）：
cwnd <- cwnd + segsize * segsize / cwnd + segsize / 8。
2.3.4 窗口调节技术 传输窗口大小，即在收到回应之前一次发送的数据量，会直接影响到 TCP 的性能。相反，性能又与回程时间成正比，由于协议需要（通过 ACK 包说明数据已被成功接收的信号）确保数据投送到位。在最糟糕的情况下，一个端点会等待另一端点回应数据的传输情况，从而使网络闲置的时间变长。当传输窗口变得很小时，这种现象便会发生，但此现象并不能准确反映线路速度与延迟情况。
使情况变得更加复杂的是，TCP 会根据响应速度调整自己的窗口大小。连接的距离越长，窗口就越小。假如响应的速度非常缓慢，TCP 协议就可能永远也不选择最大的窗口尺寸，这意味着许多广域网连接的完整容量永远也不可能被完全利用。因此，TCP 协议可能导致广域网性能的恶化，甚至在带宽 仍然非常充足时，性能的恶化也在所难免。同样，重传也会严重影响 TCP 的性能，要明白 1%的包丢失可能导致最多 80%的性能缺失。
TCP 应当基于系统可用带宽时延积（BDP，Bandwidth Delay Product）设定合适的接收方窗口大小。接收方通知窗口应当至少同 BDP 一样大，否则接收方的 TCP 层将对最大可用带宽造成限制。该技术...