用于 json 数据的 IIS gzip 压缩 - 我们如何解释有无压缩结果

Question

我在 chrome 上模拟 chrome 的常规 3G 网络执行的平均网络时间：

gzip

• 时间（毫秒）：1376.8
• 延迟（毫秒）：1155.777778
• 数据接收时间（毫秒）：277.1111111

非压缩

• 时间（毫秒）：2220
• 延迟（毫秒）：1043.4
• 数据接收时间（毫秒）：1176.6

我已将“数据接收时间”计算为时间和延迟之间的差异，因为根据他们的定义： 时间是总持续时间，从请求开始到收到响应中的最后一个字节。延迟是加载响应中第一个字节的时间。

我有几个不清楚的地方：

• 未压缩的延迟更少，几乎减少了 10%。我看到这是因为 IIS 需要一些时间来压缩可能会增加它的数据。意见？
• 我不明白的是，使用 gzip 的“数据接收时间”如何减少？

我假设客户端会收到压缩数据，解压缩它然后渲染它。所以这应该需要更多时间。

没有压缩浏览器必须只接收数据并渲染它。

因此，通过压缩，我们有一个额外的解压缩步骤，而且时间更短。有人对此有解释吗？

Answer 1

我不确定我是否理解这个难题。这个讨论中的延迟本质上是响应时间；客户要求提供一些数据，并且在收到响应的第一个字节之前经过了 x 时间。因此，它可以被认为是服务器处理时间加上网络延迟的合并。

可以将数据接收时间视为分布在响应的每个数据包中的网络延迟。压缩后的数据需要更少的网络数据包来传输，这不仅由于大小的减少而减少了传输时间，而且还减少了每个数据包的延迟影响，因为更少的数据包传输 = 整体延迟的影响更小。

那么这里有什么令人惊讶的呢？更少的数据需要更少的时间来传输。就 CPU 周期而言，解压缩该数据的成本远低于任何连接的延迟量。