（轉）HTTP 協議之壓縮

　以前寫過一個篇 【HTTP協議詳解】 ，此次繼續介紹HTTP協議中的壓縮。

　　HTTP壓縮是指: Web服務器和瀏覽器之間壓縮傳輸的」文本內容「的方法。 HTTP採用通用的壓縮算法，好比gzip來壓縮HTML,Javascript, CSS文件。 能大大減小網絡傳輸的數據量，提升了用戶顯示網頁的速度。固然，同時會增長一點點服務器的開銷。 本文從HTTP協議的角度，來理解HTTP壓縮這個概念。 
　　閱讀目錄

1. HTTP內容編碼和HTTP壓縮的區別
2. HTTP壓縮的過程
3. 實例：用Fiddler觀察HTTP壓縮
4. 內容編碼類型
5. 壓縮的好處
6. gzip的缺點
7. gzip是如何壓縮的
8. HTTP Response能壓縮，HTTP Request也是能夠壓縮的

　　HTTP內容編碼和HTTP壓縮的區別

　　HTTP壓縮，在HTTP協議中，實際上是內容編碼的一種。

　　在http協議中，能夠對內容（也就是body部分）進行編碼， 能夠採用gzip這樣的編碼。 從而達到壓縮的目的。 也可使用其餘的編碼把內容攪亂或加密，以此來防止未受權的第三方看到文檔的內容。

　　因此咱們說HTTP壓縮，其實就是HTTP內容編碼的一種。 因此你們不要把HTTP壓縮和HTTP內容編碼兩個概念混淆了。

　　HTTP壓縮的過程

　　1. 瀏覽器發送Http request 給Web服務器,  request 中有Accept-Encoding: gzip, deflate。 (告訴服務器， 瀏覽器支持gzip壓縮)

　　2. Web服務器接到request後， 生成原始的Response, 其中有原始的Content-Type和Content-Length。

　　3. Web服務器經過Gzip，來對Response進行編碼， 編碼後header中有Content-Type和Content-Length(壓縮後的大小)， 而且增長了Content-Encoding:gzip.  而後把Response發送給瀏覽器。

　　4. 瀏覽器接到Response後，根據Content-Encoding:gzip來對Response 進行解碼。 獲取到原始response後， 而後顯示出網頁。

　　以下圖:

　　實例：Fiddler觀察HTTP壓縮

　　眼見爲實， 咱們看一個實際的例子， 我發現博客園就使用了gzip壓縮。

　　使用Fiddler能夠清楚地看到。  

　　在Fiddler中，每次都要手動去decode. 太麻煩。  點擊工具欄上的"Decode"按鈕，就能夠自動decode了。

　　內容編碼類型

　　HTTP定義了一些標準的內容編碼類型，並容許用擴展的形式添加更多的編碼。

　　Content-Encoding header 就用這些標準化的代號來講明編碼時使用的算法

　　Content-Encoding值

　　gzip　　代表實體採用GNU zip編碼

　　compress 代表實體採用Unix的文件壓縮程序

　　deflate　　代表實體是用zlib的格式壓縮的

　　identity　　代表沒有對實體進行編碼。當沒有Content-Encoding header時， 就默認爲這種狀況

　　gzip, compress, 以及deflate編碼都是無損壓縮算法，用於減小傳輸報文的大小，不會致使信息損失。 其中gzip一般效率最高， 使用最爲普遍。

　　壓縮的好處

　　http壓縮對純文本能夠壓縮至原內容的40%, 從而節省了60%的數據傳輸。

　　實例： 博客園首頁壓縮前是：46124 bytes. 壓縮後是：16368bytes.     只有原先的35%。  節省了65%的數據傳輸，從而大大提升了性能，有圖爲證。

　　Gzip的缺點

　　JPEG這類文件用gzip壓縮的不夠好。

　　Gzip是如何壓縮的

　　簡單來講， Gzip壓縮是在一個文本文件中找出相似的字符串， 並臨時替換他們，使整個文件變小。這種形式的壓縮對Web來講很是適合， 由於HTML和CSS文件一般包含大量的重複的字符串，例如空格，標籤。

　　HTTP Response能壓縮，HTTP Request也是能夠壓縮的

　　瀏覽器是不會對Request壓縮的。 可是 一些HTTP程序在發送Request時，會對其進行編碼。 以下圖。