Web 应用的 HTTP 压缩

高级应用开发人员 ChandraMohan Lingam

HTTP 压缩：充分释放 Web 服务器的潜能，缩短应用响应时间并降低带宽成本。

当前的网站内容极其丰富，而且还具备类似于全功能客户机应用的多种能力。提供丰富内容会带来一个令人头疼的副作用－－增加页面尺寸。在大多数情况下，响应能力是决定 Web 应用能否取得成功的一大因素。保持站点响应能力的最佳方法就是最大限度缩小下载页面的尺寸。考虑到页面中的大部分内容均为文本数据，HTTP 压缩便成为了缩短响应时间的理想方法。用压缩算法处理文本数据十分有效，压缩率可达到 70% 至 80%。在本文中，我将阐述关于 Internet Information Services* 6.0 压缩如何提高整体性能的一些观点，同时针对下列方面的相关影响回答一些问题：

• CPU、网络利用率
• 应用吞吐率（每秒请求数量）
• 响应时间
• 静态与动态应用
• 支持 SSL 的站点

技术

Microsoft IIS 6.0, HTTP, ASP.NET*

尽管我们可能希望衡量压缩对于特定应用的影响，但需要了解的是，我们实际上衡量的却是压缩对于服务器资源的影响。明确这一点之后，我们将使用一个样本应用，观察其在进行压缩操作前后的性能。此外，我们还将使用相同的应用，观察其在使用 SSL 前后的性能。

为了衡量压缩造成的影响，可以观察以下方面：

压缩算法的效率在很大程度上取决于文件内出现的重复模式。值得注意的一个有趣现象是：加密内容永远不能进行压缩。在下文评审 SSL 压缩性能时，我们还将讨论这一主题。下表简要介绍了一种压缩算法（如 gzip）针对各种文件类型的效率。



表 1. 压缩效率

我们首先快速回顾一下数据如何穿越网络。在非常高的级别上，当需要传输一个数据时，该数据首先要在机器中排队（排队延迟）。队列数据由网络控制器传输到网络上，而数据真正被推送到网络上需要一些时间（传输延迟）。源头与目的地之间的实际距离、涉及到的跃点数量和通信媒介（光纤、同轴电缆、微波、卫星等）均会影响数据到达目的地所需的时间（传播延迟）。为了提供可靠的网络通信，TCP/IP 协议采用了数据包确认、中继和开窗操作（windowing）机制。根据网卡的能力，主机处理器将不再共同承担一些网络通信责任。我们拥有的数据越多，传输开支和遗失数据包的可能性就越高。

在利用 HTTP 压缩* 部分，会详细描述有关 IIS 压缩对于静态文件的行为。在支持静态文件压缩时，静态文件将根据要求进行压缩并保存在临时文件夹中。压缩内容将重新用于该文件的后续请求。



图 2. 静态文件压缩效率

上图比较了使用和不使用压缩方法的页面尺寸。压缩率可以达到 72% 至 88%。除缩小页面尺寸外，启用压缩之后，Web 服务器吞吐率可提高 66% 至 900% 不等（参见图 3）。

图3. 静态文件吞吐率

表 2. 静态文件

需要注意的重要一点是：尽管服务器要花费额外的 CPU 周期来压缩数据，但完成一次压缩之后，便可将压缩数据重复用于所有其它请求。启用压缩后，CPU 利用率降低了大约 60%。客户机的页面下载时间缩短了 40% 至 50%。

通过动态扩展，针对每个请求的页面响应都是独一无二的，且响应均在每次调用时进行压缩。显然，服务器必须进行大量的额外处理。与静态文件中的情况一样，实现的压缩率在 70% 至 85% 之间。

图 4. 动态文件压缩效率

图 5 对使用和不使用压缩方法的应用吞吐率进行了比较。结果表明，启用压缩后服务器可处理更多请求，同时整体吞吐率也提高了 30%，达到 190%。


图 5. 动态文件吞吐率

表 3. 动态文件

进行压缩后，CPU 平均利用率提高了 25% 至 35%。与静态文件一样，客户机的页面下载时间缩短了 40% 至 50%。

关于 SSL 的情况需要解释一下。加密数据的一个副作用是加密结果似乎是以随机的字节顺序输出。当存在重复的数据模式时，加密的效果最佳，但很不幸，加密把这种模式打乱了。如果压缩在 SSL 加密之后进行，则我们可能只能获得 5% 的压缩效率。幸运的是，HTTP 压缩方案的设计者考虑到了这一点，从而可确保在加密之前进行压缩。SSL 加密是一项处理器密集型操作。即使压缩文件需要消耗一些资源，但加密只有原有文件尺寸部分大小的小型文件可以节省更多的资源。因此逻辑上，进行压缩和加密所造成的影响非常小。

 

 
图 6. SSL 和压缩流程

 

图 7. 采用 SSL 的静态文件吞吐率

通过静态文件，即使服务器重复使用压缩数据，也仍然必须为每个请求执行加密。对于较小的文件，加密开销很少，而吞吐率却可以提高 30% 至 40%。大型文件则可以提高 15% 至 20%。支持压缩之后，CPU 利用率下降了 20%。

表 4. 采用 SSL 的静态文件



图 8. 采用 SSL 的动态文件吞吐率


表 5. 采用 SSL 的动态文件

对于动态文件，进行压缩后，应用可以处理更多小尺寸页面的请求。对于较大的页面尺寸，吞吐率比较平稳。由于支持 SSL 连接上的压缩，CPU 利用率可提高 10% 至 20%。整体页面尺寸缩减了 70% 至 80%。

使用 SSL 的 Web 站点可以安全地启用 HTTP 压缩，因为它对服务器资源的影响最小，同时可以显著缩小页面尺寸。

迄今为止，我们已了解了压缩的诸多优势。现在我们来看看启用 IIS 中压缩时出现的一些问题。第一个问题就是压缩功能的启用或禁用发生在机器层面上。在一台设备内，您不能在具体的 Web 站点上选择性地启用/禁用压缩。

第二个问题是关于缓存压缩数据。此处讨论的缓存是指代理和浏览器高速缓存上基于 HTTP 标头的高速，而不是 ASP.NET 缓存。通常，内容可以在几个点上进行缓存：反向代理、客户机代理和浏览器。并非所有内容都适合在代理上进行缓存。例如，SSL 响应从不在代理中进行缓存；反之，浏览器可以选择缓存 SSL 响应。虽然通过在本地处理文件，高速缓存可以明显提高下载速度，但对压缩内容进行缓存仍然存在几个问题。

当前的 IIS 压缩部署不能对高速缓存响应进行精密控制。您可以选择使用 metabase.xml 中的 HcSendCacheHeaders 节点来开/关高速缓存标头。请参考 MSDN 文件了解关于每项设置的更多帮助信息。

<IIsCompressionSchemes	Location ="/LM/W3SVC/Filters/Compression/Parameters"
		HcCacheControlHeader="max-age=0"
		HcExpiresHeader="Wed, 01 Jan 1997 12:00:00 GMT"
		...
		...
                ...
		HcSendCacheHeaders="FALSE"
	>

            

IIS 压缩内容高速缓存模式会迫使您在 Web 服务器级别，而非 Web 应用级别制定各项政策。一项全面的高速缓存方案永远不会为应用工作，也不会为托管几个 Web 应用的 Web 服务器工作。如果您配置错误，可能会发现动态响应的缓存时间要长于预期时间。例如，您可能会看到一天前的股票报价，或者重复下载较大的图像。一个选择就是禁用压缩例程所设置的高速缓存指令 (HcSendCacheHeaders=FALSE) 并在程序上控制所有面向动态文件的高速缓存指令。另一个选择是支持高速缓存指令，并确定没有缓存动态压缩内容 (HcSendCacheHeaders=FALSE 且 HcCacheControlHeader="max-age=0")。第三个选择是只压缩动态应用文件，不压缩静态文件。这样，您将获得压缩全部动态响应的优势，并可充分利用代理上的高速缓存静态文件。感受一下哪种方案对您的应用效果最佳，并做出相应的选择。

Metabase.XML 压缩设置：

高速缓存指令	目的
HcSendCacheHeaders	明确说明 HcCacheControlHeader 和 HcExpiresHeader 指定的标头是否随着每个压缩响应一同发送。
HcCacheControlHeader	指定 IIS 添加至高速缓存控制（Cache Control）标头的相关指令。HcCacheControlHeader 属性指定一个标头来超越 HTTP Expires 标头。 如果元数据库属性（metabase property）HcSendCacheHeaders设置有误，则HcCacheControlHeader和HcExpiresHeader指定的标头均不会随响应一同发送。 使用方法： 用于未进行高速缓存的数据的指令 HcCacheControlHeader="max-age=0" 用于进行 1 天（86400秒）高速缓存的数据的指令 HcCacheControlHeader="max-age=86400"
HcExpiresHeader	指定随所有必要压缩文件一同发送的 HTTP Expires 标头，以及 HcCacheControlHeader 中所述的高速缓存控制（Cache Control）标头的内容。 HcExpiresHeader 与 HcCacheControlHeader 的组合可确保旧客户机和代理服务器不会尝试缓存压缩文件。 使用方法： 用于不缓存绝对过期（absolute expiration）数据的指令： HcExpiresHeader="Wed, 01 Jan 1997 12:00:00 GMT"

• 压缩非常适合文本内容（参见表 1）。对于图像，不应采用 bmp 格式，而应选择更加有效的格式，如 jpg, png 等。Jpg 和 png 格式均经过优化和压缩，您可以在 IIS 压缩中不包含这些扩展名。
• 分析您的 Web 站点通常处理的数据类型。确定通过什么方式可以使压缩能够带来最大的优势。使用 IIS Log 文件来验证所生成的响应规模。配置 IIS 6.0，指定希望用于静态和动态压缩的文件扩展名。
• 在 Metabase.xml 中选择压缩级别，以优化速度或尺寸。推荐值不超过 9。

当前的英特尔® 至强® 处理器和英特尔® 安腾® 处理器均十分强大。对于经常与数据库进行交互的典型 Web 站点而言，在这些处理器中很少能看到较高的 CPU 利用率，因为大部分限制都存在于网络或其它 IO 设备中。您恰好可以借助压缩来利用“未使用的”CPU 容量，以扩展基础设施。除缩小页面尺寸外，进行压缩后，应用还能够处理更多页面。文件更小了，Web 服务器使用的带宽也更少，网络传输也就更迅速，从而可大幅节省网络基础设施成本。

从 IIS 实施的角度看，用于压缩的管理代码是核心 IIS 6.0 Web 服务器的一部分，决定着速度和稳定性。在 IIS 4 和 IIS 5 中，压缩是带有限制的 ISAPI 过滤器（参阅“参考信息”）。

• 指导：在 IIS 中实现 ASPX压缩*
  
  
• 通过 Windows Server 2003* 实现 IIS 6.0 压缩：达到事半功倍的效果*
  
  
• MSDN 高速缓存标头帮助文档*
  
  
• Web 站点加速的基础*
  
  
• RFC 1951 ― DEFLATE 压缩数据格式规范 1.3 版*
  
  
• RFC 1952 ― GZIP 文件格式规范 4.3 版*

ChandraMohan Lingam（Chandra）是英特尔公司的高级应用开发人员，专门致力于各种性能调节器应用的开发，旨在提高应用的速度和响应能力，同时支持大量并发用户。Chandra 对于各种微软技术和 Linux* 拥有超过 7 年的丰富开发经验。

特别感谢下列审阅人员：Thiru Thangarathinam、Jay Turpin、Patrick Logan、Tom Fieldhouse 和 Brandon Bohling。