|
13、Gzip壓縮文件內(nèi)容
網(wǎng)絡傳輸中的HTTP請求和應答時間可以通過前端機制得到顯著改善。的確，終端用戶的帶寬、互聯(lián)網(wǎng)提供者、與對等交換點的靠近程度等都不是網(wǎng)站開發(fā)者所能決定的。但是還有其他因素影響著響應時間。通過減小HTTP響應的大小可以節(jié)省HTTP響應時間。
從HTTP/1.1開始，web客戶端都默認支持HTTP請求中有Accept-Encoding文件頭的壓縮格式：
Accept-Encoding: gzip, deflate
如果web服務器在請求的文件頭中檢測到上面的代碼，就會以客戶端列出的方式壓縮響應內(nèi)容。Web服務器把壓縮方式通過響應文件頭中的Content-Encoding來返回給瀏覽器。
Content-Encoding: gzip
Gzip是目前最流行也是最有效的壓縮方式。這是由GNU項目開發(fā)并通過 RFC 1952 來標準化的。另外僅有的一個壓縮格式是deflate，但是它的使用范圍有限效果也稍稍遜色。
Gzip大概可以減少70%的響應規(guī)模。目前大約有90%通過瀏覽器傳輸?shù)幕ヂ?lián)網(wǎng)交換支持gzip格式。如果你使用的是Apache，gzip模塊配置和你的版本有關：Apache 1.3使用mod_zip，而Apache 2.x使用moflate。
瀏覽器和代理都會存在這樣的問題：瀏覽器期望收到的和實際接收到的內(nèi)容會存在不匹配的現(xiàn)象。幸好，這種特殊情況隨著舊式瀏覽器使用量的減少在減少。Apache模塊會通過自動添加適當?shù)腣ary響應文件頭來避免這種狀況的出現(xiàn)。
服務器根據(jù)文件類型來選擇需要進行gzip壓縮的文件，但是這過于限制了可壓縮的文件。大多數(shù)web服務器會壓縮HTML文檔。對腳本和樣式表進行壓縮同樣也是值得做的事情，但是很多web服務器都沒有這個功能。實際上，壓縮任何一個文本類型的響應，包括XML和JSON，都值得的。圖像和PDF文件由于已經(jīng)壓縮過了所以不能再進行gzip壓縮。如果試圖gizp壓縮這些文件的話不但會浪費CPU資源還會增加文件的大小。
Gzip壓縮所有可能的文件類型是減少文件體積增加用戶體驗的簡單方法。
14、配置ETag
Entity tags（ETags）（實體標簽）是web服務器和瀏覽器用于判斷瀏覽器緩存中的內(nèi)容和服務器中的原始內(nèi)容是否匹配的一種機制（“實體”就是所說的“內(nèi)容”，包括圖片、腳本、樣式表等）。增加ETag為實體的驗證提供了一個比使用“l(fā)ast-modified date（上次編輯時間）”更加靈活的機制。Etag是一個識別內(nèi)容版本號的唯一字符串。唯一的格式限制就是它必須包含在雙引號內(nèi)。原始服務器通過含有ETag文件頭的響應指定頁面內(nèi)容的ETag。
HTTP/1.1 200 OK
Last-Modified: Tue, 12 Dec 2006 03:03:59 GMT
ETag: "10c24bc-4ab-457e1c1f"
Content-Length: 12195
稍后，如果瀏覽器要驗證一個文件，它會使用If-None-Match文件頭來把ETag傳回給原始服務器。在這個例子中，如果ETag匹配，就會返回一個304狀態(tài)碼，這就節(jié)省了12195字節(jié)的響應。 GET /i/yahoo.gif HTTP/1.1
Host: us.yimg.com
If-Modified-Since: Tue, 12 Dec 2006 03:03:59 GMT
If-None-Match: "10c24bc-4ab-457e1c1f"
HTTP/1.1 304 Not Modified
ETag的問題在于，它是根據(jù)可以辨別網(wǎng)站所在的服務器的具有唯一性的屬性來生成的。當瀏覽器從一臺服務器上獲得頁面內(nèi)容后到另外一臺服務器上進行驗證時ETag就會不匹配，這種情況對于使用服務器組和處理請求的網(wǎng)站來說是非常常見的。默認情況下，Apache和IIS都會把數(shù)據(jù)嵌入ETag中，這會顯著減少多服務器間的文件驗證沖突。
Apache 1.3和2.x中的ETag格式為inode-size-timestamp。即使某個文件在不同的服務器上會處于相同的目錄下，文件大小、權限、時間戳等都完全相同，但是在不同服務器上他們的內(nèi)碼也是不同的。
IIS 5.0和IIS 6.0處理ETag的機制相似。IIS中的ETag格式為Filetimestamp:ChangeNumber。用ChangeNumber來跟蹤IIS配置的改變。網(wǎng)站所用的不同IIS服務器間ChangeNumber也不相同。 不同的服務器上的Apache和IIS即使對于完全相同的內(nèi)容產(chǎn)生的ETag在也不相同，用戶并不會接收到一個小而快的304響應；相反他們會接收一個正常的200響應并下載全部內(nèi)容。如果你的網(wǎng)站只放在一臺服務器上，就不會存在這個問題。但是如果你的網(wǎng)站是架設在多個服務器上，并且使用Apache和IIS產(chǎn)生默認的ETag配置，你的用戶獲得頁面就會相對慢一點，服務器會傳輸更多的內(nèi)容，占用更多的帶寬，代理也不會有效地緩存你的網(wǎng)站內(nèi)容。即使你的內(nèi)容擁有Expires文件頭，無論用戶什么時候點擊“刷新”或者“重載”按鈕都會發(fā)送相應的GET請求。
如果你沒有使用ETag提供的靈活的驗證模式，那么干脆把所有的ETag都去掉會更好。Last-Modified文件頭驗證是基于內(nèi)容的時間戳的。去掉ETag文件頭會減少響應和下次請求中文件的大小。微軟的這篇支持文稿 講述了如何去掉ETag。在Apache中，只需要在配置文件中簡單添加下面一行代碼就可以了：
FileETag none
出處：藍色理想
責任編輯：bluehearts
上一頁 Yahoo!網(wǎng)站最佳體驗守則之服務器篇 [1] 下一頁 Yahoo!網(wǎng)站最佳體驗守則之服務器篇 [3]
◎進入論壇網(wǎng)站綜合、網(wǎng)頁制作版塊參加討論
|
第 1 頁 
第 2 頁 Yahoo!網(wǎng)站最佳體驗守則之服務器篇 [2]
