Question

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

通过反向代理将此内容与任何其他文本资源一起gzip？
添加规则以不在阈值下压缩资源？

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

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

由于

Answer 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（不包括标题），所以这是一个不值得担心的小幅增长。

Answer 2

虽然它可能无济于事，但压缩一个小数据包可能也不会造成伤害。此外，使用保持活动的高并发系统可能仍然会受益，因为它们可能会在单个数据包中缓冲多个响应，压缩会将更多响应压缩到每个数据包中。

当Content-Length低于1K时，压缩HTTP响应是否无效？

2 个答案: