nginx - gzip_proxied 指令有哪些选项？

Question

gzip_proxied指令允许以下选项(非详尽):

• expired
  enables compression if a response header includes the “Expires” field with a value that disables caching;
• no-cache
  enables compression if a response header includes the “Cache-Control” field with the “no-cache” parameter;
• no-store
  enables compression if a response header includes the “Cache-Control” field with the “no-store” parameter;
• private
  enables compression if a response header includes the “Cache-Control” field with the “private” parameter;
• no_last_modified
  enables compression if a response header does not include the “Last-Modified” field;
• no_etag
  enables compression if a response header does not include the “ETag” field;
• auth
  enables compression if a request header includes the “Authorization” field;

我看不出使用大多数这些选项的任何合理理由。例如，为什么代理请求是否包含 Authorization header ，或 Cache-Control: private ，影响我要不要gzip呢？

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

不过其他的我想不通。

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

Answer 1

来自 admin guide : (强调我的)

The directive has a number of parameters specifying which kinds of proxied requests NGINX should compress. For example, it is reasonable to compress responses only to requests that will not be cached on the proxy server. For this purpose the gzip_proxied directive has parameters that instruct NGINX to check the Cache-Control header field in a response and compress the response if the value is no-cache, no-store, or private. In addition, you must include the expired parameter to check the value of the Expires header field. These parameters are set in the following example, along with the auth parameter, which checks for the presence of the Authorization header field (an authorized response is specific to the end user and is not typically cached)

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

在许多站点的正常 Web 流量中，非个性化响应(构成可缓存响应的大部分)具有 已经通过脚本缩小、图像大小优化等技术进行了优化。 , 在 web 构建过程中。虽然这些静态资源可能会因压缩而略微缩小，但尝试将它们压缩到更小的 CPU 成本可能不是对代理层机器资源的有效使用。但是动态生成的页面，提供给登录的用户，包含大量应用程序生成的内容，很可能会从压缩中受益(并且通常不会被缓存)。

您在昂贵的上游服务前设置代理，但您是 将响应提供给另一个代理 这将负责每个用户代理的压缩。例如，如果您的 CDN 向同一个成本高昂的上游资源(从不同的地理边缘位置)发出多个请求，并且您希望确保可以重用成本高昂的响应。如果 CDN 缓存了未压缩的版本(为压缩和未压缩的用户代理提供服务)，您可能在代理上进行压缩，只是为了让它们在 CDN 上再次解压缩，这只是对双方硬件和电力的浪费，以减少带宽链中带宽最高的部分。 (响应 gzip 压缩在最后一英里最有用，可以将响应数据发送到用户手机，当他们进入地铁时，该手机的信号已经下降到一个点。)

对于相当大的响应实体，可能会(来自各种用户代理，但通常通过下游 CDN 中介)请求 字节范围 资源，给不支持压缩的用户代理。 CDN 可能会从自己的缓存中提供字节范围请求，前提是它的缓存中已经有一个未压缩的版本。