HTTP協議3之壓縮--轉

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時，會對其進行編碼。 以下圖。

 

轉：http://www.cnblogs.com/TankXiao/archive/2012/11/13/2749055.html