当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

启用动态 HTTP 压缩

在各种 Web 服务器上通过动态压缩节省带宽

Alan Beal, 应用程序开发分析师, Bank One

Alan Beal 是一位分布式计算专家，擅长 WebSphere、中间件以及电子商务体系结构设计和开发。他是俄亥俄州哥伦布市 Bank One 的 Technology and Operations Division 的应用程序开发分析师。

简介： 动态 HTTP 压缩能够减少返回给浏览器的 HTML 内容量，因此它 Web 体系结构很重要。在本文中，Alan Beal 讲解如何启用动态 HTTP 压缩，从而减少产生的 HTML 内容量并提高慢速网络连接上的传输时间。

标记本文！

发布日期： 2008 年 8 月 15 日
级别： 初级
原创语言： 英文
访问情况： 1853 次浏览
评论：

HTTP 压缩和 Web 浏览器缓存是两种用来提高访问 Web 页面时的响应速度的技术。HTTP 压缩减少返回给浏览器的 HTML 内容量，而 Web 浏览器缓存减少把文件下载到浏览器的次数。在拨号连接上，HTTP 压缩可以加快 HTML 内容的传输，直接提供更好的应用程序性能。在流行的 Internet Information Services Web 服务器 5.0（IIS 5.0）中，支持对静态文件和服务器端应用程序生成的动态内容应用 HTTP 压缩。其他 Web 服务器（比如 IBM® HTTP Server 或 Apache）也提供压缩 HTTP 内容的功能。在本文中，主要介绍动态内容压缩。

压缩的历史

HTTP 压缩是在 HTTP 1.0 规范（RFC 1945）中引入的，最初支持 gzip 以及 UNIX 压缩算法 x-gzip 和 x-compress。在 HTTP 1.1 协议（RFC 2616）中，压缩得到了进一步明确和规范化，包括以下编码方案：

Gzip。文件压缩程序 gzip（GNU zip）产生的编码格式，由 RFC 1952 描述。这种格式是一种使用 32 位 CRC（Cyclic Redundancy Check）的 Lempel-Ziv 编码（LZ77）。
Compress。通用 UNIX 文件压缩程序 compress 产生的编码格式。这种格式是一种自适应的 Lempel-Ziv-Welch 编码（LZW）。
Deflate。RFC 1950 中定义的 zlib 格式，并与 RFC 1951 中定义的 deflate 压缩机制相结合。

一些压缩术语

Cyclic Redundancy Check（循环冗余校验，CRC）对数据块执行一种数学计算。它返回一个代表数据内容和组织的数字，可以认为 CRC 返回的数字惟一地标识数据，是数据的 “指纹”（称为校验和）。计算方法是，用一个生成多项式对数据执行以 2 为模的除法，记录除法的余数。

Lempel-Ziv 编码是 Jakob Ziv 和 Abraham Lempel 在 1977-1978 年提出的压缩方案。两种主要方案是 LZ77 和 LZ78。

Lempel-Ziv Welch 压缩（LZW）是 UNIX compress 命令使用的算法，可以减少存档文件的大小或提高传输效率。它是由 Terry Welch 在 1984 年设计的，用于高性能磁盘控制器中的硬件实现。这种算法依赖于输入中字节序列（或字符串）的重复出现。

LZ77 扫描一个固定长度的数据块，并用指向原始数据的指针替代重复的数据。

LZ78 扫描数据块并创建一个重复短语的词典。然后，用表示原始数据的指针替代重复的数据片段。

为了使用 HTTP 压缩，浏览器和 Web 服务器必须都支持压缩。Internet Explorer 4 和更高版本支持 HTTP 压缩，但是 Macintosh 版本除外。Netscape 4.x 支持压缩，但是有 bug。Netscape 6 支持 HTTP 1.1 和 HTTP 压缩。Opera 5 和更高版本支持 HTTP 1.1。

Microsoft IIS 5.0、IBM HTTP Server 和 Apache Web 服务器支持 HTTP 压缩。

回页首

HTTP 压缩概述

浏览器发出的 HTTP 请求时必须指定它可以接受压缩的内容，这样 Web 服务器才会发送压缩的输出。具体地说，使用 Accept-Encoding 请求头来指定浏览器可以接收压缩的输出。

清单 1 中的代码是 GET 请求中的 HTTP 头示例。在这个示例中，Accept-Encoding 头告诉 Web 服务器它接收用 gzip 压缩的输出。如果没有这个头，Web 服务器就不会在响应中返回压缩的内容。

HTTP 响应

当服务器发送回生成的内容时，Content-Encoding 头向浏览器说明压缩内容所用的格式。清单 2 是包含压缩内容的响应中的 HTTP 头示例。注意 Content-Encoding 和 Transfer-Encoding 头 —— 在 HTTP 头中没有指定内容的长度。

清单 2. HTTP 响应头

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Thu, 18 Sep 2003 17:29:44 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 1.1.4322
Set-Cookie: 
  TEST=SESSIONKEY=Ac0641be0-be5e-4be6-8f1e-b4a8d2643e33; path=/
Cache-Control: no-cache, no-store
Pragma: no-cache
Content-Type: text/html; charset=utf-8
Content-Encoding: gzip
Transfer-Encoding: chunked
Expires: Wed, 01 Jan 1997 12:00:00 GMT
Vary: Accept-Encoding

Microsoft 支持 HTTP 压缩的方式

Microsoft IIS 5.0 Web 服务器支持动态和静态内容的压缩。在考虑使用动态压缩时，管理员应该熟悉一些问题：

Knowledge Base 文章 272596 指出，在打开压缩时，过期日期设置为 1997 年 1 月 1 日。
Windows 2000 SP2 引入的一个补丁支持在 POST 上进行压缩。以前只支持对 GET 请求应用压缩（KB 文章 259760）。
在默认情况下，静态压缩只压缩 htm、html 和 txt 文件类型，动态压缩只压缩 exe、dll 和 asp 文件类型。要想添加更多的类型，必须通过运行脚本来修改 IIS 元数据库。
通过一个 ISAPI 过滤器来处理压缩。这个过滤器安装在 WWW Service 级，它是针对整个 Web 服务器（而不是特定 Web 站点）配置的。
支持 gzip（RFC 1952）和 deflate（RFC 1951）压缩方案（KB 文章 255951）。
除非安装 Windows 2000 SP3，否则总会返回压缩的静态内容，而不会返回 “HTTP/1.1 304 Not Modified”（KB 文章 307633）。

例如，在默认情况下，动态压缩并不会压缩文件类型为 aspx 的内容（ASP.Net），所以必须在列表中添加这个文件类型（KB 文章 332603）。步骤如下：

打开一个命令提示。
输入 net stop iisadmin，然后按 Enter。
输入 cd C:\InetPub\adminscripts，然后按 Enter。
输入以下命令，然后按 Enter：
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/GZIP/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
输入以下命令，然后按 Enter：
CSCRIPT.EXE ADSUTIL.VBS SET W3Svc/Filters/Compression/DEFLATE/HcScriptFileExtensions "asp" "dll" "exe" "aspx"
输入 net start w3svc，然后按 Enter。

注意，只有在浏览器发送的 HTTP 请求头包含 Accept-Encoding: gzip 的情况下，IIS 才会压缩动态内容。

把 IIS 配置为压缩 ASP.Net 内容之后，必须在服务器级启用它。在 IIS 中启用它的步骤是：访问 IIS Server 属性框并单击 WWW Service 的主属性的 Edit。然后，单击 Service 选项卡并选中 Compress application files 框。然后，应该重新启动 IIS 服务器。

回页首

IBM 支持 HTTP 压缩的方式

执行 HTTP 压缩的工作常常委托给 Web 服务器或网络设备。对于 IBM HTTP 服务器和 Apache Web 服务器，可以使用 mod_gzip 模块。在文章 “用 HTTP 压缩加快 Web 数据的发送” 中，讨论了这个模块的使用方法。

回页首

针对性能测试工具的调优

在运行性能测试时，测试工具不一定会将正确的 HTTP 头发送给 Web 服务器，使它返回压缩的内容。我在 Mercury Interactive 的 LoadRunner 和 Microsoft 的 Application Center 测试中发现，在默认情况下，它们都不向 Web 服务器发送 Accept-Encoding 请求头。

LoadRunner 不在 HTTP 请求中发送 Accept-Encoding 头，除非在脚本中添加以下行：web_add_auto_header("Accept-Encoding", "gzip");。如果不添加这一行，IIS 就不会返回用 gzip 压缩的内容。

Application Center Test（ACT）中记录的测试脚本使用 HTTP 1.0，并不发送 Accept-Encoding 请求头。ACT 似乎没有切换到 HTTP 1.1 的全局设置，所以测试无法发送这个请求头。

在执行性能测试脚本时，不要假设性能测试工具会接收压缩的 Web 页面。

回页首

HTTP 压缩性能测试结果

为了提供压缩性能的测试示例，我使用一个访问三个 Web 页面的典型应用程序测试了 IIS 5.0 动态压缩。我记录了压缩和未压缩的 Web 页面大小。测试使用 Shunra Cloud 产品模拟 28.8K 和 56K 线路的速度（这种产品在计算机上模拟一个网络链接，使用户可以测试基于 IP 的技术在各种条件下的性能，可模拟的条件包括延迟、数据包损失、抖动和带宽约束）。下表给出基于实际 Web 页面大小的响应时间算术差。

表 1. HTTP 压缩性能

	内容大小（字节）	线路速度（Kbs），传输时间（sec）
	内容大小（字节）	14.4	28.8	56	128	256	348
未压缩	64975	35.25	17.63	9.06	3.97	1.98	1.46
压缩	17478	9.68	4.74	2.44	1.07	0.53	0.39
差	47497	25.77	12.88	6.63	2.90	1.45	1.07
节省（百分数）	73.1

下面的图表说明，对于这么大的 HTML 内容，压缩会对 128K 或更低速的线路上的传输时间产生积极影响。对于更高速的线路，用户可能不会注意到性能差异。

图 1. 压缩对传输时间的影响

上面的表和图给出的是动态压缩在理论上的性能结果。我在实验室中用 Shunra Cloud 模拟 28.8K 和 56K 线路得到的响应时间结果与理论结果相符。当然，压缩应该会增加 Web 服务器上的 CPU 资源消耗；但是实验室测试表明，这个影响很小，差不多只增加 2%~3% 的 CPU 使用率。

以上结果随线路速度和 Web 页面大小变化，而且并不是 IIS 特有的结果；在任何 Web 服务器上都应该会得到相同的结果。

回页首

可以替代动态压缩的产品

除了 IIS 动态压缩之外，还可以在网上找到许多支持 HTTP 压缩的产品。这些产品分为两大类：ISAPI 过滤器和外部设备。ISAPI 过滤器十分常用而且便宜，并提供有选择地压缩内容的各种特性。外部设备通常是提供 HTTP 压缩特性的网络设备。

这些替代产品包括：

PipeBoost 是一种 ISAPI 过滤器，每个企业许可证需要支付 $1,500。
Packeteer AppCelera.ICX 是一种放在负载平衡器和 Web 服务器之间的网络设备。
NetScaler 是一种提供包括压缩在内的多种功能的网络设备。
HttpZip 是一种 ISAPI 过滤器。
注意： Cisco 已经停止支持 Content Optimization Engine。

回页首

另外几个考虑因素

考虑 Web 页面的响应时间时，要注意以下几个问题：

慢速线路上的 Web 页面传输大小。通过使用动态压缩，可以把 HTML 页面的大小减少 70%。压缩不影响 HTTP 头；只对内容进行压缩。
Secure Sockets Layer 加速。如果 Web 站点有许多启用 SSL 的 Web 页面，可以考虑使用外部的 SSL 加速设备。
静态页面缓存。大多数 HTML 引用 JavaScript（js）、层叠样式表（Cascading Style Sheets，CSS）、XML、GIF 和 JPG 文件。浏览器在首次访问这些文件时会缓存它们，所以浏览器两次下载了这些文件：首次访问时以及修改文件之后。但是，浏览器总会用 GET HTTP 请求向 Web 服务器请求这些文件，Web 服务器则会以 “HTTP/1.1 304 Not Modified” 作为响应。所以总是询问 Web 服务器这些文件是否已经修改。继续阅读了解更多的细节。

回页首

用于静态文件的 HTTP 请求和响应头

为了便于参考，清单 3 给出对静态文件的 HTTP 请求和对浏览器缓存的静态文件的 HTTP 响应。注意，请求头比响应头大得多。

对于浏览器中缓存的内容，会出现这些 HTTP 请求头和响应头。假设一个 Web 页面包含 10 到 12 个对静态文件的引用。慢速网络连接仍然会影响响应时间，因为这些请求头和响应头的传输要花几秒时间。如果静态文件的引用数量很多，那么应该考虑尽可能减少引用数量。

回页首

结束语

如果 Web 服务器和浏览器之间的网络线路是慢速的，那么使用动态 HTTP 压缩会对大多数 Web 站点的传输时间产生积极影响，而且对服务器的消极影响不大。如果要传输的页面比较大（大于 100K），那么压缩可能对快速线路也有好处。对于静态内容，由于浏览器可以缓存这些文件，所以使用 HTTP 压缩可能没什么好处。但是，即使浏览器缓存了静态文件，在浏览器和 Web 服务器之间也会发送请求和响应，这在慢速线路上会降低响应速度。在这种情况下，明智的做法是减少 Web 页面中对静态内容的引用数量，或者考虑在接近用户的地方设置缓存服务器。

参考资料

您可以参阅本文在 developerWorks 全球网站上的英文原文。
阅读 WebReference 上的一篇文章，了解为什么要使用压缩提高 Web 传输速度。
通过阅读 “用 HTTP 压缩加快 Web 数据的发送”，了解 Web 压缩，研究 HTTP 压缩的好处，学习几种压缩工具，并通过一个案例研究突出压缩技术的效果（developerWorks，2003 年 7 月）。
通过阅读 “A data compression primer”，了解数据压缩的基本类型以及压缩技术涉及的数学知识和算法（developerWorks，2001 年 5 月）。
参阅 HTTP 1.1 协议。
获取关于 WebSphere® Application Server 的信息并下载试用程序的 5.1 版。
如果您正在使用 MS，但是希望有更多开放源码选择，那么可以用 J-ASP 把 ASP 应用程序迁移到 J2EE 平台。
浏览关于这些主题和其他技术主题的图书。
查阅本文提到的网络设备和 ISAPI 过滤器的相关信息，它们专门用于支持 Web 内容压缩：
- PipeBoost 最初为 ASP 而设计，但是也可以加快 JSP 的速度。
- Packeteer 的 PacketShaper Xpress 网络设备。
- NetScaler 的网络设备。
- HttpZip 的 ISAPI 过滤器。
- 注意：Cisco 的 Content Optimization Engine 已经停止支持了。