消息的可缓存性V0 1

1. Hosting Imporvement
消息的可缓存性

2. 目 录
目 录 .......................................................................................................................................2
1 修订记录 ................................................................................................................................3
2 介绍 .......................................................................................................................................4
2.1 目的和范围.....................................................................................................................................4
2.2 术语与缩写解释..............................................................................................................................4
3 可缓存实体 ............................................................................................................................6
3.1 按状态码分类的 response 可缓存性................................................................................................6
3.2 cache-control response 可缓存性.....................................................................................................6
3.3 Response 响应的过期与保鲜..........................................................................................................9
3.4 Validation 验证..............................................................................................................................13
4 其他建议 ..............................................................................................................................14
4.1 进一步工作...................................................................................................................................14
5 相关文档列表 ......................................................................................................................15

3. 修订日期 版本号 描述 修订人
2008/06/2 0.1 消息的可缓存性 v0.1 Pickup.Li
7
1 修订记录

4. 2 介绍
2.1 目的和范围
本文档的目的介绍 HTTP 消息的缓存以及相关信息。
cache 服务器作为反向代理可以减少后端 web 服务器的访问压力并提高用户的访问速度，但是 cache
服务器到底可以缓存那些东西，可以缓存多久，怎么控制某个消息过期以后的动作等等。这些都是本文档关
注的内容。
本文介绍的内容主要来源是 HTTP 1.1，某些缓存服务器通过一定的配置（比如：squid 配置中
refresh_pattern 的 ignore-private 等）能够显式的违反某些规则，所以具体的某个消息的缓存还依赖于缓存服
务器的配置及相关因素，需要具体问题具体分析。
另外，本文关注的主要是做反向代理的缓存服务器。
2.2 术语与缩写解释
编号 术语 解释
1. message 消息，HTTP 通讯的基本单元，通常指 request 或者 response 消息
2. request 请求，客户端向服务器发送的请求
3. response 响应，服务器对客户端请求的响应
4. cache 缓存，存储在本机的 response 信息，以及对这些信息的存储，获取，删除等。
这些信息存储以便在相同的 request 请求时能够及时返回，从而减少响应时间
和网络流量的消耗。
5. cacheable 可缓存，某个 response 信息如果可以存储在下来以供接下来同样的 request 请
求使用，那么这个信息可以被认为作可缓存的。即使某个 response 是可以缓存
的，当一个特定的 request 请求到达时，是否返回该 response 还要受到一些附
加的条件限制
6. explicit 显式的过期时间，源服务器指定的过期时间，当过了过期时间以后 cache 服务
expiration time 器返回相应 response 之前必须经过验证。
7. heuristic 启发式的过期时间，当没有显式的过期时间时由 cache 服务器生成的过期时间
expiration time
8. age 年龄，一个 response 的年龄值就是它从被源服务器发送或者验证之后经过的时
间值
9. freshness 保鲜时间，它表示从 response 生成到过期之间经过的时间值
lifetime
10. fresh 保鲜的，如果一个 response 的 age 没有超过 freshness lifetime 则被认为是保
鲜的
11. stale 过期的，如果一个 response 的 age 超过了 freshness lifetime 则被认为是过期
的
12. validator 验证子，用于确认 cache 保存的实体是否和源服务器一致的协议元素（比如：
Last Modified time 或者一个 entity tag）
13. Shared and Non- 共享和不可共享 cache，不可共享 cache 是指那些只能被单个用户访问的
Shared Caches cache，访问它必须经过相关的权限认证，其他的 cache 都是共享 cache。

6. 3 可缓存实体
在 Squid Cache 服务器安装配置与测试数据中，经过测试和分析，发现 cache 服务器不仅可以为 web
服务器分担压力，并且能够提高用户访问时的速度。以 squid 为例，网站用 squid 加速，目的有二
1: squid 本身具有缓存功能，可以将 webserver 输出的内容缓存起来，在缓存没有过期之前来的访问，
都直接用缓存里面的内容，这样可以有效减少 webserver 机器上面的请求数量。这是 squid 的主要功用。
2: 网络慢的用户会长时间占用 webserver 的 TCP 连接，webserver 对每个连接占用的资源比较大，如
果长时间不能释放出来服务其他请求，性能会有比较大的影响。前面放一个 squid，webserver 就可以迅速处
理完逻辑以后，把数据快速发送给 squid， 然后去处理别的逻辑，而 squid 每个 TCP 连接占用的资源很少，
不用担心占用太多资源。这个用途也叫做连接管理，有一些网络设备也可以做这个事情，价格都很贵。
所以我们有必要搞清楚哪些东西可以缓存，哪些不能被缓存，怎么控制，为网页制作人员和 web
service 维护配置人员提供指导。
3.1 按状态码分类的 response 可缓存性
我们知道，response 按照状态码可以分成 5 类，分别是 1xx 信息类，2xx 成功类，3xx 重定向类，4xx
客户端错误类和 5xx 服务器错误类。这里可以被缓存的 response 只有状态码为：200, 203, 206, 300, 301 或
者 410 的 response。其他的 response 除非由 cache-control 或者其他的 header 显式指定（比如：cache-
control 中的 “max-age”, “s-maxage”, “mustrevalidate”,“proxy-revalidate”, “public” 或 “private”），否则都不
能被缓存。
3.2 cache-control response 可缓存性
cache-control 定义了一系列 request/response 链上的 cache 服务器必须要遵守的规则。这些规则大部分
会改变缺省的 cache 算法。cache-control 的基本语法格式为：
Cache-Control = "Cache-Control" ":" 1#cache-directive
1#cache-directive 表示一个或者多个 cache-directive，cache-directive 可能是 cache-request-directive 也
有可能是 cache-response-directive。
cache-request-directive 包括："no-cache", "no-store", "max-age='delta-seconds'", "max-stale[='delta-
seconds']", "min-fresh='delta-seconds'", "no-transform", "only-if-cached"和 cache-extension。其中，"max-
stale"可以指定以秒为单位的时间值，"max-age"和"min-fresh"则必须指定以秒为单位的时间值。

7. cache-response-directive 包括："public", "private[='1#field-name']", "no-cache[='1#field-name']", "no-
store", "no-transform", "must-revalidate", "proxy-revalidate", "max-age='delta-seconds'", "s-maxage='delta-
seconds'", cache-extension。其中，"max-age"和" s-maxage"必须指定以秒为单位的时间值，" private "和" no-
cache "可以带一个或者多个 HTTP header 域从而指定这些 header 不能缓存。cache-extension 是类似
community="UCI"的 cache-control 扩展标签，它可以用于自定义的 cache 缓存协议元素，比如
community="UCI"作为 Private 的附带元素可以表示该条 response 信息只能被私有的标识为“UCI”的 cache
缓存，其他的 cache 都不能缓存它。
首先，我们介绍一些影响 response 可缓存性的 cache-control 规则："public", "private[='1#field-name']",
"no-cache[='1#field-name']"。
 "public"表示该 response 可以被缓存，就算平常被认为不能缓存或者只能被 non-shared cache 缓
存的那些 response 也可以。
 "private"表示该 response 的全部或者某一部分是为单个用户服务的，不可以被 shared cache 缓存，
源服务器可以用它来标示该 response 隶属于某个用户而不能为其他用户服务。私有（non-
shared）cache 可以保存这些消息，但是"private"并不能保证消息内容的私密安全性。
 "no-cache"，如果 no-cache 没有特别指定某些 field-name，那么它表示 cache 如果需要返回该
response 给接下来的 request 之前必须先向源服务器验证，否则不能发送。这样，源服务器就可以
用它来强制 cache 验证该 response，即使 cache 被设置为可以返回过期的 response 给用户。如果
no-cache 附带了一些 field-names，cache 可以受限的返回 response，也就是说返回的 response
中对应的这些特定的 field-names 在返回之前必须经过验证，这样源服务器可以限制某些 header
不会被重用，从而使得这些 header 都是最新的。
接下来我们来看看影响 cache 存储 response 的 cache-control 规则："no-store"。
cache 可存储 reponse 和 response 的可缓存性是不同的。为了避免某些敏感数据不被 cache 存储下来，
可以指定"no-store"，它作用于整个 request 或者 response 消息。指定了"no-store"的 request 表示该 request
以及由它引起的 response 都不能被存储，指定了"no-store"的 response 表示该 response 以及引起它的
request 都不能被存储。它对 non-shared cache 和 shared-cache 都有效。也就是说 cache 不能故意的把它存储
在永久存储设备上，并且在转发了它以后应该及时清除易失存储设备上的信息。"no-store"提供了一定的私密
安全保证，但是某些 cache 也许不会遵守该约定，也有可能被浏览器本身缓存下来了（当用户点击后退按钮
可以访问），并且也可以通过网络监听获得对应的数据。
接着介绍一下影响过期机制的一些 cache-control 规则："max-age", "s-maxage"，"max-stale"和"min-
fresh"。其中"max-age"可以应用于 request 或者 response。
 作用于 response 的影响过期机制的一些 cache-control 规则
"max-age"：过期时间有源服务器的"Expires"头指定，也可以由"max-age"规则指定。"max-age"优先
于"Expires"头（即使"Expires"头限制的时间值更加严格），当一个 response 年龄值大于过期时间时，它被认
为是过期的，返回过期的数据需要经过验证或者后面提到的 cache-control 规则的作用。事实上，"max-age"暗
示了该 repsonse 可以被缓存，除非指定了一些别的更加严格的 cache 规则。HTTP 1.0 没有制定"max-age"规

8. 则。
"s-maxage"："s-maxage"总是被 private cache 忽略。对于 shared cache，它指定了 response 的最高生
命期。它的优先级比"max-age"和"Expires"都要高。"s-maxage"在语义上包含了"proxy-revalidate"，也就是说，
cache 服务器在返回一个过期的 response 之前必须要首先提交源服务器进行验证。
 作用于 request 的影响过期机制的一些 cache-control 规则
"max-age"：在 request 中包含"max-age"表示客户端同意接受一个 age 小于指定秒数的 response。如果
没有指定"max-stale"那么客户端并不同意接受一个过期的 response。
"min-fresh"：表示客户端同意接受一个 freshness_lifetime 不小于当前 age 值+指定秒数的 response。也
就是说客户端希望收到的 response 的新鲜度至少在指定秒数以内。
"max-stale"：表示客户端同意接受一个过期的 response 消息。如果指定了时间值，表示客户端同意接受
一个超过过期时间不大于指定秒数的 response 消息。如果没有指定具体的数值，表示客户端同意接受一个超
过过期时间任意值的 response 消息。但是，不管是由于用户指定了"max-stale"还是 cache 服务器被配置为返
回过期的数据，cache 服务器必须给这个过期的数据加上 Warning 110（Response is stale）头。
我们发现，"max-age"即可以应用于 request 也可以应用于 response，如果 request 和 response 都包含
了"max-age"，那么应该以它们两个中的值更小的那一个为准。
上面，我们提到了 cache 数据过期后需要提交源服务器进行验证，cache-control 同样存在影响验证的
规则："max-age"，"only-if-cached"，"must-revalidate"和"proxy-revalidate"。
"max-age"：客户端提交 request 的时候可以加上不带 field-names 的"no-cache"（如果是 HTTP 1.0 客
户端可以用"Pragma: no-cache"）来获得源服务器上的 response 版本从而使 cache 也装入这个版本。如果使
用"max-age=0"附带于 request 上，可以使得从客户端到源服务器链路上的所有 cache 已有的对应 response
都提交源服务器进行验证，并且把该 response 装入那些没有存储该 response 的 cache 服务器中。当链路中
的某台 cache 服务器收到"max-age=0"的 request 请求，并且该请求中还附带了 validator，而该 validator 于
cache 验证的 validator 不同时，cache 服务器可以选择自己的或者附带的 validator（比较好的方法是使用
cache 服务器自己的 validator），这样在服务器收到 200 或者 304 响应的时候可以根据具体的情况更新缓存，
并给客户端发送正确的响应。另外，如果 request 中包含了"no-cache"就不应该包含"max-age"，"max-
stale"和"min-fresh"。
"only-if-cached"：在某些情况下（比如网络情况非常差），客户端可能希望获得 cache 服务器中存储的
response，而要求验证或者从源服务器重新获得对应 response 消息，用户就可以在 request 中包含"only-if-
cached"。收到这样的请求的 cache 服务器可以返回本地存储的相应 response，或者 504（Gateway
Timeout）错误信息。如果它属于构建的 cache 服务器集群，那么它也可以将这个请求转发给集群的其他
cache 服务器。
"must-revalidate"：上面提到，用户指定"max-stale"或者 cache 服务器被配置为返回过期的数据都可以
导致过期消息的返回。 "must-revalidate"是源服务器用于指定 response 在过期后必须到源服务器进行验证的
而
规则，不管用户是否指定了"max-stale"或者 cache 服务器是否被配置为返回过期的数据。它为某些协议特性

9. 提供了可靠性操作。如果 cache 验证时不能连上源服务器，它必须返回 504（Gateway Timeout）错误信息。
"proxy-revalidate"：除了不能够应用于 non-shared cache 以外，"proxy-revalidate"和"must-revalidate"的
意思是一样的。它允许在用户 cache 中保存那些经过权限认证的 response（它们 应该包含有"public"来保证
它们可以被缓存）并且在认证过同样的 request 到达时返回缓存数据而不经过源服务器验证过程；其他的则
每次都必须经过验证。
最后我们介绍一下"no-transform"规则。为了某些原因，一些 cache 服务器在保存和传输消息的时候可能
会转变实体主体的媒体类型。比如为了降低缓存空间或者在较慢的链接中减少传输流量，cache 服务器可能会
把一个图片的格式转换一下。但是某些应用场景下，数据的传输一个 bit 也不能转换，这里"no-transform"就非
常必须了。如果一个消息中包含了"no-transform"，那么非修改头部及其指定的消息主体部分都不能转换或者
改变，这些非修改头部包括"Content-Location", "Content-MD5", "ETag", "Last-Modified", "Expires", "Content-
Encoding", "Content-Range", "Content-Type"（参见 HTTP 1.1 section 13.5.2）
一般说来：遵循以下基本的规则
1. 如果响应头信息：告诉缓存器不要保留缓存，缓存器就不会缓存相应内容；
2. 如果请求信息是需要认证或者安全加密的，相应内容也不会被缓存；
3. 如果在回应中不存在校验器（ETag 或者 Last-Modified 头信息），缓存服务器会认为缺乏直接的更
新度信息，内容将会被认为不可缓存。
4. 一个缓存的副本如果含有以下信息：内容将会被认为是足够新的
o 含有完整的过期时间和寿命控制头信息，并且内容仍在保鲜期内；
o 浏览器已经使用过缓存副本，并且在一个会话中已经检查过内容的新鲜度；
o 缓存代理服务器近期内已经使用过缓存副本，并且内容的最后更新时间在上次使用期之前；
o 够新的副本将直接从缓存中送出，而不会向源服务器发送请求；
5. 如果缓存的副本已经太旧了，缓存服务器将向源服务器发出请求校验请求，用于确定是否可以继续
使用当前拷贝继续服务；
3.3 Response 响应的过期与保鲜
3.3.1 age 的计算方法
先介绍一下一个响应的 age 的计算方法。
/*
* age_value: is the value of Age: header received by the cache with this response.
* date_value: is the value of the origin server's Date: header

10. * request_time: is the (local) time when the cache made the request that resulted in this cached response
* response_time: is the (local) time when the cache received the response
* now: is the current (local) time
*/
apparent_age = max(0, response_time - date_value);
corrected_received_age = max(apparent_age, age_value);
response_delay = response_time - request_time;
corrected_initial_age = corrected_received_age + response_delay;
resident_time = now - response_time;
current_age = corrected_initial_age + resident_time;
3.3.2 过期时间的计算方法
过期时间主要分为 explicit expiration time 和 heuristic expiration time，强烈建议用户指定 explicit
expiration time，因为只有网页制作者更加清楚这个网页的过期时间。
先介绍一下 explicit expiration time 的计算方法。
客户可以通过设置 Expires 或者 Cache-control 的 max-age（max-age 优先级大于 Expires）来指定
explicit expiration time。我们测试了 html 和 php 语言设置 Expires 的方法，并且使用 ethereal 观察了传输的
HTTP 信息，在我们的环境下，发现使用 html 设置 header meta 不能反映到 HTTP header 中去，而 php 的
header()函数则能够成功。
php 设置 HTTP 头的方法很简单，只要调用函数 header()就可以了，假如我们新建一个名为
testHeader.php 的文件并将其内容修改为：
<?php
$offset = 3600 * 24;
$expire = "Expires: " . gmdate("D, d M Y H:i:s", time() + $offset) . " GMT";
Header($expire);

11. Header("Content-Language: zh-cn");
echo "success";
?>
当用户访问该网页时我们可以传输的信息找到这两个（Expires 和 Content-Language）HTTP 头。
meta 是用来在 HTML 文档中模拟 HTTP 协议的响应头报文。meta 标签用于网页的<head>与</head>中，
meta 的属性有两种：name 和 HTTP-equiv。name 属性主要用于描述网页，以便于搜索引擎机器人查找、分类。
HTTP-equiv 顾名思义，相当于 HTTP 的文件头作用，它可以向浏览器传回一些有用的信息，以帮助正确和
精确地显示网页内容，与之对应的属性值为 content，content 中的内容其实就是各个参数的变量值。
meat 标签的 HTTP-equiv 属性语法格式是：＜meta HTTP-equiv="参数" content="参数变量值"＞ ；其中
HTTP-equiv 属性主要有以下几种参数：
A、Expires(期限)
说明：可以用于设定网页的到期时间。一旦网页过期，必须到服务器上重新传输。
用法：＜meta HTTP-equiv="expires" content="Fri, 12 Jan 2001 18:18:18 GMT"＞
注意：必须使用 GMT 的时间格式。
B、Pragma(cache 模式)
说明：禁止浏览器从本地计算机的缓存中访问页面内容。
用法：＜meta HTTP-equiv="Pragma" content="no-cache"＞
注意：这样设定，访问者将无法脱机浏览。
C、Refresh(刷新)
说明：自动刷新并指向新页面。
用法：＜meta HTTP-equiv="Refresh" content="2；URL=HTTP://www.webjx.com"＞
注意：其中的 2 是指停留 2 秒钟后自动刷新到 URL 网址。
D、Set-Cookie(cookie 设定)
说明：如果网页过期，那么存盘的 cookie 将被删除。

12. 用法：＜meta HTTP-equiv="Set-Cookie" content="cookievalue=xxx; expires=Friday, 12-Jan-2001
18:18:18 GMT； path=/"＞
注意：必须使用 GMT 的时间格式。
E、Window-target(显示窗口的设定)
说明：强制页面在当前窗口以独立页面显示。
用法：＜meta HTTP-equiv="Window-target" content="_top"＞
注意：用来防止别人在框架里调用自己的页面。
F、content-Type(显示字符集的设定)
说明：设定页面使用的字符集。
用法：＜meta HTTP-equiv="content-Type" content="text/html; charset=gb2312"＞
我们在 index.htm 中的<header>中加入了：
<meta HTTP-equiv="Expires" content="Wed, 24 Jun 2009 09:19:31 GMTrn"/>
但是用户访问网页时返回的 response 的 HTTP header 中找不到 Expires。
接下来，介绍一下 heuristic expiration time 的计算方法。
而 freshness_lifetime 计算方法如下：
如果存在 cache-control 的 max-age（或者 s-maxage）值，则：freshness_lifetime = max_age_value
否则如果存在 Expires 值，则：freshness_lifetime = expires_value - date_value
如果上述两个值都不存在，而且响应中也没有包含其他的限制条件时，cache 服务器可以使用一种启发
式规则来计算获得 freshness_lifetime（如果计算得到的 freshness_lifetime 大于 24 小时并且年龄值也超过 24
小时则必须在 response 响应中增加 warning 113），但响应中包含有 Last-Modified 值时，原则上
freshness_lifetime 不应该超过从 Last-Modified 到现在经过的时间值的一定比例（比如：10%）。这个计算
freshness_lifetime 启发式规则是由 cache 服务器自己制定的。比如，squid 的启发式规则主要是由用户制定的
refresh_pattern 规则指定。

13. 3.3.3 过期或者保鲜
当 age 值和 freshness_lifetime 都得到了以后，计算一个响应是否过期就简单了：
response_is_fresh = (freshness_lifetime > current_age)
3.4 Validation 验证
在 HTTP1.1 中对缓存进一步提出了验证的概念。验证的目的就是检验缓存项目是否在有效期内。当
cache 服务器存在一个过期的消息，并且对应的 request 请求到达时，它应该首先向服务器或者链路上的其
他保存有未过期的 cache 服务器请求验证来确定本地的 response 是否可用。这个过程就是一个 cache 消息的
验证过程。HTTP 1.1 提供了有条件的请求返回方法（conditional methods），这样当本地 response 是可用时
就可以减少网络流量不用传输整个 response 的信息，而当本地 response 不可用时也可以减少链路上请求多
一个来回的消耗。当源服务器生成了一个完整的 response 时，它会附带一个验证子（validator）；cache 服
务器可以保存它，在 response 过期以后，可以利用它生成一个有条件的 request 以向源服务器请求验证。而
服务器（源服务器或者链路上保存有未过期的 cache 服务器）收到这样的请求以后就可以用它与自己的
validator 比较，如果相等，那么只返回一个带有特定状态码（通常是：304 Not Modified），并且消息主体为
空的 response，在这种情况下就减少了网络流量；如果两个 validator 不相等就传输一个完整的 response，
在这种情况下避免了客户端再次提交 request，从而减少了一次通讯往返。事实上，所谓的有条件的 request
和普通的 request 是一样的，只是它包含了一个特殊的 Header 和 validator。并且有条件的验证包括正验证和
负验证，如果 request 中要求服务器与附带的 validator 必须相等的是正验证，如果要求两者不相等的是指负
验证。
validator 主要包括 Last-Modified Dates 和 Entity Tag Cache Validators 两种，分别对应了"Last-
Modified"和"ETag"两个 Header。当一个 response 在"Last-Modified"之后没有被修改过可以认为它是有效的。
它是被经常用来验证一个 response 是否有效的 validator。它对应的对应的 request 请求头包括："If-Modified-
Since"，"If-Unmodified-Since"。但是，"Last-Modified"是有缺陷的，因为 HTTP 协议的时间值是以秒为单位的，
如果一个 response 在一秒内被修改了两次，那么验证某个 response 是否一致就没有办法了。所以在这种情
况下或者源服务器希望避免使用时间的修改来匹配两个数据时，就可以用"ETag"。"ETag"可以由源服务器指
定计算方法，根据 response 生成，它是一个不透明的 validator。对应的 request 请求头包括："If-Match"，"If-
None-Match"，"If-Range"。
两个 validator 之间的比较可以分为强验证子比较或者弱验证子比较。强验证子比较表示每一个字节都要
相等，而弱验证子比较主要是指实体相等，可以在不明显改变语义的基础上相互替换。弱验证子比较仅仅用
于在弱验证子上的比较，比如：在 Entity Tag 前面有"W/"则表示这是一个弱 validator。一个实体的修改时间可
以被认为是弱验证子。弱验证子可以应用于不要求精确一致的情况下，强验证子比较应用比较广泛，几乎所
有的场合都可以用。如果用户提交的 request 只需要 response 的一部分（sub-range）那么必须要保证使用强
验证以获得正确的数据。

14. 4 其他建议
4.1 进一步工作
了解 apache 和 squid 的 cache 实现以及相关配置，并结合本公司网站以及相关数据部署和测试。加快用
户访问速度，提交同时可访问的用户数，加强它们的鲁棒形以及服务可用性。为以后公司的产品和项目提供
支持。
另外，研究网页制作者增加缓存头部域需要遵守的规范，为网页制作者有意识的增加缓存，控制缓存时
间等提供参考。

15. 5 相关文档列表
HTTP 1.1
Squid Cache 服务器安装配置与测试数据
squid 服务器用户手册 v0.2