HTTP系列（三）：缓存

本文想要解释以下问题：

HTTP
如何保持已缓存副本的新鲜度
缓存如何与其他缓存和服务器通信

一、保存缓存的新鲜

1.If-Modified-Since 首部

原始服务器的内容可能会发生变化,缓存要不时对其进行检测,看看它们保存的副本是否仍是服务器上最新的副本。这些“新鲜度检测”被称为HTTP
再验证。

缓存可以在任意时刻,以任意的频率对副本进行再验证。但由于缓存中通常会包含数百万的文档,而且网络带宽是很珍贵的,所以大部分缓存只有在客户端发起请求,并且副本旧得足以需要检测的时候,才会对副本进行再验证。 

HTTP为我们提供了几个用来对已缓存对象进行再验证的工具,但最常用的是If-Modified-Since首部。将这个首部添加到
GET请求中去,就可以告诉服务器,只有在缓存了对象的副本之后,又对其进行了修改的情况下,才发送此对象。 

这里列出了在 3种情况下(服务器内容未被修改,服务器内容已被修改,或者服务器上的对象被删除了)服务器收到GETIf-Modified-Since请求时会发生的情况:

• 再验证命中

如果服务器对象未被修改,服务器会向客户端发送一个小的HTTP 304 NotModified响应。

• 再验证未命中

如果服务器对象与已缓存副本不同,服务器向客户端发送一条普通的、带有完整内容的HTTP
200 OK 响应。

• 对象被删除
如果服务器对象已经被删除了,服务器就回送一个404 Not Found响应,缓存也会将其副本删除。 

服务器用HTTP/1.0+的Expires首部或HTTP/1.1的Cache-Control:
max-age响应首部来指定过期日期,同时还会带有响应主体。Expires 首部和 Cache-Control:max-age 首部所做的事情本质上是一样的,但由于 Cache-Control 首部使用的是相对时间而不是绝对日期,所以我们更倾向于使用比较新的 Cache-Control 首部。绝对日期依赖于计算机时钟的正确设置。 



在发现文档过期之后，就可以使用上述的新鲜度检测方法对文档进行检测。

2.If-None-Match： 实体标签再验证

有些情况下仅使用最后修改日期进行再验证是不够的。

有些文档可能会被周期性地重写(比如,从一个后台进程中写入),但实际包含的数据常常是一样的。尽管内容没有变化,但修改日期会发生变化。

有些文档可能被修改了,但所做修改并不重要,不需要让世界范围内的缓存都重装数据(比如对拼写或注释的修改)。

有些服务器无法准确地判定其页面的最后修改日期。

有些服务器提供的文档会在亚秒间隙发生变化(比如,实时监视器),对这些服务器来说,以一秒为粒度的修改日期可能就不够用了。

为了解决这些问题,HTTP 允许用户对被称为实体标签(ETag)的“版本标识符”进行比较。实体标签是附加到文档上的任意标签(引用字符串)。它们可能包含了文档的序列号或版本名,或者是文档内容的校验和及其他指纹信息。
当发布者对文档进行修改时,可以修改文档的实体标签来说明这个新的版本。这样,如果实体标签被修改了,缓存就可以用 If-None-Match 条件首部来 GET 文档的新副本了。
在图 7-15 中,缓存中有一个实体标签为 v2.6 的文档。它会与原始服务器进行再验证,如果标签 v2.6 不再匹配,就会请求一个新对象。在图 7-15 中,标签仍然与之匹配,因此会返回一条 304
Not Modified 响应。 



如果服务器上的实体标签已经发生了变化(可能变成了v3.0),服务器会在一个200OK响应中返回新的内容以及相应的新
Etag。

可以在 If-None-Match首部包含几个实体标签,告诉服务器,缓存中已经存在带有这些实体标签的对象副本:

If-None-Match: "v2.6"

If-None-Match: "v2.4","v2.5","v2.6"

If-None-Match: "foobar","A34FAC0095","Profiles in Courage" 

二、区分是从缓存中获取的还是服务器获取的

HTTP没有为用户提供一种手段来区分响应是缓存命中的,还是访问原始服务器得到的。在这两种情况下,响应码都是200
OK,说明响应有主体部分。有些商业代理缓存会在Via首部附加一些额外信息,以描述缓存中发生的情况。 

客户端有一种方法可以判断响应是否来自缓存,就是使用Date首部。将响应中Date首部的值与当前时间进行比较,如果响应中的日期值比较早,客户端通常就可 

以认为这是一条缓存的响应。客户端也可以通过Age首部来检测缓存的响应,通过这个首部可以分辨出这条响应的使用期
。

三、网状缓存、内容路由以及对等缓存 

有些网络结构会构建复杂的网状缓存(cache
mesh),而不是简单的缓存层次结构。网状缓存中的代理缓存之间会以更加复杂的方式进行对话,做出动态的缓存通信决策,决定与哪个父缓存进行对话,或者决定彻底绕开缓存,直接连接原始服务器。这种代理缓存会决定选择何种路由对内容进行访问、管理和传送,因此可将其称为内容路由器(content
router)。

网状缓存中为内容路由设计的缓存(除了其他任务之外)要完成下列所有功能。

根据URL在父缓存或原始服务器之间进行动态选择。

根据URL动态地选择一个特定的父缓存。

前往父缓存之前,在本地缓存中搜索已缓存的副本。

允许其他缓存对其缓存的部分内容进行访问,但不允许因特网流量通过它们的缓存。

缓存之间这些更为复杂的关系允许不同的组织互为对等(peer)实体,将它们的缓存连接起来以实现共赢。提供可选的对等支持的缓存被称为兄弟缓存(siblingcache)(参见图 7-10)。HTTP 并不支持兄弟缓存,所以人们通过一些协议对 HTTP进行了扩展,比如因特网缓存协议(Internet
Cache Protocol,ICP)和超文本缓存协议(HyperText
Caching Protocol,HTCP)。