|
http協(xié)議里控制瀏覽器緩存的頭有三個Cache-Control，Expires，Last-Modified
對于靜態(tài)頁面還有Etag。
一、先來看第一種情況：apache 靜態(tài)頁面
apache發(fā)送給客戶端的靜態(tài)頁面一般包含Last-Modified和Etag，這兩個標(biāo)簽的值來自靜態(tài)文件的修改時間和inode，
下面是截取得apache返回客戶端的頭
---------
Last-Modified: Fri, 26 Jan 2007 01:53:34 GMT
ETag: "3f9f640-318-cb9f8380"
---------
搜索引擎之所以喜歡靜態(tài)文件是因為有這兩個標(biāo)識，可以判斷文件是否更新過
二、PHP等動態(tài)頁面
由于php是動態(tài)生成的，它的內(nèi)容是不能根據(jù)php程序的時間來確定最后修改日期，所以默認(rèn)php返回客戶端的時候補(bǔ)包含任何緩存控制，要想利用好緩存就必須了解緩存機(jī)制，和理減少b,s的交互，縮減帶寬流量，減輕服務(wù)器負(fù)擔(dān)...好處多多
三、緩存控制的具體含義
先解釋一下本人經(jīng)過測試?yán)斫獾倪@幾個標(biāo)簽的含義
Cache-Control:指定請求和響應(yīng)遵循的緩存機(jī)制。在請求消息或響應(yīng)消息中設(shè)置Cache-Control并不會修改另一個消息處理過程中的緩 存處理過程。請求時的緩存指令包括no-cache、no-store、max-age、max-stale、min-fresh、only-if- cached，響應(yīng)消息中的指令包括public、private、no-cache、no-store、no-transform、must- revalidate、proxy-revalidate、max-age。各個消息中的指令含義如下：
Public指示響應(yīng)可被任何緩存區(qū)緩存。
Private指示對于單個用戶的整個或部分響應(yīng)消息，不能被共享緩存處理。這允許服務(wù)器僅僅描述當(dāng)用戶的部分響應(yīng)消息，此響應(yīng)消息對于其他用戶的請求無效。
no-cache指示請求或響應(yīng)消息不能緩存
no-store用于防止重要的信息被無意的發(fā)布。在請求消息中發(fā)送將使得請求和響應(yīng)消息都不使用緩存。
max-age指示客戶機(jī)可以接收生存期不大于指定時間（以秒為單位）的響應(yīng)。
min-fresh指示客戶機(jī)可以接收響應(yīng)時間小于當(dāng)前時間加上指定時間的響應(yīng)。
max-stale指示客戶機(jī)可以接收超出超時期間的響應(yīng)消息。如果指定max-stale消息的值，那么客戶機(jī)可以接收超出超時期指定值之內(nèi)的響應(yīng)消息。
php用法：
在輸出之前用header()，（如果使用ob_start()可以將header放在程序任意地方）
header('Cache-Control: max-age=8');
max-age=8表示最大生存期8秒，超過8秒瀏覽器必須去服務(wù)器重新讀取，這個時間是以用戶的讀取頁面開始計時的，而Expires是絕對時間。
Expires：緩存過期的絕對時間，如果過了它指定的那個時間點，瀏覽器就不認(rèn)緩存了，要去服務(wù)器重新請求一份最新的。
Last-Modified：文檔的最后修改時間，它的妙用就是：1 如果是靜態(tài)文件，客戶端會發(fā)上來它緩存里的時間，apache會來比對，如果發(fā)現(xiàn)沒有修改就直接返回一個頭，狀態(tài)碼是304，字節(jié)數(shù)非常少，（高級版本還會增加比較Etag來確定文件是否變化）
2 php動態(tài)文件: 客戶端發(fā)上比對時間，php會判斷是否修改，如果修改時間相同，就只會返回1024字節(jié)，至于為什么返回1024不得而知，如果你 的php生成的文件非常大，它也只返回1024，所以比較省帶寬，客戶端會根據(jù)服務(wù)器端發(fā)過來的修改時間自動從緩存文件里顯示。
注：如果沒有Last-Modified頭，Cache-Control和Expires也是可以起作用的，但每次請求要返回真實的文件字節(jié)數(shù)，而不是1024
四、HOW ?
靜態(tài)頁面不用去管它了，如果想更好的控制靜態(tài)頁面的緩存，apache有幾個模塊可以很好的控制，這里不討論
php頁面：
這里分兩種：1 不經(jīng)常改動的頁面，類似新聞發(fā)布，這類頁面的特點：第一次發(fā)布之后會有幾次改動，隨著時間推移基本不會再修改。控制策略應(yīng)該是：1第一次 發(fā)布之發(fā)送Last-Modified，max-age設(shè)定1天，修改過之后更新Last-Modified，max-age時間隨著修改次數(shù)正常。這樣 似乎比較繁瑣，還要記錄修改次數(shù)，也可以預(yù)計一下下次可能的修改時間用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 經(jīng)常改動的頁面 類似bbs，論壇程序，這種頁面更新速度比較快，緩存的主要作用是防止用戶頻繁刷新列表，導(dǎo)致服務(wù)器數(shù)據(jù)庫負(fù)擔(dān)，既要保證更新的及時性，也要保證緩存能被利用
這里一般用Cache-Control來控制，根據(jù)論壇的發(fā)帖的頻率靈活控制max-age。
header('Cache-Control: max-age=60');//緩存一分鐘
header('Last-Modified: '.gmdate('D, d M Y 01:01:01',$time).' GMT');//格林尼治時間,$time是帖子的最后更新時間戳
五 額外
1 刷新，轉(zhuǎn)到，強(qiáng)制刷新的區(qū)別
瀏覽器上有刷新和轉(zhuǎn)到按鍵，有的瀏覽器支持用ctrl+F5強(qiáng)制刷新頁面，它們的區(qū)別是什么？
轉(zhuǎn)到：用戶點擊鏈接就是轉(zhuǎn)到，它完全使用緩存機(jī)制，如果有Last-Modified那么不會和服務(wù)器通訊，用抓包工具可以查看到發(fā)送字節(jié)是0byte，如果緩存過期，那么它會執(zhí)行F5刷新的動作。
刷新(F5)：這種刷新也是根據(jù)緩存是否有Last-Modified來決定，如果有會轉(zhuǎn)入304或1024(php)，如果沒有最后更新時間那么去服務(wù)器讀取，返回真實文檔大小
強(qiáng)制刷新：完全拋棄緩存機(jī)制，去服務(wù)器讀取最新文檔，向服務(wù)器發(fā)送的header如下
Cache-Control: no-cache
2 調(diào)試工具
查看瀏覽器和服務(wù)器交互比較好的工具是httpwatch pro，現(xiàn)在的版本4.1，支持ie7
還有別的代理抓包工具可以分析，http debugging。沒用過，還有tcp抓包工具，2000自帶的network monitor不過不是專門針對http的比較難用
六 聲明
本文作者保留所有權(quán)力，允許被自由查看和轉(zhuǎn)載，但必須指明作者(Ash)和源網(wǎng)址(www.cosrc.com)；不允許商用 下面是HTTP 協(xié)議 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./internet-drafts/draft-ietf-httpbis-p6-cache-06.txt
|
