Content-Length 小于 1K 时，压缩 HTTP 响应没有用吗？答案

【问题标题】：Does compressing HTTP response is useless when Content-Length is lower than 1K?Content-Length 小于 1K 时，压缩 HTTP 响应没有用吗？
【发布时间】：2011-03-16 10:56:02
【问题描述】：

我编写了一个响应低于 1K 的 JSON 内容的 Web 服务。哪种压缩策略最好？

通过反向代理将此内容压缩为任何其他文本资源？
添加不压缩低于阈值的资源的规则？

我认为互联网上的数据包大小大于 1K（This article 很有趣，但它给我带来的问题多于答案：579 字节？1518 字节？）。这样，避免花费时间和处理器来压缩已经在 1 个数据包中发送的内容是有意义的。

因此我更多地关注某人对这两种策略的测试？有人做过测试吗？而且我对你写的规则也很感兴趣。

谢谢

【问题讨论】：

标签： http-compression content-length

【解决方案1】：

我下载了这个页面的一个副本（即包含这个问题的 HTML 的源代码），并且只保留了前 993 个字符。

即原始大小为 993 个字符。

使用 gzip 压缩压缩该文件会产生一个 595 字节的文件。

这意味着新文件几乎是原始文件的 60%！

结论：是的，大约 1KB 的（文本）数据很值得。

将原始大小大约减半至 515 个字符会产生 397 个字符的压缩文件，较新的文件大约是原始文件的 77%，虽然没有那么好，但仍然是一个优势。

将文件再次减半到 223 个字符大约会产生 277 个字节的压缩文件，并且压缩文件现在更大，因此对于非常小的数据包大小，gzip 压缩没有用处，尽管它仍然可以实现压缩。（但不是简单地使用 gzip）。

为了让您了解大约 500 字节有多小，请考虑 google.com 的响应（包括 HTTP 标头）：

HTTP/1.0 302 Found
Location: http://www.google.com/
Cache-Control: private
Content-Type: text/html; charset=UTF-8
X-Content-Type-Options: nosniff
Date: Wed, 16 Mar 2011 11:27:29 GMT
Server: sffe
Content-Length: 219
X-XSS-Protection: 1; mode=block

<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>

这已经是 465 字节，包括标题！（但是HTTP头一般不会被压缩，只有内容……这里是219个字符）。

压缩后的文件大小为 266（不包括标题），所以小幅增加并不值得担心。

【讨论】：

【解决方案2】：

虽然它可能无济于事，但压缩一个小数据包可能也无济于事。此外，使用 keep-alives 的高并发系统可能仍然受益，因为它们可能会在单个数据包中缓冲多个响应，并且压缩会将更多响应压缩到每个数据包中。

【讨论】：