壓縮，讓網(wǎng)絡(luò)更快
作者: By Arvind Jain, Engineering Director and Jason Glasgow, Staff Software Engineer
簡介
互聯(lián)網(wǎng)上，每天有超過99人年浪費在下載未經(jīng)壓縮的內(nèi)容上面。雖然支持壓縮已經(jīng)是每個現(xiàn)代的瀏覽器的標(biāo)準(zhǔn)功能了，但是它們的使用者們往往還是由于這樣那樣的原因不能下載到壓縮的數(shù)據(jù)。這樣就造成了帶寬浪費并且拖慢了用戶和網(wǎng)頁的交互。
數(shù)據(jù)不壓縮對所有的使用者都是一種傷害。對于窄帶用戶，下載那些多余的數(shù)據(jù)花費了更多的時間。而對于寬帶用戶，雖然數(shù)據(jù)傳輸非常快，但是在進入所能達到的最高速的數(shù)據(jù)傳輸之前，不壓縮的數(shù)據(jù)也需要更多的網(wǎng)絡(luò)間往返（IP包）（emu注：這里指的大概是寬帶用戶在訪問多媒體網(wǎng)站時，在高速下載多媒體內(nèi)容之前，需要先下載網(wǎng)頁、css和腳本的資源），這種情況下，網(wǎng)絡(luò)間的往返次數(shù)（IP包個數(shù)）在裝載一個完整的網(wǎng)頁所需要的時間中是一個比網(wǎng)速更大的影響因素。即使網(wǎng)絡(luò)狀況非常好的用戶哪里，這些多余的網(wǎng)絡(luò)間往返也經(jīng)常會多耗費數(shù)十甚至上百毫秒的時間。
在Steve Souders 的《Even Faster Web Sites》里面，Tony Gentilcore用數(shù)據(jù)展現(xiàn)出了禁止壓縮時頁面裝載時間的增加的情況。在得到了許可后，我們也重現(xiàn)了其總?cè)齻€Alexa 排名最高等級的網(wǎng)站的測速結(jié)果：
|
網(wǎng)站
|
Alexa 排名
|
總下載時間增長量(首次打開時)
|
頁面加載時間增長
(1000/384 Kbps DSL)（寬帶）
|
頁面加載時間增長
(56 Kbps modem)（窄帶）
|
|
www.google.com
|
1
|
10.3KB (44%)
|
0.12秒(12%)
|
1.3秒 (25%)
|
|
www.facebook.com
|
2
|
348 KB (175%)
|
9.4秒 (414%)
|
63秒(524%)
|
|
www.yahoo.com
|
3
|
331 KB (126%)
|
1.2秒 (64%)
|
9.4秒 (137%)
|
數(shù)據(jù)來自Steve Souders的《 Even Faster Web Sites》中的“第9章：超越Gzip壓縮”，經(jīng)過作者許可。
Google的web搜索日志也顯示，下載未經(jīng)壓縮數(shù)據(jù)的用戶比下載壓縮數(shù)據(jù)的用戶評價多花費25％的頁面裝載時間。在一個隨機試驗中，我們強行給一些（聲稱）不接受壓縮數(shù)據(jù)的用戶推送了壓縮數(shù)據(jù)，結(jié)果我們測量到它們的頁面延遲有300毫秒的提升。不過這個試驗不能完全說明問題，因為這些被強行推送壓縮數(shù)據(jù)的用戶中有一些可能是誤傷的，因為它們可能真的是在比較老式的計算機上使用比較老的（不支持壓縮的）軟件（后面會講到，更多的可能并非如此）。
它們?yōu)樯恫恢С謮嚎s?
我們發(fā)現(xiàn)有4種常見的原因?qū)е掠脩艚邮懿坏綁嚎s內(nèi)容：殺毒軟件，瀏覽器缺陷，網(wǎng)絡(luò)代理和服務(wù)器配置錯誤。前面3種影響了網(wǎng)絡(luò)請求導(dǎo)致了網(wǎng)絡(luò)服務(wù)器不知道瀏覽器其實能解壓內(nèi)容，尤其是它們錯誤的吧瀏覽器本來應(yīng)該在每個請求中發(fā)送給服務(wù)器的Accept-Encoding 這個http頭給去掉或者破壞了。
殺毒軟件可能是為了減少cpu占用，對網(wǎng)絡(luò)請求進行了攔截和篡改，這樣服務(wù)器就會發(fā)送不壓縮的數(shù)據(jù)給客戶端（這樣它們就不用先解壓后查毒而可以直接查毒了）。但是，如果CPU是系統(tǒng)的性能瓶頸，那么殺毒軟件這樣做根本不是在幫忙而是在添亂。一些著名的殺毒軟跟網(wǎng)絡(luò)壓縮有沖突。網(wǎng)友們自行可以到Browserscope.org上的瀏覽器壓縮支持測試頁面上驗證一下自己的殺毒軟件是否和網(wǎng)絡(luò)壓縮有沖突。
默認情況下IE6瀏覽器在通過代理服務(wù)器訪問網(wǎng)絡(luò)的時候會降級通訊協(xié)議為HTTP/1.0（在IE6的工具——Internet選項——高級 中的第2個選項叫做“ 通過代理連接使用 HTTP 1.1 ” ），其結(jié)果就是不會發(fā)送一個Accept-Encoding的請求頭部。下面的表格是從Google的網(wǎng)絡(luò)搜索日志中生成出來的，顯示出來自IE6的搜索在所有“未聲明接受壓縮結(jié)果”的搜索中占了36％。這個比例比IE6的實際使用比例要高。
|
瀏覽器
|
搜索結(jié)果中要求不壓縮的比例
|
在所有未聲明支持壓縮的搜索中所占的比例
|
|
Google Chrome
|
1
|
1
|
|
Safari
|
1
|
1
|
|
Firefox 3.5
|
3
|
4
|
|
Internet Explorer 8
|
6
|
5
|
|
Firefox 3.0
|
6
|
7
|
|
Other
|
46
|
22
|
|
Internet Explorer 7
|
7
|
24
|
|
Internet Explorer 6
|
20
|
36
|
數(shù)據(jù)來自Google網(wǎng)絡(luò)搜索日志
還有那么一小撮ISP，它們的未壓縮內(nèi)容（未聲明接受壓縮的請求）的比例超過了95％。一個看起來有道理的假設(shè)是，這些ISP或者公司代理去掉或者篡改了Accept-Encoding這個HTTP頭部。和殺毒軟件的情況一樣，懷疑自己的ISP和網(wǎng)絡(luò)壓縮有沖突的網(wǎng)友們自行可以到Browserscope.org上的瀏覽器壓縮支持測試頁面上驗證一下。
最后還有一種情況，用戶下載到了未經(jīng)壓縮的內(nèi)容是因為訪問的網(wǎng)站根本就不壓縮內(nèi)容。下面的表格顯示了幾個不壓縮內(nèi)容的流行站點。這些網(wǎng)站要是壓縮它們的內(nèi)容，它們平均可以給每個訪客減少數(shù)百毫秒的頁面加載時間，對于那些窄帶用戶影響更為明顯。
| 網(wǎng)站 |
資源類型 |
可壓縮的字節(jié)數(shù) |
| www.cnn.com |
CSS and JavaScript |
330 kB |
| www.twitter.com |
CSS and JavaScript |
40 kB |
| www.bbc.co.uk |
CSS and JavaScript |
201 kB |
數(shù)據(jù)使用Page Speed生成
該怎么做?
為了減少未壓縮的數(shù)據(jù)，我們需要一起努力
· 公司里的IT部門和獨立的個人用戶可以升級瀏覽器，尤其是用IE6通過代理服務(wù)器上網(wǎng)的用戶。使用最新版本的 Firefox, Internet Explorer, Opera, Safari, 或者 Google Chrome 可以增加下載到壓縮后數(shù)據(jù)的機會。一份最近的IEEE分析期刊社論中列出了更多的——除了壓縮之外——的升級掉IE6瀏覽器的理由。
· 殺毒軟件供應(yīng)商可以開始正確的解決壓縮問題，在后續(xù)的發(fā)行版中停止篡改和刪除Accept-Encoding這個HTTP頭部。
· 那些使用http代理并且把Accept-Encoding這個HTTP頭部篡改或者剝離掉的ISP們，可以升級、重新配置或者安裝一個好一點的不會禁止用戶使用壓縮功能的代理服務(wù)器。
· 網(wǎng)絡(luò)管理員們可以用Page Speed(或者其他類似的工具)來檢測自己的網(wǎng)頁內(nèi)容是否是經(jīng)過壓縮的。