最近我們用 YSlow 做頁(yè)面的性能分析時(shí)，發(fā)現(xiàn)有一個(gè) js 不知什么原因沒有被 Gzip 壓縮。于是我找到負(fù)責(zé)服務(wù)器配置的相關(guān)同學(xué)咨詢，這個(gè)過程中巧遇淘叔度，聽了他的解釋才知道這是他們有意為之。

我們知道，數(shù)據(jù)在網(wǎng)絡(luò)上是以包的形式傳輸?shù)?，?TCP/IP 協(xié)議中，大塊的數(shù)據(jù)會(huì)被切分成小塊，然后每一塊會(huì)被加上一些頭信息，最后，這些頭信息加上原始數(shù)據(jù)的一個(gè)片斷組成一個(gè) IP 數(shù)據(jù)報(bào)，即一個(gè)數(shù)據(jù)包。如下圖所示：

(圖：TCP/IP數(shù)據(jù)包的封裝，圖片來自互聯(lián)網(wǎng))

對(duì)于以太網(wǎng)來說，一個(gè)最大傳輸單元(MTU)為 1500 字節(jié)，也即一個(gè) IP 數(shù)據(jù)報(bào)最大不能超過 1500 字節(jié)，除去頭信息和，最終的數(shù)據(jù)信息的長(zhǎng)度一般最多可以比 1400 字節(jié)略多一些。

在 TCP/IP 協(xié)議中，數(shù)據(jù)傳輸?shù)淖钚挝皇前?，也就是說，如果用戶請(qǐng)求一個(gè)文件，無論這個(gè)文件有多小，服務(wù)器端至少需要發(fā)送一個(gè)數(shù)據(jù)包。這就帶來一個(gè)有趣的問題：如果我們的文件內(nèi)容非常小，加上頭信息之后還不足一個(gè)包的長(zhǎng)度，是否還有必要啟用 Gzip 壓縮呢?

比如我們之前發(fā)現(xiàn)的那個(gè) js 文件，內(nèi)容其實(shí)只有 944 字節(jié)，加上 HTTP 頭信息，也還是不足 1400 字節(jié)。對(duì)這么小的文件來說，無論是否啟用 Gzip 壓縮，總是需要一個(gè)數(shù)據(jù)包來傳送。也就是說，對(duì)這個(gè)文件而言，Gzip 壓縮與否，網(wǎng)絡(luò)傳送的速度是一樣的，同時(shí)，如果對(duì)它啟用壓縮，反而需要多耗費(fèi)一些服務(wù)器壓縮以及客戶端解壓的時(shí)間。

因此，對(duì)這樣的小文件來說，不用 Gzip 可能頁(yè)面性能更好，盡管這會(huì)讓 YSlow 的評(píng)分看起來低一些?？紤]到 HTTP 頭的長(zhǎng)度，禁用 Gzip 壓縮的文件一般應(yīng)該在 1024 字節(jié)以內(nèi)。當(dāng)然，從另一個(gè)角度來說，大部分情況下，這樣的小 js 不應(yīng)該存在，而是應(yīng)該合并到某個(gè)更大的 js 中。不過，如果真的有某些特殊的無法合并的小文件，還是可以考慮一下這種禁用小文件 Gzip 的可能性的。

原文：http://oldj.net/article/a-gzipping-exception/

【編輯推薦】

1. 高性能web開發(fā)之網(wǎng)絡(luò)傳輸環(huán)節(jié)
2. 高性能網(wǎng)站建設(shè)的14個(gè)原則
3. 網(wǎng)站高性能的核心優(yōu)勢(shì)該如何打造
4. 高性能WEB開發(fā)之flush讓頁(yè)面分塊逐步呈現(xiàn)
5. 高性能WEB開發(fā)應(yīng)用指南