從輸入url到頁面（三）：緩存機制

7、緩存應用

　　Web緩存是能夠自動保存廠家文檔副本的HTTP設備。能夠分爲私有專用緩存，和共有共享緩存。web瀏覽器中有內建的私有緩存，存在我的電腦的磁盤和內存中。共有緩存是代理緩存服務器，結構有層級結構，和更復雜的網狀結構。網狀結構須要結合內容路由器，來動態決策緩存通訊的管理。

（一）處理步驟

　　一、接收。可同時從多條輸入鏈接上讀取，在整條報文抵達以前開始事務處理。

　　二、解析報文，提取出URL和各類首部，放入易於操做的數據結構。

　　三、查詢，是否有本地副本可用，若沒有就請求獲取一份副本並保存。

　　四、新鮮度檢測，不夠新鮮就從新請求

　　五、建立響應，用新的首部和緩存的實體。不用調整Date首部，表示的是原始服務器最初產生這個對象的日期。

　　六、發送

　　七、日誌。更新緩存命中與未命中的統計數據。

（二）新鮮度檢測　　

　　一、  HTTP/1.0+：Expires 指定一個絕對的過時日期

　　　　HTTP/1.1: Cache-Control:max-age=10000 以秒爲單位，從文檔生成到再也不新鮮的時間。

　　二、  再驗證

　　　　對於過時的緩存，向服務器請求在驗證，若發生變化獲取新文檔替換；沒有變化，更新首部及有效期。

　　三、  再驗證條件方法

　　　　在GET請求中添加特殊的條件首部，到條件爲真時，服務器纔會返回對象。

　　　　If-Modified-Since:<cached last-modified date>:

　　　　被稱爲IMS請求，在緩存資源的生成或修改日期以後發生變化的時候，服務器纔會返回新資源200 OK。如條件爲假，返回304 Not Modified響應報文。與Last-Modified響應首部配合工做。

　　　　注：有些服務器，只是將IMS日期與最後修改日期作字符串匹配。

　　　　If-None-Match:<Etag> 實體標籤再驗證

　　　　有些狀況下僅適用最後修改日期進行再驗證是不夠的：

　　　　--週期性重寫的文檔，如後臺程序寫入，實際內容不變。

　　　　--有些所作修改並不重要

　　　　--沒法準確判斷頁面的最後修改日期

　　　　--文檔在亞秒間隙發生變化

　　　　Etag 實體標籤是 附加到文檔上的任意標籤（引用字符串），可能包含了文檔的序列號，文檔內容的校驗或其餘指紋信息。

 

　　　　當服務器響應回送了一個Etag時，HTTP/1.1 客戶端必須使用實體標籤驗證器。

　　　　若是隻回送了一個Last-Modified值時，客戶端會使用If-Modified-Since驗證。

　　　　二者都提供了，客戶端應該使用者兩種再驗證方案。

　　　　緩存或服務器若收到兩種驗證的首部是，只有都知足時，才能返回304。

（三）控制緩存　

　　對緩存控制的方式優先級：

　　--Cache-Control : no-store ，禁止緩存對響應進行復制保存。

　　--Cache-Control : no-cache ，在使用緩存的文檔前，必須與原始服務器進行新鮮度再驗證。

　　--Cache-Control : must-revalidate ， 嚴格遵照過時時間，對陳舊副本就行再驗證

　　--Cache-Control : max-age ， 從服務器將文檔傳來之時起，新鮮的時間

　　--Expires 指定的是過時的絕對時間，應用程序時鐘不一樣步時有缺陷

　　--試探性過時  緩存能夠使用任意算法計算出一個最大使用期，大於24小時應該在響應首部添加警告。

　　--新鮮度控制: 瀏覽器會有Refresh和Reload兩種操做。

　　Cache-Control : max-stale = <s> 緩存能夠隨意提供過時的文件，如指定了參數時間s，在這段時間內，文檔就不能過時，文檔過時時間不超過s，Expires + maxStale < nowDate

　　Cache-Control : min-fresh=<s> 在將來S秒內文檔要是新鮮的 Expires – minFresh < nowDate

　　Cache-Control : only-if-cached 只有當緩存有副本時

（四）瀏覽器緩存

創建一個緩存池，內核從資源池中查找資源的關鍵字是URL。Webkit中對於不少資源，使用前是要想服務器發送再驗證請求的。下圖爲查看Chrome中的緩存文件：