緩存的定義

Web緩存是可以自動保存常見文檔副本的HTTP設備（包括瀏覽器？）

緩存的作用

1. 減少冗余數據傳輸
2. 緩解帶寬瓶頸（很多網絡為本地網絡客戶端提供的帶寬比為遠程服務器提供的帶寬要寬）
3. 緩解瞬時擁塞（不會所有的請求都奔著一臺服務器去）
4. 降低距離時延（就近訪問么）

命中、非命中

1. 命中率：請求命中緩存的比例
2. 字節命中率：請求命中緩存的文檔，其文檔大小總和，占所有請求大小總和的比例（一些大文檔盡管訪問少，但對流量貢獻大，對于按流量計費的人來說很重要）

客戶端如何判斷請求是否命中緩存：它能夠過Date首部，如果Date的值比當前日期值要早，那么可以認為是緩存的響應。

如何保持副本的新鮮

HTTP通過以下兩種機制來實現這樣的目的：不要求服務器記住哪些緩存擁有資源副本，同時保持已緩存數據與服務器數據之間的一致。

1. 文檔過期（document expiration）—— Cache-Control、Expires
2. 服務器再驗證（server revalidation）—— If-Modified-Since（時間）、If-None-Match（結合ETag）

文檔過期：相關的header

Expires

HTTP 1.0引入，指定實際的過期時間，而不是秒數。不推薦使用，原因：很多服務器的始終不同步或不正確。使用舉例：

Expires: Fri, 05 Jul 2002, 05:00:00 GMT

Cache-Control: max-age

從服務器將資源傳送過來時算起，文檔處于新鮮的時間（單位為秒）。可通過將其設為0，來請求緩存（服務器）不要緩存資源。舉例：

Cache-Control: max-age=0

Cache-Control: no-cache

名字比較有歧義，實際表達的意思是：緩存（服務器）在與原始服務器進行新鮮度再驗證前，不能將資源提供給客戶端使用。這里包含兩個點：

1. 標識為no-cache的響應實際是可以存儲在本地緩沖區的
2. 必須每次與原始服務器再校驗

舉例：

Cache-Control: no-cache

Cache-Control: no-store

帶有no-store的響應，會禁止緩存對資源進行復制。緩存向客戶端轉發no-store響應后，會將副本刪除。

Cache-Control: must-revalidate

可以使用陳舊（過期）的資源以提高性能。但在沒有與原始服務器進行再驗證的情況下，不能使用資源的陳舊副本。

與no-cache的區別：

1. no-cache：無論資源副本是否過期，都必須與原始服務器進行校驗
2. must-revalidate：資源副本過期前，無需校驗；過期后，須校驗，如原始服務器上的資源沒變化，那么緩存可以提供陳舊的副本。（減少資源傳輸）

服務器再驗證

If-Modified-Since（IMS）

詢問服務器，資源在If-Modified-Since指定的時間之后，是否被修改了，如果

1. 沒被修改：返回304 Not Modified響應報文，同時只會發送需要在源端更新的首部，比如新的過期時間。
2. 被修改了：攜帶新首部的資源會被返回給緩存，包括新的過期時間。

例子：

If-Modified-Since: Sat, 29 Jun 2002, 14:30:00 GMT

If-None-Match

ETag：實體標簽（Entity Tag）。ETag再驗證的原因：

1. 有些文檔會被周期性地重寫，但實際包含的數據常常是一樣的，但修改時間已經發生變化。
2. 文檔被修改了，但修改并不重要，不需要讓所有緩存都失效。
3. 某些服務器無法準確判斷資源的最后修改時間。

流程與If-Modified-Since差不多，帶上ETag去服務器查詢，如果

1. ETag發生變化：返回帶有新ETag的資源
2. ETag沒變化：返回304 Not Modified

例子：

If-None-Match: "v2.6
If-None-Match: "v2.6","v2.7"（告訴服務器，帶有這些實體標簽的副本緩存上已有了）