在設(shè)置GZip時，發(fā)現(xiàn)同時有個Deflate壓縮設(shè)置，一開始并不了解Deflate壓縮，于是便在啟用GZip的同時，也啟用了Deflate壓縮。雖然同時設(shè)置GZip和Deflate壓縮，并不影響網(wǎng)站的正常運(yùn)行，并且在檢測網(wǎng)站是否啟用GZip時，返回的答案是已啟用。但是我們能否不設(shè)置Deflate壓縮呢？或者來說，需要禁用Deflate壓縮呢？Deflate壓縮又有什么好處和壞處？帶著這一堆疑問，我今天查了一些資料，大概了解了一些，最后得到的結(jié)論是：DEFLATE——過時的網(wǎng)頁壓縮格式，最好禁用。
了解GZip和deflate
GZIP，好像是一個不透明的或原子的功能。事實上，HTTP定義了一種機(jī)制，一個Web客戶機(jī)和Web服務(wù)器同意一壓縮方案可以用來發(fā)送內(nèi)容，這由使用Accept-Encoding和Content-Encoding標(biāo)頭完成。有兩種常用的HTTP壓縮：DEFLATE和GZIP。
DEFLATE是一個無專利的壓縮算法，它可以實現(xiàn)無損數(shù)據(jù)壓縮，有眾多開源的實現(xiàn)算法。該標(biāo)準(zhǔn)的實施庫大多數(shù)人用的是zlib的。zlib庫提供用于壓縮和解壓縮使用DEFLATE/INFLATE的數(shù)據(jù)。zlib庫還提供了一種數(shù)據(jù)格式，混淆的命名ZLIB，它包裝DEFLATE壓縮數(shù)據(jù)，具有報頭和校驗和。
GZIP是使用DEFLATE進(jìn)行壓縮數(shù)據(jù)的另一個壓縮庫。事實上，GZIP的大多數(shù)實現(xiàn)實際使用zlib庫的內(nèi)部進(jìn)行DEFLATE/ INFLATE壓縮操作。GZIP產(chǎn)生其自己的數(shù)據(jù)格式，混淆的命名GZIP，它包裝DEFLATE壓縮數(shù)據(jù)，具有報頭和校驗和。
早期瀏覽器對DEFLATE壓縮描述混亂
HTTP/1.1 RFC（超文本傳輸協(xié)議HTTP/1.1版）在為Accept-Encoding和Content-Encoding標(biāo)頭描述允許的壓縮方案時做得不好，它定義了Content-Encoding：gzip，該響應(yīng)體由使用GZIP數(shù)據(jù)格式（GZIP標(biāo)頭，壓縮數(shù)據(jù)，和校驗和）組成。它還定義 Content-Encoding：DEFLATE，但是，盡管它的名字，這并不意味著響應(yīng)體是DEFLATE壓縮數(shù)據(jù)的原始塊。根據(jù)RFC-2616，DEFLATE和Content-Encoding：DEFLATE，實際上意味著響應(yīng)體是由zlib的格式（zlib的頭，壓縮數(shù)據(jù)和校驗）組成的。
這種“DEFLATE的標(biāo)識并不意味著原始DEFLATE壓縮數(shù)據(jù)”的想法是相當(dāng)混亂的。早期版本的Microsoft的IIS Web服務(wù)器被編程為返回原始DEFLATE壓縮數(shù)據(jù)的Accept-Encoding:：deflate要求，而不是一個zlib的格式的響應(yīng)。而在與Content-Encoding時期望的響應(yīng)自然版本的Internet Explorer：DEFLATE標(biāo)頭有原始DEFLATE響應(yīng)主體。
Mark Adler，zlib的作者之一，介紹說：
早期的微軟服務(wù)器會錯誤地提供“Deflate”的原始壓縮（例如RFC1951的數(shù)據(jù)沒有RFC1950的zlib包裝）。這導(dǎo)致的問題是，瀏覽器不得不去試一下兩種方式，在最后它只是使用更可靠的GZIP。
現(xiàn)在瀏覽器對DEFLATE壓縮處理不好
如Mark所說，瀏覽器收到Content-Encoding后，壓縮必須處理兩種可能的情況：響應(yīng)主體是原始DEFLATE數(shù)據(jù)，或響應(yīng)主體是zlib包裝過的DEFLATE響應(yīng)。那么，現(xiàn)代瀏覽器處理DEFLATE或zlib包裝過的DEFLATE響應(yīng)效果有多好？Verve工作室測試了一個龐大的瀏覽器數(shù)量，結(jié)果并不好。
表中的部分結(jié)果意味著瀏覽器處理原始DEFLATE或zlib包裝過的DEFLATE不一致，這其實是另一種說法“它被破壞了，功能不正常了。”這似乎是一個棘手的錯誤，而瀏覽器創(chuàng)造者不斷重新引入到他們的產(chǎn)品中。 Safari瀏覽器5.0.2？沒問題。 Safari瀏覽器5.0.3？徹底失敗。 Safari瀏覽器5.0.4？沒問題。 Safari瀏覽器5.0.5？不一致和被破壞。
發(fā)送原始DEFLATE數(shù)據(jù)不是一個好主意，正如馬克說，“[它]只使用更可靠的GZIP。”
還應(yīng)該注意的是，所有支持DEFLATE的瀏覽器都支持GZIP，但不是所有支持GZip的瀏覽器都支持DEFLATE。有些瀏覽器，如Android，在它們的Accept-Encoding請求頭不包含deflate壓縮。由于你不得不配置你的Web服務(wù)器使用GZIP，你還不如避免Content-Encoding: deflate。
禁用DEFLATE
幸運(yùn)的是，避免DEFLATE并不那么困難。
Apache處理所有HTTP壓縮的模塊是mod_deflate模塊。盡管它的名字，mod_deflate模塊根本不支持deflate。要得到一個發(fā)送原始DEFLATE或zlib包裝過的DEFLATE的Apache2版本是不可能。 Nginx的，如Apache，不支持deflate的，它只會發(fā)送gzip壓縮的響應(yīng)，發(fā)送Accept-Encoding：deflate請求頭將導(dǎo)致未壓縮的響應(yīng)。
微軟的IIS Web服務(wù)器可以同時發(fā)送gzip和deflate的響應(yīng)，你可以分別啟用或禁用每個方案。對于IIS6，你可以編輯metabase來禁用DEFLATE支持。對于IIS7，您可以通過編輯.config 文件里的 <httpCompression>元素的<schemes>的DEFLATE壓縮方案部分禁用DEFLATE。
如果你的Web服務(wù)器發(fā)送壓縮的DEFLATE內(nèi)容，無論免費(fèi)還是商業(yè)的產(chǎn)品都具有內(nèi)置的檢測，“過時的壓縮格式”。
檢測網(wǎng)頁使用GZip還是deflate壓縮
檢測網(wǎng)頁使用使用GZip還是deflate壓縮，可以借助一些在線工具，例如卡卡網(wǎng)的GZip壓縮檢測（http://pagespeed.webkaka.com/youhua/gzip/）。
GZip壓縮檢測
需要特別注意的是，GZip壓縮是按文件分別壓縮的，并不是檢測到網(wǎng)頁啟用了GZip，所有文件就全部啟用GZip了。很多情況下，網(wǎng)頁啟用了GZip，但發(fā)現(xiàn)JS文件并沒有啟用GZip，這是因為設(shè)置不當(dāng)而造成的。
如何知道網(wǎng)頁的哪些文件啟用了GZip，哪些文件還沒有啟用GZip？可以借助卡卡網(wǎng)的網(wǎng)站速度診斷工具（http://pagespeed.webkaka.com/），一鍵查看。例如，看看下面的檢測結(jié)果：
html網(wǎng)頁已經(jīng)成功啟用了GZip壓縮
css文件未成功啟用GZip壓縮
這是因為，啟用GZip壓縮時只對html網(wǎng)頁有效，而對其他文件如css沒有生效。
您可能對如下文章也感興趣
IIS啟用GZip失敗之原因：臨時目錄權(quán)限沒設(shè)好
