1.緩存的優點
1） 緩存減少了冗餘的數據傳輸，節省了網絡費用。
2） 緩存緩解了網絡瓶頸的問題，不需要更多的網絡帶寬就能更快的加載頁面。
3） 緩存降低了對原始服務器的要求，服務器可以更快的響應。
2.緩存分類
1）私有緩存
常見就是我們的瀏覽器裏內置的緩存。
2）公有緩存
常見的就是代理緩存，不多介紹。
3.緩存的處理流程
處理流程圖，如上所示，下面分步驟具體介紹：
1）請求處理
用戶發起一個http請求，緩存獲取到URL，根據URL查找是否有匹配的副本，這個副本可能在內存中，也可能在本地磁盤。
2） 新鮮度檢測
如果緩存中存在所請求資源的副本，則進行新鮮度檢測。新鮮度檢測舉個簡單的例子，我們在商店買了一瓶汽水，汽水瓶上肯定會標有過期時間，我們會根據這個過期時間和現在的時間做對比，看看飲料過期了沒，如果沒過期，我們正常喝就行了，如果已經過期，我們肯定要找商家。。。其實這就是一個新鮮度檢測的過程，HTTP請求的新鮮度檢測流程也是這樣的，HTTP發起一個請求時，發現緩存中有相應的副本，接着就會檢查這個副本有沒有過期，如果沒有過期，直接使用。如果已經過期，則進行再驗證。具體的實現在下面會介紹。
3）服務器再驗證
緩存中的文檔過期了並不代表他和服務器上的不一樣，所以這個時候就需要問問服務器，過期的這段時間裏這個文檔到底有沒有改變。如果改變了，緩存就會獲取一份新的文檔副本，然後發送給客戶端。如果沒有改變，緩存只需要獲取新的首部，包括一個新的過期時間，並對緩存中的首部更新。
4）創建響應並返回
我們希望緩存看起來就像是來自原始服務器一樣，緩存將已緩存的服務器響應首部作爲響應首部，發送給客戶端。
4.保質期的實現
HTTP中，通過Cache-Control首部和Expires首部爲文檔指定了過期時間，通過對過期時間的判斷，緩存就可以知道文檔是不是在保質期內。Expires首部和Cache-Control:max-age首部都是來告訴緩存文檔有沒有過期，爲什麼需要兩個響應首部來做這件簡單的事情了？其實這一切都是歷史原因，Expires首部是HTTP 1.0中提出來的，因爲他使用的是絕對日期，如果服務端和客戶端時鐘不同步的話（實際上這種情況非常常見），緩存可能就會認爲文檔已經過了保質期。
HTTP 1.1爲了修正這個問題，引入了Cache-Control:max-age首部，這個首部使用相對時間來控制保質期，讓一切變得更加合理。舉個例子，我們買了一瓶汽水，如果使用Expires首部來標註保質期，就會這麼寫：飲料過期時間：2012年12月21日，如果某個2貨不知道今天多少號，他還真不知道這飲料過期沒，我小時候飲料都這麼寫。後來，有個挺有名的賣牛奶的，大概就叫蒙牛，他發明了一種標註保質期的方法，他怎麼搞了？他這麼寫：保質期：12個月，行，牛逼了，我牛奶一年前就生產出來的牛奶，今天要發給廠家，發之前，先往包裝上印上生產日期（當然是印發貨那天），然後告訴你，明年才過期，這多聰明，搞成相對的，毒死你。也許HTTP 1.1借鑑了這個偉大的發明，於是就有了Cache-Control:max-age首部。
5.服務器再驗證的實現
緩存要問問服務器，牛奶已經過期了，到底還能不能喝。我說錯了，是文檔，不是牛奶。HTTP中，使用兩個請求請首部來完成這個功能：If-Modified-Sice和If-None-Match。爲啥又要兩個首部來完成這個功能了？答案還是因爲歷史的原因。一開始使用 If-Modified-Sice:<date>首部，date是上一次緩存牛奶時，響應中Last-Modified首部的值。
客戶端拿着這個值，問服務器，這段時間內這個牛奶你有沒有修改過？服務器看了看這個牛奶的修改時間，如果沒有修改過，會返回一個304 Not Modified的響應；如果修改過，把最新的牛奶返回給客戶端。後來，人們發現這樣有問題，因爲就算修改時間變化了，文檔也不一定發生改變！於是乎，就有了 If-None-Match:<tag>首部，tag是上一次緩存文檔時，響應中Etag的值，Etag是一種唯一標識資源的方式，就像java中的hashcode，如果hashcode不一樣，那麼兩個對象肯定不一樣！
6.試探性過期
如果響應中既沒有Cache-Control:max-age首部又沒有Expires首部，緩存可以計算出一個試探性最大使用期。這東西打個比方就是緩存會根據響應的Last-Modified來決定這文檔靠不靠譜，需不需要再驗證，如果Last-Modified中的日期是很早之前，那緩存就認爲這文檔挺靠譜，近期之內應該不會變化；如果Last-Modified中的日期是最近幾天，那緩存可能就認爲這文檔可能經常改變，不靠譜。當然這麼粗略的判斷想想就知道不嚴謹，所以我們一定要設置Expires首部和Cache-Control首部。
7.寫在最後
如果你是個好學者，看完這個文章，你可能會迫不及待的打開你的chrome瀏覽器，F12，觀察oschina的HTTP信息。這個時候的你，肯定和幾個月前的我一樣茫然，因爲你發現我上面講的很多東西再這裏被現實無情推翻了。看看這個討論記錄，這是幾個月前我在OSC上問的。之所以會出現這個情況，是因爲chrome爲了保證牛奶的安全放心，所以他不太信任包裝上的保質期標識，每次都問問服務器（再驗證），牛奶有沒有變化，沒變化的話他就直接喝了！一切都是爲了安全！
