如果讓我們去實現一個HTTP緩存機制，我們應該怎么去實現呢，接下來我們將帶著這個去閱讀這篇文章!
思路1,無緩存
假設瀏覽器向服務器請求資源a.html時,服務器找到對應的資源a.html,然后將資源返回給瀏覽器。當瀏覽器再次向服務器請求該資源時，服務器將再次將該資源返回給瀏覽器。
優點：簡單。。
缺點：每次請求資源都需要服務器查找，然后再返回資源，導致服務器相應慢，浪費帶寬。
思路2，有緩存無更新
我們通過思路1的思考，忽然大悟！哦，原來每次請求資源會導致這樣的問題啊，那么我們加個緩存不就好了嗎？哈哈，我真是太天才了。因此接下來，瀏覽器第一次請求資源a.html時，服務器會響應并發送完整文件，然后瀏覽器可以把這個文件存到本地（緩存），下次瀏覽器再次請求該資源時，就直接讀取本地緩存就可以，這應就能提高網頁響應速度和省下帶寬了。
優點：省帶寬，提高頁面響應速度。
缺點：果服務器上a.html的文件內容變了，瀏覽器每次都從緩存讀取無法獲取最新文件
思路3，緩存+更新機制
我們接下來思考！唔，思路二還是存在重大缺點，得去改進它。接下瀏覽器在請求a.html時服務器會發送完整的文件，并且服務器發送的文件還附帶額外的信息——過期時間，如** Expires: Mon,10 Dec 1990 02:25:22GMT**，瀏覽器可以把這個文件和額外信息存到本地。當瀏覽器再次想服務器請求a.html時，瀏覽器就會用當前的時間和Expires的時間作比較，如果還在Expires規定的時間內，則會使用本地緩存的a.html(200, from xx cache)；否則再次向服務器再次請求a.html(200)。 服務器在每次給資源的時候都會發送新的過期時間。
優點：緩存可控制
缺點：控制的功能太單一，很有可能服務器a.htm更新了，客戶端還在用舊的資源。
思路4，緩存+更新機制升級版
上面我們已經實現了簡單的緩存的更新機制。但是還是覺得不太智能，功能太單一，我們思考一下，看一下應該如何完善。HTTP1.1版本提供了Cache-Control讓我們更好地去控制緩存。
比如：瀏覽器第一次請求a.html 時，服務器會發送完整的文件并附帶額外信息。
Cache-Control: max-age=300；
瀏覽器把文件和附帶信息保存起來。當再次需要a.html 時，如果是在300秒以內發起的請求則直接使用緩存(200, from xx cache)，否則重新發起網絡請求(200)。(和Expires有點類似)，下面是Cache-Control常見的幾個值：
<li>Public表示相應可以被任何中間節點緩存，如 Browser <-- proxy1 <-- proxy2 <-- Server，中間的代理可以緩存資源，比如下次再請求同一資源proxy1直接把自己緩存的東西給 Browser 而不再向proxy2要。</li>
<li>Private表示中間節點不能緩存，對于Browser <-- proxy1 <-- proxy2 <-- Server，proxy2 會老老實實把Server 返回的數據發送給proxy1，proxy1 會老老實實把Server 返回的數據發送給Browser ，自己不緩存任何數據。當下次Browser再次請求時proxy會做好請求轉發而不是自作主張給自己緩存的數據。</li>
<li>no-catch表示不使用 Cache-Control的緩存控制方式做前置驗證，而是使用 Etag 或者Last-Modified字段來控制緩存 </li>
<li>no-store ，真正的不緩存任何東西。瀏覽器會直接向服務器請求原始文件，并且請求中不附帶 Etag 參數(服務器認為是新請求)。</li>
<li>max-age，表示當前資源的有效時間，單位為秒。</li>
優點：緩存功能更為強大。
缺點：加入瀏覽器再次請求a.html，而緩存存在的時間間隔超過max-age設置的，這時候向服務器發送請求服務器應該會重新返回a.html的完整文件。假如，請求的a.html和原來的a.html一樣，沒有任何改變，則這就浪費了帶寬了。
思路5，緩存+更新機制終極版
鑒于思路4的實現方式還是有瑕疵，因此我們在思考一下。
比如:瀏覽器第一次請求a.html的時候，服務器響應發送完整的文件并附帶額外信息，其中Etag 是 對a.html文件的編碼，如果服務端的a.html沒有修改，則這個值就不會變。
Cache-Control: max-age=300；
ETag:W/"e-cbxLFQW5zapn79tQwb/g6Q"
瀏覽器把a.html和額外信息存放在本地，當緩存在max-age設置的時間間隔內，則直接讀取緩存a.html(200, from xx cache)，假如瀏覽器在300秒之后再次需要獲取a.html時，瀏覽器發現該緩存的文件已經不新鮮了于是就向服務器發送請求 重新獲取a.html,在發送請求的時候附帶剛剛保存的a.html的ETag ( If-None-Match：W/"e-cbxLFQW5zapn79tQwb/g6Q")，服務器在接收到請求后拿瀏覽器請求的 Etag 和當前文件重新計算后端 Etag 做個比較，如果二者相等表示文件未修改則發送這個短消息（響應頭，不包含圖片內容, 304），如果二者不等則發送新文件和新的 ETag，瀏覽器獲取新文件并更新該文件的 Etag。
另外與Etag相似的是Last-Modified/If-Modified-Since。當資源過期時（max-age超時），發現資源具有Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服務器收到請求后發現有頭If-Modified-Since 則與被請求資源的最后修改時間進行比對。若最后修改時間較新，說明資源又被改動過，則響應整片資源內容（200），若最后修改時間較舊，說明資源無新修改，則響應HTTP 304 ，告知瀏覽器繼續使用所保存的cache。
總結
經過帶著問題，不斷提出新的思路，我們最終實現控制緩存的比較好的方式。其實HTTP對于前端是非常重要，尤其當我們學習了Node.js或者其他后端語言去寫web服務端的時候，我們發現離不開HTTP，因此我們應該要注重HTTP的知識，而不只是比較這個框架好，還是那個框架牛。況且框架的使用視業務場景而定。
