用 HTTP 压缩加快 Web 数据的发送(转)

用 HTTP 压缩加快 Web 数据的发送       

 

HTTP 压缩，HTTP 1.1 协议规范的一种建议，用来改进页面加载时间，它要求在 Web 服务器上实现压缩特性并在浏览器端实现解压缩特性。虽然早在几年前，流行的浏览器大都能接收压缩数据，但 Web 服务器却不能发送压缩内容。服务器压缩模式出现以后，状况获得了改善。S.Radhakrishnan 博士剖析了 Web 压缩，考察了 HTTP 压缩的益处，提供了几个压缩工具并用案例突出展现了该技术的有效性。

 

不少 Internet 应用程序都以动态生成的 HTML 格式发布内容和数据；HTML 动态内容由 Web 或应用服务器经过 Java Servlet、JavaServer Pages、Personal Home Pages（PHP）、Perl scripts 或 Active Server Pages（ASP）等技术生成。请求发出后，Web 页面在客户浏览器上的速度主要取决于两个因素：

• Web 或应用程序服务器生成内容的能力。这与此应用程序和服务器的性能有关。
• 网络带宽。

Web 应用程序的性能取决于设计的好坏，若是须要，能够经过为服务器提供更多硬件功能来优化应用程序的性能。用户可用的网络带宽直接关系到页面下载时间，这一点经常被认为是理所固然的。但对于用户而言，性能水平主要体如今 Web 页面呈现的速度，而非应用程序在服务器上执行的速度。

所以，要得到好的用户体验，网络的性能及其带宽被认为是应用程序总体性能的重要部分。若是网络速度慢、网络流量大或者 Web 页面较大，这就显得更加剧要了。

在 Internet 上，网络流量经常没法控制，但用户网络部分（Modem 或其余技术）及服务器到 Internet 的链接都是能够调节的。若是 Web 应用程序经过 Local Area Networks（LAN）就近托管和访问，带宽一般可以知足快速下载页面的需求。在 Wide Area Networks（WAN）上，网络的速度可能很慢，而且流量大，在这种状况下，用户可能会感到页面下载的速度很慢。

若是能增长网络带宽固然很好；但实际上，这样会增长额外成本。不过，带宽的增长也能够在低投入的状况下实现。若是所请求的 Web 页面（只包含纯文本文档和图像）可被压缩并交付给浏览器，页面下载速度就会获得改善，而无需 考虑网络流量或速度。用户 HTTP 请求的响应时间也会加快。

在本文中，我会探索基于 Web 的压缩技术细节，详尽阐释如何经过在服务器上压缩 Web 页面，提升下载速度。此外，还重点介绍了这种技术的当前情况，并提供了真实的案例学习，借此展现一个项目的特定要求（在本文中，术语 Web 应用程序 指的是能生成动态内容的应用程序）。

首先，先来看看与 Web 压缩技术相关的细节。

压缩类型

压缩的各类类型和属性以下：

• HTTP 压缩：压缩来自 Web 服务器的内容
• Gzip 压缩： 一种无损失的数据压缩格式
• 静态压缩：预压缩，用于发送静态页面
• 内容及传输编码：IETF 用于压缩 HTTP 内容的两级标准

HTTP 压缩

HTTP 压缩是一种用于压缩来自 Web 服务器（HTTP 服务器）的内容的技术。Web 服务器内容的格式能够是诸多 MIME 类型中的一种：HTML、纯文本、图像格式、PDF 文件等。其中 HTML 和图像格式是在 Web 应用程序中最经常使用的 MIME 格式。

Web 应用程序中使用的大多数图像（例如 GIF 和 JPG）已是压缩过的格式，无需进一步压缩；即便再压缩，性能也不会有大的改善。然而，静态或动态建立的 HTML 内容只包含纯文本，适合进行压缩。

HTTP 压缩的目的是使 Web 站点发送更少的数据。要有效实地现这个目的，须要如下条件：

• Web 服务器应该可以压缩数据
• 浏览器应能解压缩数据并以正常的方式显示页面

这是很明显的。固然，压缩和解压缩的处理不该消耗大量的时间或资源。

这个看似简单的过程的 “路障” 是什么呢？HTTP 压缩的建议是 IETF（Internet Engineering Task Force）在指定 HTTP 1.1 协议规范时给出的。目前被普遍使用的 Gzip 压缩格式将成为一种压缩算法。流行的浏览器已经实现这种特性，而且已经能接收编码后的数据（根据 HTTP 1.1 协议规范）。可是，Web 服务器端的 HTTP 压缩功能却未能如此正式或迅速地实现。

Gzip 压缩

Gzip 是一种无损失的数据压缩格式。gzip（也称 zip 或 zlib）所使用的算法是开源、无专利的 LZ77（Lempel-Ziv 1977）算法的变体。

该算法寻找输入数据内的重复字符串。二次出现的字符串由一个指向前一字符串的指针（以对的形式 -- 距离和长度）代替。其中，距离限定为 32 KB，长度限定为 258 字节。若是字符串没有在这前 32 KB 内出现，它就会做为文字字节序列发出（这里所说的字符串 定义为随意字节序列，并不只限于可打印的字符）。

静态压缩

若是 Web 内容是预生成的而且不须要与其余系统进行服务器端动态交互，那么内容就能够被预压缩并放置在 Web 服务器内，而这些压缩了的页面则被发送给用户。流行的压缩工具（gzip、Unix compress）都可压缩这些静态文件。

可是，当内容必须动态生成，好比对于电子商务站点或由应用程序和数据库驱动的站点，静态压缩没有什么用处。更好的一种方式是动态压缩数据。

内容和传输编码

IETF 用来压缩 HTTP 内容的标准包括两级编码：内容编码 和传输编码。内容编码是指在 Web 用户请求文档以前就已经应用到这些文档的编码和压缩方法。这也被称为预压缩 或静态压缩。因为存在复杂的文件维护负担，这个概念历来没有获得真正的重视，并且使用预压缩页面的站点也不多。

而传输编码是指实际数据传输过程当中的编码方法。

在如今的实践中，内容和传输编码的界限已经很模糊，缘由是所请求的页面只有被请求后才会存在（它们是实时生成的）。所以，编码必须也是实时的。

受 IETF 建议的启示，浏览器在 1998 年到 1999 年期间实现了接受编码 特性。这让浏览器可以接收和解压缩使用公共算法压缩后的文件。在这种状况下，来自浏览器的 HTTP 请求头字段代表此浏览器能够接收编码信息。当 Web 服务器接收了此请求时，它能：

1. 按请求发送预压缩文件。若是文件不可用，它应能：
2. 压缩所请求的静态文件，交付压缩了的数据并将压缩文件保存在一个临时目录以备未来请求；或
3. 若是已经实现传输编码，就动态压缩 Web 服务器的输出。

正如我提到的，预压缩文件以及 Web 服务器所进行的静态文件的实时压缩 （上述两点）因为文件维护的复杂性从没有获得真正的关注，但一些 Web 服务器在必定程度上也支持这类功能。

压缩 Web 服务器的动态输出直到最近才获得真正的重视，由于其重要性刚刚被人们发现。所以，在这以前，即便不少浏览器都可以接收压缩格式，经过网络发送动态压缩后的 HTTP 数据一直没有实现。

三项独立的研究（两个由 W3C 完成，另外一个由 Mozilla 完成）展现了 HTTP 压缩的各类益处。1997 年的第一个 W3C 研究的重点是测试 HTTP 1.1 持久链接、管道性和连接级文档压缩的效果。2000 年的第二个 W3C 研究侧重的是在 LAN 上使用 HTML 文件压缩以及 HTML 数据（压缩）和图像内容（未压缩）混合可能带来的性能好处。1998 年针对 Mozilla 的研究关注的是内容编码压缩的性能。

如下是这些研究成果的一个简单总结，从中能够看出 HTTP 压缩的优势。（本文并无充分讨论这些研究成果；要得到完整的讨论，能够参考原始的研究资料。要获得更多信息，请查看 参考资料 中的相关连接）。

W3C：HTTP 1.1 的性能

此研究使用了两个 Web 服务器：Jigsaw 和 Apache，并给出了所节省的 发送包（Pa）以及 以秒为单位的下载时间（Sec）的数目。该研究使用了一个 28.8 kbps 的 modem 和没有包含任何图像的 HTML 文件。

表 1 给出了压缩比和下载时间。

表 1. 压缩比和下载时间

	Jigsaw Pa	Jigsaw Sec	Apache Pa	Apache Sec
未压缩的 HTML	67	12.21	67	12.13
压缩了的 HTML	21.0	4.35	4.35	4.43
使用压缩后的节省（百分比）	68.7	64.4	68.7	64.5

 

W3C：LAN 上的压缩效果

该项研究涉及了图像和 HTML 内容的混合。以未压缩格式传输的总负荷为 42 KB 的 HTML 文件和共计 125 KB 的 41 个内联 GIF 图像。压缩后，HTML 页面的大小从 42 KB 减小到 11 KB（73.8 %的压缩比），而图像则没有动。这意味着整体的负荷减小了 31 KB，即大约 19%。

表 2 给出了如下内容：

表 2. 图像/HTML 混合状况下的压缩比和下载时间

	Jigsaw Pa	Jigsaw Sec	Apache Pa	Apache Sec
管道处理	167.4	0.85	161.6	0.64
管道处理和 HTML 压缩	140.6	0.62	137.4	0.49
使用压缩后的节省（%）	16	27	15	23

 

该研究的做者指出，

对于 Jigsaw 服务器，压缩使包数减小了 15%，但时间却增长了 27 %。对于 Apache，包增长了 16%，时间也增长了 23%。有趣的是总体负荷减小了19%，这比改变 TCP 包数更有效。从这个角度看，压缩带来了不是很满意 “TCP 包使用”。不过，时间上的增长相对好于负荷上的增长。这代表负荷、TCP 包和传输时间之间的关系并非线性的，并且第一个链接上的包比其余包更耗资源。

Mozilla：内容编码压缩的性能

第三个研究针对 Mozilla，使用了 Apache Web 服务器版本 1.3，该版本可以为了内容编码解析 HTTP 头、接收编码 gzip 并能向浏览器发送预压缩的 HTML 文件。

表 3 给出了只发送纯 HTML 而不发送图像时的状况。很明显，在网速较慢时下载时间有所改善。

表 3. 只有纯 HTML 的 Mozilla 和 Apache

ISDN	64 kbits/秒		28.8 kbits/秒
	无 GZIP	GZIP	无 GZIP	GZIP
	105.1	83.2	327.9	121.8
		增快 21%		增快 63%

 

图像和 HTML 混合的结果则如表 4 所示。

表 4. HTML 和图像混合

ISDN	128 kbits/秒		28.8 kbits/秒
	无 GZIP	GZIP	无 GZIP	GZIP
	82.1	77.6	264.7	184.4
		增快 5.5%		增快 30%

 

解读结果

从这些研究不难看出，好的压缩比是可能的，并且也能够经过 HTTP 压缩加速 Web 内容的下载时间。这些研究使用 HTML 和图像的混合，图像占负荷的很大一部分而且在下载时间上有 20 到 30 % 的改进。当负荷只包含 HTML 内容时，下载时间能够加快将近 65 %。

很明显，对于那些图像（大部分是按钮）较少，HTML 内容较多的 Web 应用程序，下载时间的总体改进将接近 65%，而不是 20 或 30 %。这些研究代表在 Web 应用程序中部署 HTTP 压缩能够加速下载并改善用户体验。

HTTP 压缩的另外一个间接的好处是 Web 服务器和浏览器间的数据传递是由压缩算法的 virtue 加密的（虽然它并不是十分强大的加密)，这为数据增长了安全性。固然，从浏览器到服务器发送的数据并未压缩，于是没有携带这种额外的加密。

HTTP 压缩的益处一直都备受争议，虽然早在 1998 年，流行的浏览器都已实现了这个功能，但该技术在 Web 服务器端的实现却有些落后。

Apache Web server 1.3 能够向浏览器传递预压缩的静态数据。Microsoft Internet Information Server 5.0（IIS）则能在静态页面首次被请求时压缩此页面，而且可以将压缩内容存储于缓存目录内。当同一页面再次被请求时，服务器从临时目录中，而不是从 Web 服务器文档目录中传输页面。任何被置于 Web 服务器（其压缩内容已存在于缓存目录中）的新的静态内容都将被自动压缩，而且这个缓存目录也会被最新的内容更新。另外，在 IIS 5.0 中也能够启用动态内容压缩功能。

虽然大多数 Web 服务器供应商对引入动态压缩功能犹豫不决，但其余一些公司已经开始为流行的 Web 服务器生产压缩插件。如下列举一些有前景的产品。

mod_gzip

Remote Communications 公司已经引入了第一个适用性很强的压缩模块，可用于 Internet 上使用最为普遍的 Apache Web 服务器。该模块构建于 Apache 的添加模块 规范之上，根据此规范，第三方模块能够与 Apache 产品相集成。该模块名为 mod_gzip，使用了普遍可用的 gzip 算法来压缩从 Web 服务器传来的数据。

自从该模块引入以来，它获得了 Web 服务器用户开源社区的普遍承认，并且也不断有新的版本和修复出现。不少人都认同使用 Apache Web 服务器能够获得很好的压缩比。此产品的基准测试结果已经可用。

Hyperspace

这是 mod_gzip 建立者建立的商业版本压缩模块。与 mod_gzip 不一样，Hyperspace 产品压缩模块不须要与 Web 服务器集成并可用于任何 Web 服务器。该产品经过使用额外端口（Web 服务器和压缩产品都要侦听这些端口）来与基础 Web 服务器进行交互。

如下是 Hyperspace 模块的一些特色：

• 产品能够安装在远程主机，与 Web 服务器主机分开
• 具备针对 HTTP 访问和压缩统计数据的定制日志条目
• 单独的 admin 服务器用来显示实时的压缩统计数据，显示发送和保存的总字节数
• 可以指定要压缩的内容类型
• 能够进行图像压缩

该产品的 SSL 版本已经可用。

Vigos Web 站点加速器

它是 Vigos AG 公司的商业产品，这个软件工具（该公司也提供硬件版本）也能动态压缩 Web 服务器响应。基于专有的 SmartShrink 技术，Vigos 加速器能够决定浏览器是否可以接受压缩数据，并且还能发送适当的压缩和未压缩的数据。该产品亦能充当独立单元，所以也能用于任何的 Web 服务器。此产品的基准测试结果已经可用。

Vigos 加速器的主要特性以下：

• 该产品能够用做远程主机，与 Web 服务器分开
• 自动判断浏览器可否接受压缩文件
• 具备针对访问和错误日志以及压缩统计数据的定制日志条目

该产品的 SSL 版本已经可用。

WebWarper

这是一种免费的 Web 服务，经过它可访问 Web 站点的内容。虽然该服务听起来颇有趣，但由于 IP 转发上的潜在延时以及对客户端插件的须要（未来自 Web 页的 URL 条目更改成由加速器转发），使得该服务不太适合 Web 应用程序。不过，普通的 Internet 用户仍是能够从该服务受益的。

该公司也有用 Perl 编写的付费模块，专门为 IIS 和 Apache Web 服务器的 HTTP 压缩设计。

注意： 针对 Apache 的 HTTP 压缩可使用开源 mod_gzip 实现。不过，对于其余未能实现 HTTP 压缩的 Web 服务器，可能须要商业产品。

如下给出了一个使用 mod_gzip 的实际案例研究。

 

一家大公司（TCS的一个重要客户）的一个主要部门有个遗留应用程序，须要为之开发一个基于浏览器的用户界面。 这个应用程序的现有逻辑位于一个基于 OS390 的系统内。公司的 IT 人员为公司全部基于 Web 的应用程序选择一台使用 IBM HTTP 服务器（以及其余一些负载均衡和安全产品）的 WebSphere 应用服务器。这个环境将被用来托管由公司任一部门开发的任何基于 Web 的应用程序。

这个开发中的应用程序是公司的一个关键在线模块，供遍及世界的该公司的销售和客户服务表明使用。客户表明在与客户进行电话沟通的同时须要可以访问此应用程序来接收和更新针对该客户的信息（好比订单状态、历史记录或 ID）。此应用程序的响应时间必须很短：规定为发出指令后 3 秒内。

充分挖掘服务器自身的能力 能够加强应用程序的性能：更多服务器和负载均衡、更强的 CPU 处理能力和更多的 RAM。一样地，应用程序设计也能调优性能：更少的对象建立、实时的数据库优化以及使用数据库链接池。让咱们假设这些关注点都能由服务器群的体系结构及应用程序设计获得妥善处理。

此应用程序将被置于一个 WAN 上，并且有些网段的带宽只有 8 kbits/秒，因此对于用户而言，网络对于 Web 页面的缓慢传递抵消了在服务器上所得到的性能改进。

最好的解决方案是什么？

考虑到须要一个基于 Web 的 UI，以及要对难以控制的网络带宽和流量做出快速响应，下面是根据这些要求逐级筛选：

1. 因为一个 Web 页相似于一个 HTML 文件，既包含数据又包含格式化信息，并且后者大于前者，因此只有数据能够向下发送给浏览器。这能够经过在浏览器端部署 applet 来实现。不过，因为如下缘由，不鼓励使用 applet：
   • 不少客户浏览器都运行于本地防火墙以后，这些防火墙可以限制外来访问。为 applet 进行这些位置的配置超出了组织自身的权限。
   • 不少用户都不喜欢复杂客户应用程序的外观。
   • Java 支持是执行这些 applet 所必需的，应该置于客户机，这就须要安装和维护合适的 JVM。
2. 因为使用 applet 并不是理想的状况，因此经过网络发送的数据越少就越能改进页面下载的速度（或 HTTP 压缩）。
3. 若是带宽极低，即便使用 HTTP 压缩也无济于事。因此公司决定更新或丢弃那些速度低于特定限值的网段。该值被设定为 32 kbits/秒。将建议位于丢弃段的客户直接从 Internet 访问此应用程序。

简单的算术

咱们所考察的这个 Web 应用程序的一个典型的 Web 页面由大小 8 到 15 KB 的页面（不包括图像）组成。有些信息页可能长达 25 KB，但这种状况在此应用程序中不多发生。以一个 8 KB Web 页面、单一用户和一条 32 kbit/s 的线路为例，咱们发现：

下载时间 =（8*1024 字节）/（32*1000/8 字节/秒）= 2.048 秒 （忽略网络延时以及由 Web 服务器和浏览器带来的任何延时）

假设由应用服务器和主机系统进行处理须要约 1.5 秒，Web 页面不能在 3 秒内发送到浏览器。此外，若是不少用户都使用同一条线路，流量将会很高而且在线路内也减小空间，结果是对全部用户的响应时间都会变慢。

若是同一页面可以压缩 50 %，那么下载时间就会减半。并且，其余用户也可使用节省下来的带宽。

很明显，从用户的角度看，为此应用程序应用 HTTP 压缩可以加强性能。

理想的行为

若是在 Web 服务器上启用 HTTP 压缩，而此 Web 服务器托管于一个复杂的联网服务器群环境并由固定用户访问，那么此压缩产品将须要具有如下行为：

• 该产品不须要任何浏览器端插件。
• 该产品具备容许和禁止特定 MIME 类型的特性。并非全部内容类型都要自动压缩。例如，有些浏览器可能不能正确解析压缩了的 JavaScript 和 Cascading Style Sheet（CSS）文件。一样，可能也不该该压缩 PDF 文档和 HTML 帮助文件。
• 该产品不该消耗服务器环境的大量计算能力和时间。内存消耗应该较小。
• 该产品应该容许压缩来自特定目录和 URL 的文件。当一个联网环境内托管多个应用程序，并且只有来自特定应用程序的内容须要压缩时，此特性尤为重要。
• 该产品应该容许自动健康检查 以判断压缩特性是否工做正常。除了日志文件外，还须要能用浏览器显示运行时统计数据。
• 该产品应该提供额外的图像压缩特性，即便 Web 页内使用的图像已是压缩格式。

所以，产品制造商应该提供很好的支持。

下一步：寻找合适产品

衡量利弊以后，公司决定为此 Web 应用程序使用 Web 服务器和 HTTP 压缩。所选的服务器，在本例中使用的是 IBM HTTP 服务器，具有 WebSphere 环境。但这里有个问题：IBM HTTP 服务器自己并不支持 HTTP 压缩。

因为 IBM HTTP 服务器是 Apache 服务器的克隆，因此很天然想到使用可免费得到的 mod_gzip 模块。可是这行不通，由于 IBM HTTP 服务器的编译二进制文件内使用的头文件（core.h）与原始的 Apache 头文件是不一样的。因为这种不兼容性，mod_gzip 二进制文件不能用于这个 HTTP 服务器。（在本文的稍后的部分，您会找到解决此问题的方法）。

在决定为一个项目应该选择哪一个技术产品或版本时，作一次特性研究不失是个好方法。我进行特性研究，对比了 mod_gzip 模块（使用 Apache Web 服务器）和另外两个商业产品（使用 IBM HTTP 服务器）各自的优点。我发现 这两个商业产品虽然可以提供较好的压缩比，但不能提供有利于项目目标的任何明显优点。所以，我给出了 mod_gzip 模块特性的细节（在必要的地方，还说起它与商业产品的相关之处）。

首先，我作了一个可用特性的列表。表 5 列出了 mod_gzip 的特性：

表 5. mod_gzip 的特性研究

理想特性	是否支持？
支持何种 Web 服务器？	Apache。
可否侦听远程 Web 服务器？	不能。
有无 SSL 支持？	有。
如何得到？	免费下载。
内存消耗状况？	少。
支持何种平台？	Win9x、NT、2000、Linux、FreeBSD 和 Unix 等。
须要哪些额外的浏览器插件？	无。
须要哪些浏览器设置？	IE：设置 “Use HTTP 1.1”。
它可否压缩来自特定 Web 服务器目录的内容？	能。
它可否压缩来自特定 URL 字符串的内容？	能。
它可否包含/去除特定的 MIME 类型？	能。
它可否包含/去除特定的浏览器类型？	能。
它可否指定要压缩内容的最大和最小文件的大小？	能。
在 Web 服务器配置内能否再指定任何一个额外端口？	否。
压缩统计数据在何处可用？	日志文件/HTML 屏。
日志细节是什么？	定制日志格式。
是否出现错误日志？	是（Apache 错误日志的一部分）。
它有无禁用的压缩特性？	有。
它是否提供图像压缩？	否。
是否有基于 HTML 的屏幕，用于快速浏览运行时压缩统计数据？	有。
您可否指定线程/池数（并发用户）？	否（在 Apache Web 服务器能够）。
所支持的并发用户数？	Web 服务器的一个特性。
可否指定压缩级别？	否。
可否启动和中止压缩产品？	必须中止 Web 服务器。
安装和配置的简易性如何？	较好。

 

注意： 所研究的商业产品的版本也能提供上述某些特性及其余特性。要注意的其余重要特性有：

• 不少商业产品基本上都独立于 HTTP 服务器，所以压缩特性无需重启 Web 服务器就能开关。
• 管理员可以指定各类压缩级别。
• 所研究的商业产品不具有的一个重要特性是不能压缩来自某个特定 URL 的内容。这意味着要么来自服务器的内容所有被压缩，要么都没压缩。然而，应该注意到，若是有需求，厂商会在其下一个版本实现这些特性，不过可能要额外收费。

接下来，我研究的是压缩比。为了评估和表示压缩比，我设立了一个独立的环境（一个 Windows NT 工做站、256 MB RAM 和 1 GHz Pentium 4 处理器）。产品以厂商提供的默认设置安装。

用于测试的文件类型以下：

• HTML 文件用于组装应用服务器提供的某些典型应用程序输出。
• WebSphere 示例应用程序的动态输出（Servlet 和 JSP 输出）。

所使用的文件如表 6 所示。（要查看示例内使用的一些屏幕，请查看 参考资料 的第一个条目）。

表 6. 用于测试的文件

示例编号	大小（字节）*	文件类型
1	822	WebSphere 动态输出
2	864	WebSphere 动态输出
3	1370	WebSphere 动态输出
4	1523	WebSphere 动态输出
5	4588	WebSphere 动态输出
6	5248	WebSphere 动态输出
7	6201	A typical 应用程序 JSP 输出
8	6443	A typical 应用程序 JSP 输出
9	6760	A typical 应用程序 JSP 输出
10	7915	WebSphere 动态输出
11	9563	WebSphere 动态输出
12	13382	典型应用程序 JSP 输出
13	14717	WebSphere 动态输出
14	15211	典型应用程序 JSP 输出
15	27815	典型应用程序 JSP 输出

*文件大小取决于从 Web 服务器日志发回的输出数据的记录，而且大小只表示 HTML 的内容（不包括图像）。

 

图 1 中的图形描述了从日志文件中观察到的压缩比。

我从压缩比的有关数据中注意到如下几点：

• 压缩比对应用程序颇有益处。当文件较大时，益处就更为明显。
• 没有包括空白消除特性；在商业版本中，这一点能够根据须要添加。
• 压缩比是从单个产品的日志文件标记录出来的。没有尝试要限制客户机和服务器之间的带宽，也没有观察（或模拟）下载时间。
• 这三种产品的压缩比几乎同样，这多是因为使用的底层算法是相同的。
• 没有作过多研究计算效率（速度以及所使用的服务器资源）以及多个并发访问时产品的行为，由于这不是主要目标。不过我观察了同一个开发环境下有多个用户时这些产品的整体表现（有 20 个用户使用开发中的应用程序）。我没有发现任何 CPU 或时间的异常使用。
• 被压缩的示例应用程序文件包含一些内联 JavaScript，并且在浏览器内能够正常执行。
• 没有结合 SSL 进行测试。
• 没有任何一个产品压缩由 Web 服务器缓存的页面，由于产品不能访问 Web 服务器的缓存区，因此对于发送典型的静态 Web 页面须要进行仔细分析，着重考虑是启用 Web 服务器缓存仍是启用压缩。

最后的提示：除了首次访问页面外，为发送静态页面的大型 Web 站点选择压缩很难带来性能改进，由于这些 Web 站点可能会维护专门的缓存服务器。不过，当相同的静态页面从 Servlet 引擎动态发布时，不会发生缓存，所以能够进行压缩。对于 Web 应用程序，大多数页面都只在请求时才生成，因此缓存不会发生，所以压缩很是适合这类应用程序。

建议

我发现全部被研究的压缩产品都会给出大体相等的压缩比。于是，服务器群环境的其余特性就成为了决策的重要因素（好比产品只压缩特定类型的内容或来自特定 URL 内容的能力）。

因为 HTTP 压缩技术（至少在服务器端）还只处于其起步阶段，在复杂的联网环境内发生难以预见问题的可能性很高，所以这类技术的售后支持对成功的实现相当重要。

在本例中，因为 IT 部门选择 IBM 做为该项目大多数硬件、软件、安装和服务的提供商，所以在寻找其余产品前天然要先看看 IBM 的压缩解决方案。但客户支持的问题如何解决？

IBM 的 Web 服务器（相似于支持 mod_gzip 压缩的 Apache Web 服务器）并不支持 mod_gzip，先前已经提到。但 IBM 研究团队已经开发出补丁以提供对 mod_gzip 压缩的支持。该补丁不太可能加入到 Web 服务器的当前版本，由于这类压缩的开发主要针对于服务器的后续版本。

了解一切状况以后，该公司就请求 IBM 特别为其服务器群提供压缩支持，并且 IBM 团队也赞成这样作。所以公司实现了 mod_gzip 支持。