Geo*_*ith 14 gzip authorization nginx http-caching http-headers
该gzip_proxied指令允许下列选项(非详尽):
如果响应头包含带有禁用缓存的值的"Expires"字段,则expired启用压缩;
如果响应头包含带有"no-cache"参数的"Cache-Control"字段,则no-cache启用压缩;
如果响应头包含带有"no-store"参数的"Cache-Control"字段,则no-store启用压缩;
如果响应头包含带有"private"参数的"Cache-Control"字段,则private启用压缩;
如果响应头不包含"Last-Modified"字段,则no_last_modified启用压缩;
如果响应头不包含"ETag"字段,则no_etag启用压缩;
如果请求标头包含"授权"字段,则auth启用压缩;
我看不出任何合理的理由来使用大多数这些选项.例如,为什么代理请求是否包含Authorization
标题,或者Cache-Control: private
影响我是否要gzip它?
鉴于Nginx的旧版本使用gzip压缩他们时,从响应中带ETag的,我可以看到一个用例no_etag:如果你没有Nginx的配置为您的gzip压缩响应的ETag,您可能希望通过对未压缩的响应与一个ETag而不是在没有ETag的情况下生成压缩的ETag.
但是,我无法弄明白其他人.
每个选项的预期用例是什么?
Ale*_*uda 12
来自管理员指南 :(强调我的)
该指令有许多参数,指定NGINX应压缩的代理请求类型.例如,仅将响应压缩到不会在代理服务器上缓存的请求是合理的.为此,gzip_proxied指令具有参数,指示NGINX检查响应中的Cache-Control头字段,并在值为no-cache,no-store或private时压缩响应.此外,必须包含expired参数以检查Expires头字段的值.以下示例中设置了这些参数以及auth参数,该参数检查是否存在Authorization标头字段(授权响应特定于最终用户,通常不会缓存)
我同意不压缩可缓存的响应是合理的.考虑到代理缓存的主要节省是提高性能(响应时间)并减少代理在请求上游资源时花费的时间和带宽.获得这些性能优势的权衡是高速缓存存储的成本.以下是一些不压缩可缓存响应的用例:
在许多站点的正常Web流量中,非个性化响应(构成大多数可缓存响应)已经通过 Web构建过程中的脚本缩小,图像大小优化等技术进行了优化.虽然这些静态资源可能会因压缩而略微缩小,但尝试将它们缩小的CPU成本可能不是代理层机器资源的有效使用.但是,为登录用户提供的动态生成的页面,包含大量应用程序生成的内容,很可能会受益于压缩(并且通常不会被缓存).
您正在昂贵的上游服务之前设置代理,但您正在为另一个负责每个用户代理的压缩的代理服务.例如,如果您有一个CDN对同一个昂贵的上游资源(来自不同的地理边缘位置)发出多个请求,并且您希望确保可以重用昂贵的响应.如果CDN缓存未压缩的版本(为压缩和未压缩的用户代理提供服务),您可能只是在您的代理上进行压缩,让它们再次在CDN上解压缩,这只是浪费双方的硬件和电力,以减少带宽链中带宽最高的部分.(响应gzip压缩在最后一英里是最有利的,可以将响应数据传输到用户手机上,当他们进入地铁时,这些数据已降至一个信号点.)
对于相当大的响应实体,请求可以(来自各种用户代理,但通常通过下游CDN中介)进入资源的字节范围,以及不支持压缩的用户代理.CDN可能会从其自己的缓存中提供字节范围请求,前提是它的缓存中已经存在未压缩的版本.
归档时间: |
|
查看次数: |
6131 次 |
最近记录: |