标头“Vary:Accept-Encoding”指定方法及其重要性分析

作者:Kaka 时间:2013-11-22 22:8:47 浏览: 评论:9

在webkaka的网站速度诊断性能优化里有一项叫指定“Vary:Accept-Encoding”标头，可能很多人不太明白这是什么意思，不知道它对网站的影响有多大，不知道如何进行优化，为此，本文将给大家阐述下“Vary:Accept-Encoding”标头的意义以及设置方法。

指定“Vary:Accept-Encoding”标头

指定“Vary: Accept-Encoding”标头的意义

指定“Vary: Accept-Encoding”标头，用一句话来说明它的意义，就是“告诉代理服务器缓存两种版本的资源：压缩和非压缩，这有助于避免一些公共代理不能正确地检测Content-Encoding标头的问题。”不过我想很多人都不理解这句话是什么意思，所以需要更详细的解释。

先来看看下面这幅图：

网页从请求到响应的过程

这个图显示了一个网页从请求到响应的过程。正常情况下，“Response”的结果是可读文本，但并不是所有的服务器端都返回这样的正常的结果到用户端，有的返回一堆乱码，这显然是不正常的。

当浏览器发出一个请求时，会包含一些HTTP头信息，服务器会根据这些头信息决定返回什么样的东西（这是一个移动客户端吗？它能否处理压缩内容？它是否需要特定的语言支持？）。

直接访问是好的，但现在网络使用了中间高速缓存（cache）和内容分发网络（CDN）。这就产生了一个问题，缓存如何使用头信息决定返回什么？它能否复制服务器端的决策逻辑？

“Vary”解决了这个问题，“Vary”头描述什么信息“唯一地”标识一个请求——传入的请求只有完全匹配缓存的“Vary”信息，缓存才被使用。

假如没有“Vary”头，那么如果由于某种原因，客户端有一个未压缩的版本在其缓存中的文件，它会不知道随后再次要求它的压缩版本，而不是只从缓存中使用未压缩的文件。——这就很好的解释了“Vary”头信息的重要意义。

设想有两个客户，一个使用的旧浏览器不支持压缩，一个使用新的浏览器支持压缩，如果他们都请求同一个网页，那么取决于谁先请求，压缩或非压缩版本便存储在CDN上。这样问题就出现了，旧浏览器请求常规网页但获得缓存的压缩版本，而新浏览器会获得缓存的非压缩版本但尝试去“解压”它。无论哪种方式都是坏消息。解决方法是，源服务器回送“Vary: Accept-Encoding”。

现在的中间CDN会存储独立的缓存条目，一个是Accept-encoding: gzip ，而如果你没有发送header，则存储另一个。

标头“Vary:Accept-Encoding”指定方法

现在的新浏览器都支持压缩了，因此如果网站启用了GZip，可以无需再指定“Vary: Accept-Encoding”标头，不过指定“Vary: Accept-Encoding”标头会有更高的保险，而它并不需要你额外的开销，为什么不指定呢？下面是设置方法：

Apache/.htaccess

      <IfModule mod_headers.c>
        <FilesMatch ".(js|css|xml|gz|html)$">
          Header append Vary: Accept-Encoding
        </FilesMatch>
      </IfModule>

Nginx

gzip_vary on

IIS

在web.config里加上如下配置，web.config位置在：%windir%\Microsoft.NET\Framework\.net版本号\CONFIG\Web.config 。

      <system.webServer>
        <httpProtocol>
          <customHeaders>
          <remove name="Vary"></remove>
          <add name="Vary" value="Accept-Encoding"></add>
          </customHeaders>
        </httpProtocol>
      </system.webServer>

指定“Vary:Accept-Encoding”标头，网站需要启用GZip，才变得有意义。网站如何启用GZip？可以看看如下的教程：

相关文章

IIS启用GZIP压缩css、js无效的原因及解决方法

IIS启用GZip失败之原因：临时目录权限没设好

图片GZip压缩后体积会变大

GZip压缩启动后js css不能运行的解决方法