Nginx 反代网站响应 Header 头信息出现多个 “Vary:Accept-Encoding” 问题

小助手读文章 00:00 / 00:00

前面分享过《利用 Nginx 反向代理和缓存功能自建及优化 CDN 加速节点详细教程》,使用中有发现一个问题,套了多层 Nginx 后响应头出现了多个 Vary:Accept-Encoding

[[email protected] ~]# curl -I -H 'Host: vircloud.net' https://CDN IP
HTTP/1.1 200 OK
Date: Thu, 27 Jun 2019 00:20:06 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Vary: Accept-Encoding
X-Pingback: https://vircloud.net/action/xmlrpc
Set-Cookie: 1ace4129ed475fea40c32ab2c48ab0c2_armxmod_online=U5; path=/
Strict-Transport-Security: max-age=15552000; includeSubdomains; preload
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Server: vcloud

利用 curl 命令检查 CDN 状态方法可以参考《cURL:一款神奇的 Linux 万金油工具详细使用教程》。

虽然实际使用中并没有发现有什么异常,但多余的响应头信息(Response Header)未必不会造成浏览器解析困扰,所以进行了排查一番。

分析

Vary:Accept-Encoding 头信息用一句话来说明它的意义,就是 “告诉代理服务器缓存两种版本的资源:压缩和非压缩,这有助于避免一些代理不能正确地检测 Content-Encoding 标头的问题”,这句话可能不太好理解,做个图来分析一下:

浏览请求过程.png

上图是使用 CDN 后网页从请求到响应的过程,正常情况下,最终在客户端呈现的结果应该是可读文本,但并不是所有的 CDN / 服务器端都能返回正常的结果,有的时候返回的可能就是是一堆乱码。

当客户端发出一个请求时,会包含一些 HTTP Header 头信息,比如 Accept-Encoding,告诉 CDN / 服务器客户端支持什么压缩格式,CDN / 服务器会根据这些头信息决定返回什么样的内容,比如服务器就会判断这是一个移动端请求吗?它是否能处理压缩?它是否需要特定的语言支持?等等。

客户端直接访问服务器是没问题的,但现在链路中间使用了 CDN,这就产生了一个问题,缓存如何使用头信息决定返回什么?它能否复制服务器端的决策逻辑?

Vary 头信息就是为了解决这个问题诞生的,Vary 头信息描述唯一地标识了一个请求:传入的请求只有完全匹配缓存的Vary信息,缓存才能被使用。

设想有两个客户端,一个使用的浏览器不支持压缩,一个使用的浏览器支持压缩,如果他们都请求同一个网页,那么取决于谁先请求,CDN 会缓存未压缩或压缩的内容。这样问题就出现了,假如第一个浏览器请求但 CDN 回复了缓存的压缩版本,或者第二个浏览器请求但 CDN 回复了未压缩版本而浏览器会尝试去“解压”它,无论哪种方式都是两个客户端得到回复内容都是不正常的。解决方法就是,源服务器回送 Vary: Accept-Encoding。现在中间 CDN 会存储独立的缓存条目,一个是未压缩版本,另一个则是压缩版本。

通过分析我们可以知道,其实携带一模一样的头信息其实并不会影响网页的请求-响应过程,而造成最开始提到的响应里有两条一模一样的头信息,是因为中间 CDN 对请求了转发,并且 CDN 和源服务器都开启了 Gzip 压缩,在实际作业中,这是没有必要的,一般在 CDN 开启即可,源服务器关闭压缩。

具体方法为注释掉后端的 gzip_vary,重启 nginx 后即可解决:

[[email protected] ~]# curl -I -H 'Host: vircloud.net' https://CDN IP
HTTP/1.1 200 OK
Date: Thu, 27 Jun 2019 00:26:44 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
X-Pingback: https://vircloud.net/action/xmlrpc
Set-Cookie: 1ace4129ed475fea40c32ab2c48ab0c2_armxmod_online=U5; path=/
Strict-Transport-Security: max-age=15552000; includeSubdomains; preload
X-Xss-Protection: 1; mode=block
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Server: vcloud

扩展

Content-Encoding 是一个实体消息首部,用于对特定媒体类型的数据进行压缩。当这个首部出现的时候,它的值表示消息主体进行了何种方式的内容编码转换。这个消息首部用来告知客户端应该怎样解码才能获取在 Content-Type 中标示的媒体类型内容。

一般建议对数据尽可能地进行压缩,因此才有了这个消息首部的出现。不过对于特定类型的文件来说,比如 jpeg 图片文件,已经是进行过压缩的了。有时候再次进行额外的压缩无助于负载体积的减小,反而有可能会使其增大。

语法

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

指令

gzip

表示采用 Lempel-Ziv coding (LZ77) 压缩算法,以及 32 位 CRC 校验的编码方式。这个编码方式最初由 UNIX 平台上的 gzip 程序采用。出于兼容性的考虑, HTTP/1.1 标准提议支持这种编码方式的服务器应该识别作为别名的 x-gzip 指令。

compress

采用 Lempel-Ziv-Welch (LZW) 压缩算法。这个名称来自 UNIX 系统的 compress 程序,该程序实现了前述算法。
与其同名程序已经在大部分 UNIX 发行版中消失一样,这种内容编码方式已经被大部分浏览器弃用,部分因为专利问题(这项专利在 2003 年到期)。

deflate

采用 zlib 结构 (在 RFC 1950 中规定),和 deflate 压缩算法(在 RFC 1951 中规定)。

identity

用于指代自身(例如:未经过压缩和修改)。除非特别指明,这个标记始终可以被接受。

br

表示采用 Brotli 算法的编码方式。

示例

使用 gzip 方式进行压缩节

客户端可以事先声明一系列的可以支持压缩模式,与请求一齐发送。 Accept-Encoding 这个首部就是用来进行这种内容编码形式协商的:

Accept-Encoding: gzip, deflate

服务器在 Content-Encoding 响应首部提供了实际采用的压缩模式:

Content-Encoding: gzip

需要注意的是,服务器端并不强制要求一定使用何种压缩模式。采用哪种压缩方式高度依赖于服务器端的设置,及其所采用的模块。


参考文章:

1、《云服务器 ECS 上的网站访问时 header 出现多条:Vary:Accept-Encoding


ArmxMod for Typecho
个性化、自适应、功能强大的响应式主题

推广

 继续浏览关于 反代nginx反向代理教程建站系列header 的文章

 本文最后更新于 2019/06/28 12:00:00,可能因经年累月而与现状有所差异

 引用转载请注明:VirCloud's Blog > 建站 > Nginx 反代网站响应 Header 头信息出现多个 “Vary:Accept-Encoding” 问题

精选评论

  1. 心灵博客
    1. 欧文斯

      遇到问题都需要深入研究一下,可以学到更多东西 icon_mrgreen.gif