最近我们用 YSlow 做页面的性能分析时，发现有一个 js 不知什么原因没有被 Gzip 压缩。于是我找到负责服务器配置的相关同学咨询，这个过程中巧遇淘叔度，听了他的解释才知道这是他们有意为之。
我们知道，数据在网络上是以包的形式传输的，在 TCP/IP 协议中，大块的数据会被切分成小块，然后每一块会被加上一些头信息，最后，这些头信息加上原始数据的一个片断组成一个 IP 数据报，即一个数据包。如下图所示：
(图：TCP/IP数据包的封装，图片来自互联网)
对于以太网来说，一个最大传输单元(MTU)为 1500 字节，也即一个 IP 数据报最大不能超过 1500 字节，除去头信息和，最终的数据信息的长度一般最多可以比 1400 字节略多一些。
在 TCP/IP 协议中，数据传输的最小单位是包，也就是说，如果用户请求一个文件，无论这个文件有多小，服务器端至少需要发送一个数据包。这就带来一个有趣的问题：如果我们的文件内容非常小，加上头信息之后还不足一个包的长度，是否还有必要启用 Gzip 压缩呢?
比如我们之前发现的那个 js 文件，内容其实只有 944 字节，加上 HTTP 头信息，也还是不足 1400 字节。对这么小的文件来说，无论是否启用 Gzip 压缩，总是需要一个数据包来传送。也就是说，对这个文件而言，Gzip 压缩与否，网络传送的速度是一样的，同时，如果对它启用压缩，反而需要多耗费一些服务器压缩以及客户端解压的时间。
因此，对这样的小文件来说，不用 Gzip 可能页面性能更好，尽管这会让 YSlow 的评分看起来低一些。考虑到 HTTP 头的长度，禁用 Gzip 压缩的文件一般应该在 1024 字节以内。当然，从另一个角度来说，大部分情况下，这样的小 js 不应该存在，而是应该合并到某个更大的 js 中。不过，如果真的有某些特殊的无法合并的小文件，还是可以考虑一下这种禁用小文件 Gzip 的可能性的。
原文：http://oldj.net/article/a-gzipping-exception/
【编辑推荐】
