用 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 支持。