2

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

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

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

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

谢谢

4

2 回答 2

2

我下载了这个页面的一个副本（即包含这个问题的 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（不包括标题），因此不值得担心的小幅增加。

于 2011-03-16T11:34:19.153 回答
0

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

于 2011-03-16T11:02:18.807 回答