HTTP 头信息Vary对Reverse Proxy的作用

原文出自http://mark.koli.ch/2010/09/understanding-the-http-vary-header-and-caching-proxies-squid-etc.html
作者是Mark S. Kolich

就是简单的对vary进行一下介绍，方便大家理解，下面是一个简单的翻译

我从来没有过多关注http的vary header。事实上，我非常幸运在过去的很长时间避开了它给我带来的问题，所以就没引起我的关注，但是，如果你最终要配置一个高性能的反向代理服务器， 那么理解vary header并且它对于你的缓存策略意味着什么事非常有必要的。

下面是一个关于我最近处理关于squid，apache的一个有趣的问题，并且这个问题很难找出竟然是和vary response header有关。

 

1 关于vary的一些基本信息

流行的缓存代理服务器，像squid，通常会根据请求的URI和 vary response header的内容产生一个hash值。当缓存服务器接收到一个请求的时候，它会根据输入产生一个hash，之后检查缓存看是否已经有这个资源在硬盘上或 者在内存中匹配这个hash值。缓存服务器以此来判断命中与否。

而vary response header告诉缓存服务器使用什么判断一个请求的资源是fresh还是stale的，一个简单的vary header包括：

 

Vary: Accept-Encoding
Vary: Accept-Encoding,User-Agent
Vary: X-Some-Custom-Header,Host
Vary: *

 

根据http标准，vary 的值表明需要哪些request header去充分决定一个response是否是fresh的，缓存服务器是否可以不用重新确认就使用一个reponse。

2 缓存遇到的问题

我配置squid作为一个轮询的负载均衡服务器和一个反向代理缓存服务器，在apache服务器的前面，每个apache服务器都运行着我的web应用，我严格配置squid缓存.json文件24个小时。

我打开了一个web浏览器，我访问了一个我认为已经被缓存的URL。

 

GET /path/big.json HTTP/1.1
Host: app.kolich.local
User-Agent: Firefox

HTTP/1.0 200 OK
Date: Fri, 24 Sep 2010 23:09:32 GMT
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Vary: Accept-Encoding,User-Agent
Age: 1235
X-Cache: HIT from cache.kolich.local
X-Cache-Lookup: HIT from cache.kolich.local:80
Content-Length: 25090
Connection: close

很好，它已经被缓存了，然后我在另一台机器上打开了第二个web浏览器（注：是一个不同类型的浏览器），这一次，注意一下X-Cache:MISS

 

GET /path/big.json HTTP/1.1
Host: app.kolich.local
User-Agent: Chrome

HTTP/1.0 200 OK
Date: Fri, 24 Sep 2010 23:11:45 GMT
Content-Type: application/json;charset=UTF-8
Content-Language: en-US
Vary: Accept-Encoding,User-Agent
Age: 4
X-Cache: MISS from cache.kolich.local
X-Cache-Lookup: MISS from cache.kolich.local:80
Content-Length: 25090
Connection: close

 

wow,看看它，我请求了一个完全一样的资源，只是从一个不同的浏览器 上，现在我看到了一个MISS。这肯定不是我想看到的结果，我当然需要需要同样的缓存对象而无论到底是谁请求了这个资源。如果就这样放着的话，这个缓存服 务器只会是一个每一个浏览器都会有一份拷贝的缓存，而不是一个全局的缓存。

3 解决方案，检查你的vary header

观察上面两个请求，注意User-Agent header和Vary header，虽然两个请求都是请求同一个资源，但是squid把这个两个请求看做是不同的了，这是怎么发生的呢，我们看一下Vary header:

 

Vary: Accept-Encoding,User-Agent

它告诉squid请求的URI，Accept-Encoding header和User-Agent header应该包括在hash值内去决定在缓存上的对象是可用的。很明显的，任何一个（URI, Accept- Encoding,"Firefox"）组合的hash值和(URI, Accept-Encoding, "Chrome")组合产生的hash值都是不匹配的，所以squid才认为这两个请求是请求不同的内容的。

为了解决这个问题，我找到了烦人的附加在我的Vary response header上的User-Agent是从哪来的，原来是在apache自带的mod_deflate模块，推荐的mod_deflate的配置包括如果 一个response没有被mod_deflate压缩话就默认附加User-Agent在Vary header后面。这是推荐的apache配置中关于mod_deflate的相关行：

 

SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico)$ no-gzip dont-vary
Header append Vary User-Agent env=!dont-vary

 

我删除掉了上面的这两行，重启了apache然后squid会忽略掉请求的浏览器客户端的类型。本质上说，我通过移除Vary header中的User-Agent告诉squid不要再去关心用户的浏览器类型，然后问题就解决了。

http://shunter.blog.51cto.com/2183398/1076521