用 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 服务器接收了此请求时，它能：
- 按请求发送预压缩文件。如果文件不可用，它应能：
- 压缩所请求的静态文件，交付压缩了的数据并将压缩文件保存在一个临时目录以备将来请求；或
- 如果已经实现传输编码，就动态压缩 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，以及要对难以控制的网络带宽和流量作出快速响应，下面是根据这些要求逐级筛选：
- 由于一个 Web 页类似于一个 HTML 文件，既包含数据又包含格式化信息，而且后者大于前者，所以只有数据可以向下发送给浏览器。这可以通过在浏览器端部署 applet 来实现。不过，由于以下原因，不鼓励使用 applet：
- 很多客户浏览器都运行于本地防火墙之后，这些防火墙能够限制外来访问。为 applet 进行这些位置的配置超出了组织自身的权限。
- 很多用户都不喜欢复杂客户应用程序的外观。
- Java 支持是执行这些 applet 所必需的，应该置于客户机，这就需要安装和维护合适的 JVM。
- 由于使用 applet 并非理想的情况，所以通过网络发送的数据越少就越能改进页面下载的速度（或 HTTP 压缩）。
- 如果带宽极低，即使使用 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 支持。
