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

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

[root@fzun ~]# 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 标头的问题”，这句话可能不太好理解，做个图来分析一下：

上图是使用 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 后即可解决：

[root@fzun ~]# 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》