快取對於web開發有重要作用，尤其是大負荷web系統開發中。

快取分很多種：伺服器快取，第三方快取，瀏覽器快取等。其中瀏覽器快取是代價最小的，因為瀏覽器快取依賴的是客戶 端，而幾乎不耗費伺服器端的資源。

讓瀏覽器做快取需要給瀏覽器傳送指定的Http頭，告訴瀏覽器快取多長時間，或者堅決不要快取。

1.Expires（過期時間）HTTP頭資訊Expires（過期時間） 屬性是HTTP控制快取的基本手段，這個屬性告訴快取器：相關副本在多長時間內是新鮮的。過了這個時間，快取器就會向源伺服器傳送請求，檢查文件是否被修 改。幾乎所有的快取伺服器都支援Expires（過期時間）屬性；

大部分Web伺服器支援你用幾種方式設定Expires屬性；一般 的：可以設計一個絕對時間間隔：基於客戶最後檢視副本的時間（最後訪問時間）或者根據伺服器上文件最後被修改的時間；

Expires 頭資訊：對於設定靜態圖片檔案（例如導航欄和圖片按鈕）可快取特別有用；因為這些圖片修改很少，你可以給它們設定一個特別長的過期時間，這會使你的網站對 使用者變得相應非常快；他們對於控制有規律改變的網頁也很有用，例如：你每天早上6點更新新聞頁，你可以設定副本的過期時間也是這個時間，這樣快取 伺服器就知道什麼時候去取一個更新版本，而不必讓使用者去按瀏覽器的“重新整理”按鈕。

過期時間頭資訊屬性值只能是HTTP格式的日期時間，其他的都會被解析成當前時間“之前”，副本會過期，記住：HTTP的日期時間必須是格林威治時 間（GMT），而不是本地時間。舉例：
Expires: Fri, 30 Oct 1998 14:19:41

所以使用過期時間屬性一定要確認你的Web伺服器時間設定正確，一個途徑是通過網路時間同步協議（Network Time Protocol NTP），和你的系統管理員那裡你可以瞭解更多細節。

雖然過期時間屬性非常有用，但是它還是有些侷限，首先：是牽扯到了日期，這樣Web伺服器的時間和快取伺服器的時間必須是同步的，如果有些不同步， 要麼是應該快取的內容提前過期了，要麼是過期結果沒及時更新。

還有一個過期時間設定的問題也不容忽視：如果你設定的過期時間是一個固定的時間，如果你返回內容的時候又沒有連帶更新下次過期的時間，那麼之後所有 訪問請求都會被髮送給源Web伺服器，反而增加了負載和響應時間；

2.Cache-Control（快取控制） HTTP頭資訊

HTTP 1.1介紹了另外一組頭資訊屬性：Cache-Control響應頭資訊，讓網站的釋出者可以更全面的控制他們的內容，並定位過期時間的限制。
有 用的 Cache-Control響應頭資訊包括：

max-age=[秒] — 執行快取被認為是最新的最長時間。類似於過期時間，這個引數是基於請求時間的相對時間間隔，而不是絕對過期時間，[秒]是一個數字，單位是秒：從請求時間 開始到過期時間之間的秒數。
s-maxage=[秒] — 類似於max-age屬性，除了他應用於共享（如：代理伺服器）快取
public — 標記認證內容也可以被快取，一般來說： 經過HTTP認證才能訪問的內容，輸出是自動不可以快取的；
no-cache — 強制每次請求直接傳送給源伺服器，而不經過本地快取版本的校驗。這對於需要確認認證應用很有用（可以和public結合使用），或者嚴格要求使用最新資料 的應用（不惜犧牲使用快取的所有好處）；
no-store — 強制快取在任何情況下都不要保留任何副本
must-revalidate — 告訴快取必須遵循所有你給予副本的新鮮度的，HTTP允許快取在某些特定情況下返回過期資料，指定了這個屬性，你快取記憶體，你希望嚴格的遵循你的規則。
proxy-revalidate — 和 must-revalidate類似，除了他只對快取代理伺服器起作用
舉例:
Cache-Control: max-age=3600, must-revalidate

給靜態資源(HTML檔案，圖片檔案等）的Repsone加上Expires/Cache-Control Header是很有效的一招。如果HTTP Response中有Expires這樣的Header的話，瀏覽器會Cache這個資源，理想狀況下（注意，只是理想狀況），在Expire Date之前，不會再發HTTP請求給Server要這個資源，不過Expires的值只能是一個固定日期，比如“Thu 27 Nov 2008 07:00:00 GMT”，不能是一個類似“從現在開始之後10年”這樣一個隨機浮動的值，如果要這樣的效果，可以用Cache-Control這樣的Header，如果 HTTP Response中有這樣的Header:“Cache-Control: max-age = 100”，表示這個資源在cache中的最大壽命是100秒。一般說來這種靜態檔案永遠不應該過期，如果真的要給這個Cache加上一個期限，那我希望是 ——一萬年，“Cache-Control: max-age = 315360000000”

其實就應該給Expires設一個永遠不會過期的時間，比如你現在有一個檔案叫logo.gif，需要用一個新的logo的時候，你不要去 覆蓋原來的檔案，而把新的logo存成logo_v2.gif，讓相關網頁引用新的logo_v2.gif，這樣可以讓新老網頁同時工作，實在犯不上為了 節省儲存空間覆蓋原有檔案。

對Apache伺服器，使用mod_expires，在httpd.conf或者.htaccess中加上

3.Last-Modified/If-Modified-Since

有些資料隨時都在變化。 CNN.com 的主頁經常幾分鐘就更新。另一方面，Google.com 的主頁幾個星期才更新一次 (當他們上傳特殊的假日 logo，或為一個新服務作廣告時)。 Web 服務是不變的：通常伺服器知道你所請求的資料的最後修改時間，並且 HTTP 為伺服器提供了一種將最近修改資料連同你請求的資料一同傳送的方法。

如果你第二次 (或第三次，或第四次) 請求相同的資料，你可以告訴伺服器你上一次獲得的最後修改日期：在你的請求中傳送一個 If-Modified-Since 頭資訊，它包含了上一次從伺服器連同資料所獲得的日期。如果資料從那時起沒有改變，伺服器將返回一個特殊的 HTTP 狀態程式碼 304，這意味著 “從上一次請求後這個資料沒有改變”。這一點有何進步呢？當伺服器傳送狀態編碼 304 時，不再重新發送資料。您僅僅獲得了這個狀態程式碼。所以當資料沒有更新時，你不需要一次又一次地下載相同的資料；伺服器假定你有本地的快取資料。

所有現代的瀏覽器都支援最近修改 (last-modified) 的資料檢查。如果你曾經訪問過某頁，一天後重新訪問相同的頁時發現它沒有變化，並奇怪第二次訪問時頁面載入得如此之快——這就是原因所在。你的瀏覽器首次 訪問時會在本地快取頁面內容，當你第二次訪問，瀏覽器自動傳送首次訪問時從伺服器獲得的最近修改日期。伺服器簡單地返回 304: Not Modified (沒有修改)，因此瀏覽器就會知道從本地快取載入頁面。在這一點上，Web 服務也如此智慧。

4. ETag/If-None-Match

ETag 是實現與最近修改資料檢查同樣的功能的另一種方法：沒有變化時不重新下載資料。其工作方式是：伺服器傳送你所請求的資料的同時，傳送某種資料的 hash (在 ETag 頭資訊中給出)。hash 的確定完全取決於伺服器。當第二次請求相同的資料時，你需要在 If-None-Match: 頭資訊中包含 ETag hash，如果資料沒有改變，伺服器將返回 304 狀態程式碼。與最近修改資料檢查相同，伺服器僅僅 傳送 304 狀態程式碼；第二次將不為你傳送相同的資料。在第二次請求時，通過包含 ETag hash，你告訴伺服器：如果 hash 仍舊匹配就沒有必要重新發送相同的資料，因為你還有上一次訪問過的資料。

這幾個http頭可以作為meta標籤傳送到客戶端，但是需要注意的是Http頭中的設定優先順序更高一些，例如：
<meta. http-equiv=”Expires” CONTENT=” Fri, 30 Oct 1998 14:19:41″>
<meta. http-equiv=”Cache-Control” CONTENT=”no-cache”>

總結

Expires/Cache-Control Header是控制瀏覽器是否直接從瀏覽器快取取資料還是重新發請求到伺服器取資料。只是Cache-Control比Expires可以控制的多一些， 而且Cache-Control會重寫Expires的規則。

Last-Modified/If-Modified-Since和ETag/If-None-Match是瀏覽器傳送請求到伺服器後判斷檔案是否 已經修改過，如果沒有修改過就只發送一個304回給瀏覽器，告訴瀏覽器直接從自己本地的快取取資料；如果修改過那就整個資料重新發給瀏覽器。