Web缓存技术相关简析

Web缓存最权威的资料就属RFC了，可惜它太过言简意赅，本文将对缓存做一些通俗易懂的介绍。

Expires / Cache-Control：

当服务器发出响应的时候，可以通过两种方式来告诉客户端缓存请求：

第一种是Expires，比如：

Expires: Sun, 16 Oct 2016 05:43:02 GMT

在此日期之前，客户端都会认为缓存是有效的。

不过Expires有缺点，比如说，服务端和客户端的时间设置可能不同，这就会使缓存的失效可能并不能精确的按服务器的预期进行。

第二种是Cache-Control，比如：

Cache-Control: max-age=315360000

这里声明的是一个相对的秒数，表示从现在起，315360000秒内缓存都是有效的，这样就避免了服务端和客户端时间不一致的问题。

但是Cache-Control是HTTP1.1才有的，不适用与HTTP1.0，而Expires既适用于HTTP1.0，也适用于HTTP1.1，所以说在大多数情况下同时发送这两个头会是一个更好的选择，当客户端两种头都能解析的时候，会优先使用Cache-Control。

参考Apache相关文档

条件GET：Last-Modified / If-Modified-Since和ETag / If-None-Match

Last-Modified / If-Modified-Since

Last-Modified是响应头，If-Modified-Since是请求头。Last-Modified把Web组件的最后修改时间告诉客户端，客户端在下次请求此Web组件的时候，会把上次服务端响应的最后修改时间作为If-Modified-Since的值发送给服务器，服务器可以通过这个值来判断是否需要重新发送，如果不需要，就简单的发送一个304状态码，客户端将从缓存里直接读取所需的Web组件。

ETag / If-None-Match

ETag是响应头，If-None-Match是请求头。Last-Modified / If-Modified-Since的主要缺点就是它只能精确到秒的级别，一旦在一秒的时间里出现了多次修改，那么Last-Modified / If-Modified-Since是无法体现的。相比较，ETag / If-None-Match没有使用时间作为判断标准，而是使用一个特征串。Etag把Web组件的特征串告诉客户端，客户端在下次请求此Web组件的时候，会把上次服务端响应的特征串作为If-None-Match的值发送给服务端，服务端可以通过这个值来判断是否需要从重新发送，如果不需要，就简单的发送一个304状态码，客户端将从缓存里直接读取所需的Web组件。

一些建议：

当使用Expires / Cache-Control的时候，尽量给图片，样式表，脚本等设置一个足够大的缓存时间，如果在此期间，缓存文件有过修改，最简单的更新方式是改名或者设置一个查询参数，比如开始图片名是logo.gif，如果做了一个新的图片，你想更新，可以把图片改名为logo_v2.gif，或者给图片设置一个查询参数logo.gif?foobar，这样，浏览器就会去请求新的图片了。不过，并不是所有的Web组件都适合有一个大的缓存时间，比如html，就不适合使用过大的缓存时间，否则你在缓存到期前，就没机会更新任何东西了。

使用Yslow的都知道，它不建议使用ETag，理由是Etag在分布式环境里，会给服务器造成不必要的压力，比如说在Apache里，Etag缺省是由三个因素决定的：INode Size MTime，而同一个图片，在不同服务器上的INode是不同的，所以在两个服务器上先后请求同一个图片，会得到两次200，虽然我们可以通过设置FileETag Size MTime来屏蔽INode，从而达到一次200，一次304的效果，但304也是要通过一次条件GET请求验证的，所以说，还是通过Expires / Cache-Control来设置一个足够大的缓存时间更划算一些，如此说来，对图片，样式表，脚本等静态内容而言，设置一个大的过期时间是绝对必要的，而Etag和Last-Modified则不是必要的。

如果你决定禁止ETag的话，简单的使用FileETag None就能达到目的。

如果你想把Last-Modified也禁止的话，似乎没有直接的方法，只能通过header模块的方式：

LoadModule headers_module modules/mod_headers.so

<FilesMatch "...">
Header unset Last-Modified
</FilesMatch>


不理解缓存可能会让我们作出很多错误的判断，比如说很多人在估算带宽的时候一般是按照如下的流程来计算带宽的（以每天百万访问量为例来说明）：

如果100万PV的访问量在一天内平均分布的话，折合到每秒大约12次访问，如果按平均每次访问页面的大小是100K字节左右计算的话，这12次访 问总计大约就是1200K字节，字节的单位是Byte，而带宽的单位是bit，它们之间的关系是1Byte = 8bit，所以1200K Byte大致就相当于9600K bit，也就是9Mbps的样子，实际情况中，我们的网站必须能在峰值流量时保持正常访问，假设峰值流量是平均流量的5倍，于是得出真实带宽的需求应该在45Mbps 左右。

如上的计算只在一种情况下是正确的，那就是网站服务器关闭了缓存或者网站的浏览者关闭了缓存！不过现实情况我们出于性能的考虑肯定要加入缓存，用户在有缓存的情况下产生的流量要远远小于没有缓存时产生的流量。所以在估算带宽的时候，我们还得考虑携带缓存浏览的浏览者在总浏览者中所占的比例，说白了就是回头客的比例，这样才能作出准确的判断，否则会多花很多冤枉钱。

参考资料：Caching Tutorial for Web Authors and Webmasters（英文版）（中文版）