一、HTTP協議頭： 服務端根據客戶端傳送的請求頭中某些欄位自動傳送最合適的版本。可以用於這個機制的請求頭欄位分為兩種：Accept欄位、其他欄位。

請求頭欄位	說明	響應頭欄位
Accept-Encoding	告知伺服器採用何種壓縮方式	Content-Encoding

比如客戶端傳送的請求頭：

1. Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
2. Accept-Encoding: gzip, deflate, sdch
3. Accept-Language: zh-CN,zh;q=0.8

Accept：優先接受text/html....，後在接受image/webp... Accept-Encoding：支援採用gzip、deflate或sdch壓縮過的資源 Accept-Language：支援zh-CN和zh兩種語言，q表示權重值(0~1)之間 瀏覽器響應頭：

1. Content-Encoding: gzip
2. Content-Type: text/html; charset=UTF-8

表示這個文件確切的MIME型別是text/html；文件內容進行了gzip壓縮，響應頭沒有Content-Language欄位，通常說明返回版本的語言正好是請求頭Accept-Language中權重最高的那個。 1) 接下來我們來詳細分析下http壓縮的完整過程 a、瀏覽器傳送http request給web伺服器，request中有Accept-Encoding：gzip，deflate。 b、Web伺服器接到request後，生成原始的Response，其中有原始的Content-Type和Content-Length。 c、Web伺服器通過Gzip來對Response進行編碼，編碼後header中有Content-Type和Content-Length（壓縮後的大小），並且增加了Content-Encoding:gzip。然後把Response傳送給瀏覽器。 d、瀏覽器接到Response後，根據Content-Encoding:gzip來對Response進行編碼。獲取到原始response後，然後顯示出網頁。 整個流程圖如下：
2）通過fiddler抓包觀察 解碼前展示：
解碼後展示：
二、瀏覽器支援的三種http傳輸壓縮演算法 1）sdch壓縮演算法 sdch是shared dictionary compression over http的縮寫，即通過字典壓縮演算法對各個頁面中相同的內容進行壓縮，減少相同的內容傳輸。如：一個網站中一般都是共同的頭部和尾部，甚至一些側邊欄也是共同的。之前的方式每個頁面開啟的時候這些共同的資訊都要重新載入，但使用sdch壓縮方式，共同的內容只用傳輸一次就可以。 sdch主要分為3個部分：首次請求，下載字典，其他請求。 ------------首次請求---------- 客戶端： Accept-Encoding: sdch 服務端： Get-Dictionary: /path/to/dict -----------下載字典----------- 客戶端根據Get-Dictionary的值來下載字典，普通的HTTP請求。 -----------其他請求----------- 客戶端： Accept-Encoding: sdch Avail-Dictionary: xxx 伺服器端： 根據Avail-Dictionary的值來進行sdch編碼，如果Accept-Encoding裡有gzip，這些資料還會被gzip壓縮，之後返回。 sdch與ajax+pushState sdch壓縮方式是為了減少相同內容的傳輸，和ajax+pushState相同都是減少相同內容的傳輸。sdch是google出的，但pushState是H5的一個標準，目前已經有Chrome和Firefox支援，之後會有越來越多瀏覽器支援。 2）gzip壓縮演算法      表示實體採用GNU zip編碼，無失真壓縮演算法，用於減少傳輸報文的大小，不會導致資訊損失。效率最高，使用最廣泛。      壓縮方式：是在一個文字檔案中找出類似的字串，並臨時替換他們，使整個檔案變小。這種形式的壓縮對Web來說非常適合，因為HTML和CSS檔案通常包含大量的重複的字串，例如空格，標籤。      gzip可設定壓縮比率，取值範圍在1（最低）到9（最高）之間，不建議設定太高，雖然有很高的壓縮率，但是佔用更多的CPU資源。      gzip壓縮對圖片壓縮效果相對較差      a）講解gzip使用壓縮演算法的基本原理      gzip對於要壓縮的檔案，首先使用LZ77演算法的一個變種進行壓縮，對得到的結果再使用Huffman編碼的方法（gzip根據情況，會選擇使用靜態Huffman編碼或者動態Huffman編碼）進行壓縮。所以明白LZ77演算法和Huffman編碼的壓縮原理，也就明白gzip壓縮原理。      a-1）LZ77演算法壓縮原理      如果檔案中有兩塊內容相同的話，那麼只要知道前一塊的位置和大小，我們就可以確定後一塊的內容。所以我們可以用（兩者之間的距離，相同內容的長度）這樣一對資訊，來替換後一塊內容。由於（兩者之間的距離，相同內容的長度）這一對資訊的大小，小於被替換內容的大小，所以檔案得到了壓縮。      示例：有一個檔案內容a.conf      其中有些部分的內容，前面已經出現過了，下面用()括起來的部分就是相同的部分。      我們使用（兩者之間的距離，相同內容的長度）這樣一對資訊來替換後一塊內容      (22, 7)中，22為相同內容塊與當前位置之間的距離，7為相同內容的長度。      (30, 11)中，30為相同內容塊與當前位置之間的距離，11為相同內容的長度。      由於（兩者之間的距離，相同內容的長度）這一對資訊的大小，小於被替換內容的大小，所以檔案得到了壓縮。      a-2）Huffman編碼      我們把檔案中一定位長的值看作是符號，比如把8位長的256種值，也就是位元組的256種值看作是符號。我們根據這些符號在檔案中出現的頻率，對這些符號重新編碼。對於出現次數非常多的，我們用較少的位來表示，對於出現次數非常少的，我們用較多的位來表示。這樣一來，檔案的一些部分位數變少了，一些部分位數變多了，由於變小的部分變大的部分多，所以整個檔案的大小還是會減小，所以檔案得到了壓縮。 3）deflate壓縮演算法      DEFLATE是同時使用了LZ77演算法與哈夫曼編碼（Huffman Coding）的一個無損資料壓縮演算法。      它最初是由Phil Katz為他的PKZIP歸檔工具第二版所定義的，後來定義在RFC 1951規範中。
     人們普遍認為DEFLATE不受任何專利所制約，並且在LZW（GIF檔案格式使用）相關的專利失效之前，這種格式除了在ZIP檔案格式中得到應用之外也在gzip壓縮檔案以及PNG影象檔案中得到了應用。
     DEFLATE壓縮與解壓的原始碼可以在自由、通用的壓縮庫zlib上找到。
     更高壓縮率的DEFLATE是7-zip所實現的。AdvanceCOMP也使用這種實現，它可以對gzip、PNG、MNG以及ZIP檔案進行壓縮從而得到比zlib更小的檔案大小。在Ken Silverman的KZIP與PNGOUT中使用了一種更加高效同時要求更多使用者輸入的DEFLATE程式。
     deflate是一種壓縮演算法,是huffman編碼的一種加強。
     deflate與gzip解壓的程式碼幾乎相同，可以合成一塊程式碼。 三、gzip與deflate區別      deflate使用inflateInit()，而gzip使用inflateInit2()進行初始化，比inflateInit()多一個引數：-MAX_WBITS，表示處理raw deflate資料。因為gzip資料中的zlib壓縮資料塊沒有zlib header的兩個位元組。使用inflateInit2時要求zlib庫忽略zlib header。在zlib手冊中要求windowBits為8..15，但是實際上其它範圍的資料有特殊作用，見zlib.h中的註釋，如負數表示raw deflate。      deflate是最基礎的演算法，gzip在deflate的raw data前增加了10個位元組的gzheader，尾部添加了8個位元組的校驗位元組（可選crc32和adler32）和長度標識位元組。