应用错误收集

gzip_proxied指令允许以下选项（非详尽无遗）：

的过期
  如果响应头包含带有禁用缓存的值的“Expires”字段，则启用压缩;

否缓存
  如果响应头包含带有“no-cache”参数的“Cache-Control”字段，则启用压缩;

否店内
  如果响应头包含带有“no-store”参数的“Cache-Control”字段，则启用压缩;

的私有
  如果响应头包含带有“private”参数的“Cache-Control”字段，则启用压缩;

的 no_last_modified
  如果响应头不包含“Last-Modified”字段，则启用压缩;

的 no_etag
  如果响应头不包含“ETag”字段，则启用压缩;

的 AUTH
  如果请求标头包含“授权”字段，则启用压缩;

我无法理解使用大多数这些选项的合理理由。例如，为什么代理请求是否包含Authorization标头或Cache-Control: private会影响我是否要对其进行gzip？

鉴于旧版本的Nginx strip ETags from responses when gzipping them，我可以看到 no_etag 的用例：如果你没有配置Nginx来为你的gzip压缩响应生成ETag，那么你可能更喜欢使用 ETag传递未压缩的响应，而不是在没有ETag的情况下生成压缩的响应。

但是，我无法弄明白其他人。

每个选项的预期用例是什么？

来自admin guide :(强调我的）

该指令有许多参数，用于指定NGINX应压缩的代理请求类型。例如，仅将响应压缩到不会缓存在代理服务器上的请求是合理的。为此，gzip_proxied指令具有参数，指示NGINX检查响应中的Cache-Control头字段，并在值为no-cache，no-store或private时压缩响应。此外，必须包含expired参数以检查Expires头字段的值。以下示例中设置了这些参数以及auth参数，该参数检查是否存在Authorization标头字段（授权响应特定于最终用户，通常不会被缓存）

我同意不压缩可缓存的响应是合理的。考虑到代理缓存的主要节省是提高性能（响应时间）并减少代理在请求上游资源时花费的时间和带宽。获得这些性能优势的权衡是高速缓存存储的成本。以下是一些不压缩可缓存响应的用例：

在许多网站的正常网络流量中，非个性化响应（构成大部分可缓存响应）的已经通过脚本缩小，图像大小优化等技术进行了优化。，在Web构建过程中。虽然这些静态资源可能会从压缩中略微缩小，但尝试将它们缩小的CPU成本可能不是代理层机器资源的有效使用。但是，为登录用户提供动态生成的页面，包含大量应用程序生成的内容，很可能会受益于压缩（并且通常不会被缓存）。
您正在昂贵的上游服务之前设置代理，但您提供对另一个代理的响应，它将负责每个用户代理的压缩。例如，如果您有一个CDN对同一个昂贵的上游资源（来自不同的地理边缘位置）发出多个请求，并且您希望确保可以重用昂贵的响应。如果CDN缓存未压缩的版本（为压缩和未压缩的用户代理提供服务），您可能只是在您的代理上进行压缩，让它们再次在CDN上解压缩，这只是浪费双方的硬件和电力，以减少带宽链中带宽最高的部分。（响应gzip压缩在最后一英里是最有利的，可以将响应数据传输到用户手机上，当他们进入地铁时，这些数据已降至一个信号点。）
对于相当大的响应实体，请求可能来自（来自各种用户代理，但通常通过下游CDN中介），用于资源的字节范围，不支持的用户代理压缩。 CDN可能会从其自己的缓存中提供字节范围请求，前提是它的缓存中已有未压缩版本。

gzip_proxied指令有哪些选项？

1 个答案: