3

在测试内容是否通过 Apache 的mod_deflate.

我测试了相同的 URL，并在我Content-Encoding:gzip在响应标头中显示的一台 PC 上，在具有几乎相同设置（Windows 版本、浏览器版本等）的另一台 PC 上测试我没有，并且页面加载速度更慢并且尺寸更大. 请求标头Accept-Encoding:gzip, deflate, lzma, sdch, br在这两种情况下都存在。

  1. 有人可以推荐一种可靠的方法来测试内容是否被压缩？我的意思是可靠 - 除了 Chrome 开发工具。
  2. 为什么有些用户即使请求了 gzip 压缩的内容，也可能拥有完整的内容？是服务器相关还是客户端相关？如何确保 100% 的用户获得 gzip 压缩的内容？
4

2 回答 2

2

有人可以推荐一种可靠的方法来测试内容是否被压缩？我的意思是可靠 - 除了 Chrome 开发工具。

[答案] - 一种可靠的测试方法是找出从服务器检索到的内容的大小，并与接收到的内容长度进行比较。根据这篇文章（使用 http 压缩时的内容长度），内容长度将是压缩内容的大小。

如果内容是文本，压缩比将是 3:1 或更高。但是，如果您发送的是压缩图像，它会少很多。在任何情况下，如果压缩有效，它将大于 1:1。

对于测试设置，您可以在 apache 上托管一组测试数据，例如文本文件、图像，并了解它们的大小。文件名可能是它们的大小，例如 1024bytes.txt。在客户端，您可以发送请求以检索数据并比较响应标头（内容长度）以检查内容的大小。您可以使用 mocha & chai 等工具自动执行此操作。

为什么有些用户即使请求了 gzip 压缩的内容，也可能拥有完整的内容？是服务器相关还是客户端相关？如何确保 100% 的用户获得 gzip 压缩的内容？

[答案] - 您只能从服务器端确保这一点。会有客户端限制和错误。例如https://support.microsoft.com/en-us/help/871205/internet-explorer-may-not-decompress-http-content-when-you-visit-a-web-site。如您所见，Windows 错误可能导致压缩失败。这个或类似的错误可能可以解释为什么您在不同的机器上看到不同的行为。

我们如何解决这个问题？

您可以将您的测试设置与可靠的数据提供者进行比较。在您的情况下，您确实使用 www.bing.com 进行了验证。一旦您验证了您的测试设置和客户端与可靠的来源正常工作，请使用您的 apache 服务器对其进行测试并进行认证。

于 2017-02-01T04:37:24.110 回答
1

假设问题是评论中讨论的缓存代理。

有几个选项。

  1. Apache 可以向内容添加 http 标头，通知缓存不要存储内容。将以下内容放入您的 VirtualHost 块

    标头集缓存控制“私有”

    没有承诺上述内容会起作用，这是一个建议，可能会被代理忽略。

  2. 更可靠的方法是使用 HTTPS，这可以防止几乎所有代理读取主机名以外的任何内容，因此它们不可能充当缓存。SSL 证书非常便宜，但您可以先使用自签名证书免费测试。

这里有创建自签名证书的说明然后复制您的 VirtualHost 块并粘贴一个新的，将端口更改为 443 并添加以下内容：

<VirtualHost *:443>

     .... Existing config

     SSLEngine on
     SSLCertificateFile /path/to/your_domain_name.crt
     SSLCertificateKeyFile /path/to/your_private.key

</VirtualHost>

最后一点，我要指出，如果一个组织已经实现了缓存代理。这样做的目的可能是提高用户的性能。确定技术更改是否正在提高最终用户的速度的最佳方法是对其进行测量。Chrome 开发人员工具包括一个网络监视器，其中包括页面加载时间和许多其他有趣的细节。

于 2017-01-30T23:01:47.767 回答