当前位置：文江博客话题详情

当Content-Length低于1K时，压缩HTTP响应是没有用的吗？

发布于 2024-10-22 12:19:17 字数 367 浏览 1 评论 0原文

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

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

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

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

谢谢

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

不顾 2024-10-29 12:19:17

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

I downloaded a copy of this page (that is, the source code containing the HTML for this question), and kept only the first 993 characters.

That is, the original size is 993 characters.

Compressing that file using gzip compression results in a file of 595 bytes.

This means that the new file is almost 60% of the original!

Conclusion: Yes, it is easily worth ~1KB of (textual) data.

Approximately halving the original size to 515 characters results in a compressed file of 397 characters, the newer file is about 77% of the original, not as good but still an advantage.

Approximately halving the file again to 223 characters results in a compressed file of 277 bytes, and the compressed file is now larger, so for very small packet sizes, gzip compression isn't useful, although it's still possible to achieve compression. (But not with a naive use of gzip).

To give you an idea of how tiny ~500 bytes is, consider google.com's response (including HTTP headers):

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>

That is already 465 bytes including the header! (But the HTTP header is not normally compressed, only the content... Which here is 219 characters).

Compressing that results in a file size of 266 (excluding the headers), so is a small increase not worth worrying about.

回复收藏 0 原文