gzip 对 HTTP 传输文件的速度影响是什么？答案

【问题标题】：What is the speed impact of gzip on files for HTTP transfer?gzip 对 HTTP 传输文件的速度影响是什么？
【发布时间】：2011-11-18 08:17:31
【问题描述】：

我知道在通过网络发送文件之前对文件进行 gzip 压缩可以节省带宽，而且对于可以缓存的静态文件，它不会对服务器端 CPU 使用率产生重大影响。

但是客户呢？他们必须对发送的任何文件进行压缩，这将占用 CPU 时间。此外，我担心在进行任何解析之前必须接收并压缩整个文件。

这让我觉得很奇怪，因为我看到了两种情况：

1) client has fast internet   -->   gzip is relevant
2) client has slow internet   -->   gzip prevents partial parsing

显然，确切的加速（或减速？）将取决于正在传输的文件和客户端的确切情况。但是，我很好奇客户端的时间成本（或如何衡量成本）？

【问题讨论】：

我在这里没有看到明确的问题，似乎您已经知道答案是“视情况而定”。根据我的经验，gzip 对有效负载大小的影响有时会推翻所有其他论点——比如将 >1mb 的动态 JSON 减少到大约 200kb
具体来说，我想知道如何衡量由于 gzip 压缩而浪费了多少时间。我知道较小的文件会下载得更快，但我想测量时间，包括在客户端计算机上处理所需的时间（或至少大概）

标签： http gzip

【解决方案1】：

他们必须对发送的任何文件进行压缩，这将占用 CPU 时间。

也许，但是与加载页面时发生的所有其他事情（解析、样式、渲染、脚本编写）相比，解压缩所花费的 CPU 时间非常少。

我担心在进行任何解析之前必须接收并压缩整个文件。

别担心，gzip 是数据的“流”，开始解压缩/解析不需要完整的文件。

具体来说，我想知道如何衡量由于 gzip 压缩而浪费了多少时间。

Here is an interesting article 作者执行您所描述的测试类型。这些工具可供下载，以便您可以在自己的环境中执行相同的测试。

作者总结：

我想在极少数情况下您不应该使用 gzip 压缩您的内容。如果您的典型页面小于 100 字节，那么压缩它可能会损害客户端和服务器的性能。但是没有网站——除了一些网络服务——提供典型大小为 100 字节或更小的页面。因此，提供未压缩的 HTML 没有任何借口。

【讨论】：

“所以没有理由提供未压缩的 HTML。”除了 BREACH 攻击或依赖 HTTP 压缩的攻击。
"当你的速度超过 200 K/sec 时，页面的大小就不再像以前那么重要了。更快的宽带访问意味着更短的连接时间，甚至更短的下载时间。这也意味着服务器的响应时间越来越重要。”在 2021 年，每个人的下载速度都超过了 200K/秒，这意味着 gzip 在当今的情况下可能会带来更多的伤害。

【解决方案2】：

与此同时（这个问题已经有点老了）大多数人无论如何都在为每个连接使用 TLS，所以关于性能的问题已经变得有点多余了。不过这个还是值得一看的：

1) 客户端有快速的互联网 --> gzip 是相关的
2) 客户端网速慢 --> gzip 阻止部分解析

情况正好相反。客户端的互联网连接（或到服务器的路由）越慢，您从 gzip 压缩（或一般压缩）中获得的优势就越大。

如果压缩/解压缩所需的时间加上传输压缩数据所需的时间小于立即传输未压缩数据所需的时间，则压缩会很有帮助。

Gzip 通常会将您的数据减少到其原始大小的 1/3 到 1/2 之间（取决于它是什么），并且压缩运行速度约为 50MB/s (+/- 5)。解压速度大约是原来的 3 倍。

100MBit 以太网的吞吐量约为 12.5MB/s，而大多数人还没有 100MBit 的互联网访问（由于它通常堆叠在 ATM 之上，因此也比普通以太网慢）。此外，大多数人大部分时间都无法通过一次下载来完全满足他们的高带宽互联网连接。

因此，实际上，对于普通普通用户和不在您家中的局域网中但“在其他地方”的服务器，假设您获得 5MB/s（这大约是我所拥有的理论最大值的两倍在这里，顺便说一句）。

要传输一个 50kB 的文件，您需要 0.01 秒。 gzip 压缩增加了大约 0.001 秒的压缩时间和 0.0003 秒的解压缩时间（我们四舍五入说总共 0.002 秒），但您只需要传输 16kB，这需要 0.0032 秒。

将它们加在一起，使用 gzip 压缩传输大约快一倍。

当然，最终（当普通用户将拥有 200Mbit/s 的互联网，而服务器拥有 100Gbit/s 的上行链路时）这个数字将会好转。

更新（几年后）：

今天，我偶然发现了Squash Compression Benchmark 站点，该站点显示了在不同计算机上测量的各种压缩算法（其中包括 gzip）的漂亮图表。它还包括一个传输+处理计算器，它证明了我的主张：链接越慢，压缩的价值就越大。

您可以立即看到，对于较慢的传输速度（我选择 250kB/s 作为示例），压缩是一大优势。与通过网络传输东西所节省的时间相比，压缩/解压缩时间几乎是微不足道的。
但是，随着传输速度接近与压缩/解压缩速度相同的数量级，优势会减弱。对于“典型的，不是很棒”的台式计算机，根据使用的压缩算法，收支平衡点将介于 10 MB/s 和 100 MB/s 之间，这大致对应于您在 DSL 上获得的理论最大吞吐量-100 或千兆光纤互联网连接。对于任何低于 100 Mbit/s 的链接，可以肯定的是，压缩是“赢”的，而在高于 100 Mbit/s 的情况下，它更像是“取决于”，而在千兆位以上的速度，它肯定是“失败”。

请注意您的计算机速度对“压缩是值得的”方面的真实情况和谎言有何影响巨大。适用于您的桌面游戏设备的情况可能不适用于您的低成本手机。
详细说明：除最后一张外，所有屏幕截图都是针对“E-Desktop Intel Core i3”机器（典型的“没有什么特别的，不是很棒”的台式电脑），而最后一张是针对“Raspberry 2”（不太- 糟糕，但仍然是低功耗的 ARM 小型计算机）。虽然您可以毫无疑问地说，在 10 MB/s（即 100Mbit 链接）下，在 Core i3 上进行压缩总是大胜（将总时间缩短不到一半），在 Raspberry 上存在一些快速压缩器，可以说值得这样做，但 zlib 压缩肯定比不压缩更糟糕。

在 Raspberry 上，在 100 Mbit/s 时不是很清晰：

【讨论】：

我对性能感到困惑。 Zip 与 Gzip 哪个更好？
@HRaval：这不能得到最终的回答，因为它不仅取决于实现，还取决于参数（例如字典大小，可能还有算法），但通常 gzip 对我来说往往更快（从技术上讲，gzip 是一种压缩格式 [LZ77+Huffman]，而 ZIP 是一种包含目录信息等的容器格式，它可能使用许多不同的压缩算法中的一种，其中与 gzip 格式相同）。不过这并不重要，因为只有 gzip 能够很好地支持 HTTP 上的透明压缩，而 zip 则不然。