我编写了一个响应低于 1K 的 JSON 内容的 Web 服务。这种压缩策略中哪一种最好？
- 通过反向代理将此内容压缩为任何其他文本资源？
- 添加规则以不在阈值以下压缩资源？
我认为互联网上的数据包大小大于 1K(This article 非常有趣，但它给我带来的问题多于答案:579 字节？1518 字节？)。这样，就可以避免花费时间和处理器来压缩已经在 1 个数据包中发送的内容。
因此我更多地关注某人对这两种策略的测试？有人做过测试吗？ 而且我对你写的规则也很感兴趣。
谢谢
最佳答案
我下载了此页面的副本(即包含此问题的 HTML 的源代码)，并仅保留前 993 个字符。
即原始大小为993个字符。
使用 gzip 压缩方式压缩该文件会生成 595 字节的文件。
这意味着新文件几乎是原始文件的 60%!
结论:是的，它很容易就值(value)约 1KB 的(文本)数据。
将原始大小大约减半至 515 个字符会产生 397 个字符的压缩文件，较新的文件约为原始文件的 77%，虽然不如原始文件好，但仍然具有优势。
将文件再次减半至 223 个字符会产生 277 字节的压缩文件，并且压缩文件现在更大，因此对于非常小的数据包大小，gzip 压缩没有用，尽管仍然可以实现压缩。 (但不能简单地使用 gzip)。
为了让您了解大约 500 字节有多么小，请考虑 google.com 的响应(包括 HTTP header ):
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>
包括 header 已经有 465 个字节了! (但是 HTTP header 通常不会被压缩，只有内容......这里是 219 个字符)。
压缩后文件大小为 266(不包括 header )，因此小幅增长不值得担心。
关于http-compression - 当Content-Length低于1K时，压缩HTTP响应是没有用的吗？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/5324285/