HTTP壓縮技術，無需客戶端配置，它是一種最為簡便的提高網絡速度的方法。本文旨在討論這種技術是如何工作的?其優點是什么以及如何實現在Apache和IIS上的數據壓縮?

為何要壓縮?

絕大多數的用戶對壓縮技術的了解來自對下載的一大組文件進行壓縮、解壓和打開等體驗，這種壓縮技術也可以用于向客戶端傳輸的數據的壓縮方面，因為這是一種主動的處理過程，服務器可以減少網頁發送的大小，從而降低用戶下載的時間，最大效率地利用寬帶。

通過壓縮技術，你可以將HTML文件壓縮到原來大小的一半。這樣，把更多的時間留給了客戶端，去下載更多帶寬的工作量。這種壓縮，是在不影響網站實際工作流程、網頁設計和服務內務等情況下實現的，唯一改變的是信息傳輸的方式。

不過，這種方法也有他的限制。

適合壓縮的文件類型

當然，并非所有的文件需要壓縮。比如，已經壓縮的文件諸如JPEG、GIF、PNG、電影和打包內容等不需要HTTP壓縮過濾技術。對它們再次壓縮將無法得到顯著減小文件體積的效果。

同時，網站還有大量的文本內容諸如HTML、XML、CSS和RSS等，他們都需要進行壓縮。壓縮的程序取決于文件的類型，絕大多數的HTML文本文件壓縮率為50%。而用了很格式的網頁(例如用了大量的表格來規劃頁面)可以進一步壓縮，最大可壓縮到原有大小的三分之一。

幸運的是，大多數HTTP服務器都提供了選擇對哪一類型文件進行壓縮的能力，服務器就可以選擇文件類型進行壓縮，那些不適合壓縮的文件會排除在外。

實現HTTP壓縮

HTTP壓縮，是服務器的功能，而瀏覽器也會自動地支持而無需對客戶端進行另外的配置。要想啟用服務器壓縮，只需要簡單的對服務器進行一些設置。

要啟用HTTP壓縮的設置， Apache、IIS6和IIS的更老版本的設置方法都不同。

Apache

Apache 2.0包含了mod_deflate模塊，這個模塊對服務器內容進行動態的Gzip壓縮。這種壓縮可以是對所有內容無差別的——對IE瀏覽器，所有的內容都是經過壓縮的，或者是選擇性的，僅壓縮指定的MIME類型，MIME類型由HTTP應答頭確定，這個HTTP頭可以是由Apache自動生成或是由動態程序(例如CGI)的輸出。

要實現內容的無差別壓縮，可以在Apache配置文件中對整個站點或需要啟用壓縮的目錄加入SetOutputFilter指示如下:

SetOutputFilter?Deflate

要啟用對特定MIME類型內容的壓縮，可以在配置文件中使用AddOutputFilterByType指示，例如下面這樣:

AddOutputFilterByType?DEFLATE?text/html

注意，所有被指定MIME類型輸出都將被壓縮，無論它是來自于一個靜態的磁盤文件還是一個動態程序(如CGI或mod_perl)輸出。

有些老的瀏覽器無法正確的處理壓縮過的內容，這時可以用BrowserMatch指示來過濾掉特定的瀏覽器類型，你可以查看mod_deflate 幫助手冊獲取更詳細的資料。

IIS?6

IIS?6包括了一個簡便易用的內置壓縮組件。由于是內置式的,它不是通過IISAPI接口，它的壓縮速度極快，是IIS?5和更早版本IIS的第三方HTTP壓縮組件的最佳替代品。壓縮系統可以設置對動態(例如腳本輸出仙鶴)和靜態內容進行壓縮，它也可以在目錄中緩沖壓縮信息，這樣當再次訪問以前訪問過的內容時，無需再次進行壓縮從而改善了動態和靜態內容的訪問性能。

為了實現在IIS?6中的HTTP壓縮技術，用戶打開網站的屬性頁面，編輯全局屬性，切換到“服務”標簽，在HTTP壓縮選項中配置選擇項。

緩沖的文件存儲于臨時目錄中，默認的設置是IIS中的元數據目錄的子目錄下。該目錄必須位于NTFS格式分區上，你可以設定緩沖區的大小或是設定為無限，我們建議最大可設置為該分區的兩倍(這些數據還包括了動態腳本的輸出內容)。

IIS5和IIS的更老版本

IIS5和IIS的更老版本沒有內置壓縮功能，但是，它們支持ISAPI過濾器。我們建議用戶使用Port80的

ZipEnable。雖然也存在其它類似功能的產品，但它是少數微軟特別推薦的產品之一，而且它與IIS?6兼容，通過配置IIS?6的設置，它可以將IIS6的HTTP壓縮功能進一步在目錄級別上進行進行控制。

服務器的性能表現

顯然，對傳輸數據進行壓縮需要一定的CPU時間，這種壓縮過程可能會對網站造成不良的影響，因為選定的每個目標在發送前都必須進行壓縮。這里IIS6領先了Apache一小步，它建立了一個緩沖區域，放壓縮文件放在里面，這樣對于那些被頻繁訪問的內容可以大大減少CPU壓縮處理時間。但這不能完全避免實時在線壓縮的需要，大量的動態的內容還是必須被在線壓縮，而這些動態內容所需的緩存空間可能極其巨大。

如果可以節省50%的帶寬而只犧牲網站不到10%的CPU時間。這樣做是完全值得的，特別是對于那些按網絡流量計費的企業來說更為劃算。

瀏覽器的支持和動態內容

如今，絕大多數的現代瀏覽器支持壓縮技術，但是，具體的壓縮方式取決于瀏覽器。不過你無需對此擔心，因為只有瀏覽器指示支持一種壓縮方式時，Web服務器才會發送壓縮內容。盡管如果，了解一下這種處理機制和不同瀏覽器支持的壓縮類型僅是一件有意義的事。

瀏覽器在要求一個網址時，會把支持的壓縮格式通過Accept-Encoding的HTTP頭提交給服務器，Apache或其它Web服務器則從HTTP_ACCEPT_ENCODING環境變量讀取這個信息，這個過程無需你人為干預，Apache在瀏覽器支持壓縮的情況下會自動對發送的內容進行合適的編碼。

下表列出了常見的瀏覽器和它們支持的編碼類型。

瀏覽器	支持的編碼
Firefox 1.0, Mozilla 1.x, Camino	gzip, deflate
OmniWeb 5.x	bzip2,?gzip, deflate
Safari	gzip, deflate
Internet Explorer	gzip, deflate

“Identity”這個詞有時會出現在瀏覽器支持的編碼列表中，這個詞的意思就是支持非壓縮內容。所有的瀏覽器都會默認對它提供支持，不過有些沒有特別列出。

如上所示，現代的瀏覽器都支持壓縮技術。當發出URL請求時瀏覽器會自動提供支持的編碼。如果你需要使用HTTP壓縮技術，只需要對服務器端進行設置就足夠了。

總結

使用HTTP壓縮是一種簡單易行的提高服務器性能和減少帶寬消耗的方法，它也有潛在的不足，那就是增大了CPU的開銷。但是相對于它帶來的好處而言，這個開銷是物有所值的。

而且，如果你發現它并沒有帶來想象中的服務器性能提升，要禁用它也非常簡單。它沒有改變過你的站點內容，改變的僅是數據傳輸的方式而已。


附注：
在運行微軟Internet Information Services (IIS) 6.0的Windows Server 2003系統上，使用GNU zip（Gzip）進行壓縮的靜態文件可能會不可用或包含有來自Web服務器中其他文件的內容。如果出現這種情況，返回客戶端的頁面將會生成出錯，而且還可能造成訪問沖突的現象。
上述問題可能影響到“Outlook網絡訪問（OWA）”用戶，并可能導致代碼錯誤信息返回到OWA頁面上。

微軟已針對上述問題發布了修復補丁，其版本號為831464，大小為430 KB。該補丁對應微軟第831464號知識庫文章。