HTTP Cache 学习
http协议里控制浏览器缓存的头有三个Cache-Control，Expires，Last-Modified
对于静态页面还有Etag。
一、先来看第一种情况：apache 静态页面
apache发送给客户端的静态页面一般包含Last-Modified和Etag，这两个标签的值来自静态文件的修改时间和inode，
下面是截取得apache返回客户端的头
---------
Last-Modified: Fri, 26 Jan 2007 01:53:34 GMT
ETag: "3f9f640-318-cb9f8380"
---------
搜索引擎之所以喜欢静态文件是因为有这两个标识，可以判断文件是否更新过
二、PHP等动态页面
由于php是动态生成的，它的内容是不能根据php程序的时间来确定最后修改日期，所以默认php返回客户端的时候补包含任何缓存控制，要想利用好缓存就必须了解缓存机制，和理减少b,s的交互，缩减带宽流量，减轻服务器负担...好处多多
三、缓存控制的具体含义
先解释一下本人经过测试理解的这几个标签的含义
Cache-Control:指定请求和响应遵循的缓存机制。在请求消息或响应消息中设置Cache-Control并不会修改另一个消息处理过程中的缓 存处理过程。请求时的缓存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if- cached，响应消息中的指令包括public、private、no-cache、no-store、no-transform、must- revalidate、proxy-revalidate、max-age。各个消息中的指令含义如下：
Public指示响应可被任何缓存区缓存。
Private指示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这允许服务器仅仅描述当用户的部分响应消息，此响应消息对于其他用户的请求无效。
no-cache指示请求或响应消息不能缓存
no-store用于防止重要的信息被无意的发布。在请求消息中发送将使得请求和响应消息都不使用缓存。
max-age指示客户机可以接收生存期不大于指定时间（以秒为单位）的响应。
min-fresh指示客户机可以接收响应时间小于当前时间加上指定时间的响应。
max-stale指示客户机可以接收超出超时期间的响应消息。如果指定max-stale消息的值，那么客户机可以接收超出超时期指定值之内的响应消息。
php用法：
在输出之前用header()，（如果使用ob_start()可以将header放在程序任意地方）
header('Cache-Control: max-age=8');
max-age=8表示最大生存期8秒，超过8秒浏览器必须去服务器重新读取，这个时间是以用户的读取页面开始计时的，而Expires是绝对时间。
Expires：缓存过期的绝对时间，如果过了它指定的那个时间点，浏览器就不认缓存了，要去服务器重新请求一份最新的。
Last-Modified：文档的最后修改时间，它的妙用就是：1 如果是静态文件，客户端会发上来它缓存里的时间，apache会来比对，如果发现没有修改就直接返回一个头，状态码是304，字节数非常少，（高级版本还会增加比较Etag来确定文件是否变化）
2 php动态文件: 客户端发上比对时间，php会判断是否修改，如果修改时间相同，就只会返回1024字节，至于为什么返回1024不得而知，如果你 的php生成的文件非常大，它也只返回1024，所以比较省带宽，客户端会根据服务器端发过来的修改时间自动从缓存文件里显示。
注：如果没有Last-Modified头，Cache-Control和Expires也是可以起作用的，但每次请求要返回真实的文件字节数，而不是1024
四、HOW ?
静态页面不用去管它了，如果想更好的控制静态页面的缓存，apache有几个模块可以很好的控制，这里不讨论
php页面：
这里分两种：1 不经常改动的页面，类似新闻发布，这类页面的特点：第一次发布之后会有几次改动，随着时间推移基本不会再修改。控制策略应该是：1第一次 发布之发送Last-Modified，max-age设定1天，修改过之后更新Last-Modified，max-age时间随着修改次数正常。这样 似乎比较繁琐，还要记录修改次数，也可以预计一下下次可能的修改时间用Expires指定到大概时间过期
php代码：
//header('Cache-Control: max-age=86400');//缓存一天
header('Expires: Mon, 29 Jan 2007 08:56:01 GMT');//指定过期时间
header('Last-Modified: '.gmdate('D, d M Y 01:01:01',$time).' GMT');//格林尼治时间,$time是文件添加时候的时间戳
2 经常改动的页面 类似bbs，论坛程序，这种页面更新速度比较快，缓存的主要作用是防止用户频繁刷新列表，导致服务器数据库负担，既要保证更新的及时性，也要保证缓存能被利用
这里一般用Cache-Control来控制，根据论坛的发帖的频率灵活控制max-age。
header('Cache-Control: max-age=60');//缓存一分钟
header('Last-Modified: '.gmdate('D, d M Y 01:01:01',$time).' GMT');//格林尼治时间,$time是帖子的最后更新时间戳
五 额外
1 刷新，转到，强制刷新的区别
浏览器上有刷新和转到按键，有的浏览器支持用ctrl+F5强制刷新页面，它们的区别是什么？
转到：用户点击链接就是转到，它完全使用缓存机制，如果有Last-Modified那么不会和服务器通讯，用抓包工具可以查看到发送字节是0byte，如果缓存过期，那么它会执行F5刷新的动作。
刷新(F5)：这种刷新也是根据缓存是否有Last-Modified来决定，如果有会转入304或1024(php)，如果没有最后更新时间那么去服务器读取，返回真实文档大小
强制刷新：完全抛弃缓存机制，去服务器读取最新文档，向服务器发送的header如下
Cache-Control: no-cache
2 调试工具
查看浏览器和服务器交互比较好的工具是httpwatch pro，现在的版本4.1，支持ie7
还有别的代理抓包工具可以分析，http debugging。没用过，还有tcp抓包工具，2000自带的network monitor不过不是专门针对http的比较难用
六 声明
本文作者保留所有权力，允许被*查看和转载，但必须指明作者(Ash)和源网址(www.cosrc.com)；不允许商用
下面是HTTP 协议 E文原版
Cache-Control
The general-header field "Cache-Control" is used to specify
directives that MUST be obeyed by all caches along the request/
response chain. The directives specify behavior intended to prevent
caches from adversely interfering with the request or response.
Cache directives are unidirectional in that the presence of a
directive in a request does not imply that the same directive is to
be given in the response.
Note that HTTP/1.0 caches might not implement Cache-Control and
might only implement Pragma: no-cache (see Section 3.4).
Cache directives MUST be passed through by a proxy or gateway
application, regardless of their significance to that application,
since the directives might be applicable to all recipients along the
request/response chain. It is not possible to target a directive to
a specific cache.
Fielding, et al. Expires September 10, 2009 [Page 17]
Internet-Draft HTTP/1.1, Part 6 March 2009
Cache-Control = "Cache-Control" ":" OWS Cache-Control-v
Cache-Control-v = 1#cache-directive
cache-directive = cache-request-directive
/ cache-response-directive
cache-extension = token [ "=" ( token / quoted-string ) ]
3.2.1. Request Cache-Control Directives
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
no-cache
The no-cache request directive indicates that a stored response
MUST NOT be used to satisfy the request without successful
validation on the origin server.
no-store
The no-store request directive indicates that a cache MUST NOT
store any part of either this request or any response to it. This
directive applies to both non-shared and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile
storage as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for
ensuring privacy. In particular, malicious or compromised caches
might not recognize or obey this directive, and communications
networks may be vulnerable to eavesdropping.
max-age
The max-age request directive indicates that the client is willing
to accept a response whose age is no greater than the specified
time in seconds. Unless max-stale directive is also included, the
client is not willing to accept a stale response.
Fielding, et al. Expires September 10, 2009 [Page 18]
Internet-Draft HTTP/1.1, Part 6 March 2009
max-stale
The max-stale request directive indicates that the client is
willing to accept a response that has exceeded its expiration
time. If max-stale is assigned a value, then the client is
willing to accept a response that has exceeded its expiration time
by no more than the specified number of seconds. If no value is
assigned to max-stale, then the client is willing to accept a
stale response of any age. [[anchor15: of any staleness? --mnot]]
min-fresh
The min-fresh request directive indicates that the client is
willing to accept a response whose freshness lifetime is no less
than its current age plus the specified time in seconds. That is,
the client wants a response that will still be fresh for at least
the specified number of seconds.
no-transform
The no-transform request directive indicates that an intermediate
cache or proxy MUST NOT change the Content-Encoding, Content-Range
or Content-Type request headers, nor the request entity-body.
only-if-cached
The only-if-cached request directive indicates that the client
only wishes to return a stored response. If it receives this
directive, a cache SHOULD either respond using a stored response
that is consistent with the other constraints of the request, or
respond with a 504 (Gateway Timeout) status. If a group of caches
is being operated as a unified system with good internal
connectivity, such a request MAY be forwarded within that group of
caches.
Fielding, et al. Expires September 10, 2009 [Page 19]
Internet-Draft HTTP/1.1, Part 6 March 2009
3.2.2. Response Cache-Control Directives
cache-response-directive =
"public"
/ "private" [ "=" DQUOTE 1#field-name DQUOTE ]
/ "no-cache" [ "=" DQUOTE 1#field-name DQUOTE ]
/ "no-store"
/ "no-transform"
/ "must-revalidate"
/ "proxy-revalidate"
/ "max-age" "=" delta-seconds
/ "s-maxage" "=" delta-seconds
/ cache-extension
public
The public response directive indicates that the response MAY be
cached, even if it would normally be non-cacheable or cacheable
only within a non-shared cache. (See also Authorization, Section
3.1 of [Part7], for additional details.)
private
The private response directive indicates that the response message
is intended for a single user and MUST NOT be stored by a shared
cache. A private (non-shared) cache MAY store the response.
If the private response directive specifies one or more field-
names, this requirement is limited to the field-values associated
with the listed response headers. That is, the specified field-
names(s) MUST NOT be stored by a shared cache, whereas the
remainder of the response message MAY be.
Note: This usage of the word private only controls where the
response may be stored, and cannot ensure the privacy of the
message content.
no-cache
The no-cache response directive indicates that the response MUST
NOT be used to satisfy a subsequent request without successful
validation on the origin server. This allows an origin server to
prevent caching even by caches that have been configured to return
stale responses.
If the no-cache response directive specifies one or more field-
names, this requirement is limited to the field-values assosicated
with the listed response headers. That is, the specified field-
Fielding, et al. Expires September 10, 2009 [Page 20]
Internet-Draft HTTP/1.1, Part 6 March 2009
name(s) MUST NOT be sent in the response to a subsequent request
without successful validation on the origin server. This allows
an origin server to prevent the re-use of certain header fields in
a response, while still allowing caching of the rest of the
response.
Note: Most HTTP/1.0 caches will not recognize or obey this
directive.
no-store
The no-store response directive indicates that a cache MUST NOT
store any part of either the immediate request or response. This
directive applies to both non-shared and shared caches. "MUST NOT
store" in this context means that the cache MUST NOT intentionally
store the information in non-volatile storage, and MUST make a
best-effort attempt to remove the information from volatile
storage as promptly as possible after forwarding it.
This directive is NOT a reliable or sufficient mechanism for
ensuring privacy. In particular, malicious or compromised caches
might not recognize or obey this directive, and communications
networks may be vulnerable to eavesdropping.
must-revalidate
The must-revalidate response directive indicates that once it has
become stale, the response MUST NOT be used to satisfy subsequent
requests without successful validation on the origin server.
The must-revalidate directive is necessary to support reliable
operation for certain protocol features. In all circumstances an
HTTP/1.1 cache MUST obey the must-revalidate directive; in
particular, if the cache cannot reach the origin server for any
reason, it MUST generate a 504 (Gateway Timeout) response.
Servers SHOULD send the must-revalidate directive if and only if
failure to validate a request on the entity could result in
incorrect operation, such as a silently unexecuted financial
transaction.
proxy-revalidate
The proxy-revalidate response directive has the same meaning as
the must-revalidate response directive, except that it does not
apply to non-shared caches.
max-age
Fielding, et al. Expires September 10, 2009 [Page 21]
Internet-Draft HTTP/1.1, Part 6 March 2009
The max-age response directive indicates that response is to be
considered stale after its age is greater than the specified
number of seconds.
s-maxage
The s-maxage response directive indicates that, in shared caches,
the maximum age specified by this directive overrides the maximum
age specified by either the max-age directive or the Expires
header. The s-maxage directive also implies the semantics of the
proxy-revalidate response directive.
no-transform
The no-transform response directive indicates that an intermediate
cache or proxy MUST NOT change the Content-Encoding, Content-Range
or Content-Type response headers, nor the response entity-body.
3.2.3. Cache Control Extensions
The Cache-Control header field can be extended through the use of one
or more cache-extension tokens, each with an optional value.
Informational extensions (those that do not require a change in cache
behavior) can be added without changing the semantics of other
directives. Behavioral extensions are designed to work by acting as
modifiers to the existing base of cache directives. Both the new
directive and the standard directive are supplied, such that
applications that do not understand the new directive will default to
the behavior specified by the standard directive, and those that
understand the new directive will recognize it as modifying the
requirements associated with the standard directive. In this way,
extensions to the cache-control directives can be made without
requiring changes to the base protocol.
This extension mechanism depends on an HTTP cache obeying all of the
cache-control directives defined for its native HTTP-version, obeying
certain extensions, and ignoring all directives that it does not
understand.
For example, consider a hypothetical new response directive called
"community" that acts as a modifier to the private directive. We
define this new directive to mean that, in addition to any non-shared
cache, any cache that is shared only by members of the community
named within its value may cache the response. An origin server
wishing to allow the UCI community to use an otherwise private
response in their shared cache(s) could do so by including
Cache-Control: private, community="UCI"
Fielding, et al. Expires September 10, 2009 [Page 22]
Internet-Draft HTTP/1.1, Part 6 March 2009
A cache seeing this header field will act correctly even if the cache
does not understand the community cache-extension, since it will also
see and understand the private directive and thus default to the safe
behavior.
Unrecognized cache directives MUST be ignored; it is assumed that any
cache directive likely to be unrecognized by an HTTP/1.1 cache will
be combined with standard directives (or the response's default
cacheability) such that the cache behavior will remain minimally
correct even if the cache does not understand the extension(s).
3.3. Expires
The entity-header field "Expires" gives the date/time after which the
response is considered stale. See Section 2.3 for further discussion
of the freshness model.
The presence of an Expires field does not imply that the original
resource will change or cease to exist at, before, or after that
time.
The field-value is an absolute date and time as defined by HTTP-date
in Section 3.2.1 of [Part1]; it MUST be sent in rfc1123-date format.
Expires = "Expires" ":" OWS Expires-v
Expires-v = HTTP-date
For example
Expires: Thu, 01 Dec 1994 16:00:00 GMT
Note: if a response includes a Cache-Control field with the max-
age directive (see Section 3.2.2), that directive overrides the
Expires field. Likewise, the s-maxage directive overrides Expires
in shared caches.
HTTP/1.1 servers SHOULD NOT send Expires dates more than one year in
the future.
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
http://www.ietf.org/internet-drafts/draft-ietf-httpbis-p6-cache-06.txt