【导读】：在互联网上获取内容是相当耗时和昂贵的：大的响应需要在客户端和服务器之间有很多次通信来回，这延缓了他们被浏览器使用和处理的时机，同时也增加了访问者的数据流量开销。因此，缓存和重用已获取的资源成为了性能优化很关键的一方面。 本课内容
好消息是每个浏览器都自带HTTP缓存的实现！我们所要做的就是保证每个服务器响应提供正确的HTTP头指令信息来指导浏览器何时进行缓存以及缓存保留多长时间。 注意：
服务器返回一个响应的同时也发出了一个HTTP头的集合，用来描述响应的类型，长度，缓存指令，验证令牌（validation token）等。举个例子，在上图的交互中，服务器返回了一个1024字节的响应，指示客户端将它缓存120秒，提供了一个验证令牌（“x234dff”），它可以在响应过期之后用来验证资源是否更新过。 使用ETags验证缓存的响应学习重点
让我们假设浏览器在获取一个资源120秒之后又对相同的资源发出请求。首先，浏览器会检查本地缓存并找到之前的响应，不幸的是这个响应已经“过期”不能用了。这时，浏览器原本可以直接发出一个新的请求来获取完整的响应，但是这并不是最高效的，因为如果这个资源没有被更改过，我们就没有理由再去下载一个跟缓存中完全一样的资源。 这就是ETag头信息中放入验证令牌所要解决的问题：服务器生成并返回一个随机令牌，通常是文件内容的哈希（hash）或者其他指纹码（fingerprint）。客户端不需要知道指纹码是如何生成的，它只需要将它在下一个请求中发回给服务器：如果指纹码仍然一致，说明资源没有被修改，我们就可以跳过下载。
在上面的例子中，客户端自动在“If-None-Match”请求头中提供了ETag令牌，服务器端针对当前的资源检查令牌，如果没有被修改过，就返回“304 Not Modified”响应，告诉浏览器，缓存中的响应没有被修改过，可以延用下一个120秒。注意到我们不需要再次下载响应——这节约了时间和带宽。 作为一个Web开发人员，你该如何利用高效的加签（revalidation）？浏览器已经为我们做了很多：它自动检测验是否已经拥有验证令牌，它会将验证令牌附加到发出的请求上，会根据服务器的响应在必要的时候更新缓存时间戳。事实上，唯一留给我们要做的就是保证服务器提供必要的ETag令牌：阅读你的服务器文档并设置必要的配置项。 小贴士：HTML5 样板项目包含了所有最流行的服务器的配置文件样例，并为每一个配置项都提供了详细的注释：找到你最喜欢的服务器，查找适当的设置项，然后拷贝/确认你的服务器使用了推荐的设置。 |
