http緩存 及 Etag 記錄

一、HTTP報文簡介

HTTP報文就是瀏覽器和服務器間通訊時發送及響應的數據塊。
瀏覽器向服務器請求數據，發送請求(request)報文；服務器向瀏覽器返回數據，返回響應(response)報文。

報文信息主要包含以下：
1.起始行 ---------------------- 報文的第一行就是起始行，在請求報文中用來講明要作些什麼，在響應報文中說明出現了什麼狀況
2.包含屬性的首部(header) ------- 附加信息（cookie，緩存信息等）與緩存相關的規則信息，均包含在header中
3.包含數據的主體部分(body)------- HTTP請求真正想要傳輸的部分

二、緩存規則解析

爲方便你們理解，咱們認爲瀏覽器存在一個緩存數據庫,用於存儲緩存信息。
在客戶端第一次請求數據時，此時緩存數據庫中沒有對應的緩存數據，須要請求服務器，服務器返回後，將數據存儲至緩存數據庫中。

HTTP緩存有多種規則，根據是否須要從新向服務器發起請求來分類，我將其分爲兩大類(強制緩存，對比緩存)
在詳細介紹這兩種規則以前，先經過時序圖的方式，讓你們對這兩種規則有個簡單瞭解。

對緩存機制不太瞭解的同窗可能會問，基於對比緩存的流程下，不論是否使用緩存，都須要向服務器發送請求，那麼還用緩存幹什麼？
這個問題，咱們暫且放下，後文在詳細介紹每種緩存規則的時候，會帶給你們答案。

咱們能夠看到兩類緩存規則的不一樣，強制緩存若是生效，不須要再和服務器發生交互，而對比緩存不論是否生效，都須要與服務端發生交互。
兩類緩存規則能夠同時存在，強制緩存優先級高於對比緩存，也就是說，當執行強制緩存的規則時，若是緩存生效，直接使用緩存，再也不執行對比緩存規則。

三、強制緩存

從上文咱們得知，強制緩存，在緩存數據未失效的狀況下，能夠直接使用緩存數據，那麼瀏覽器是如何判斷緩存數據是否失效呢？
咱們知道，在沒有緩存數據的時候，瀏覽器向服務器請求數據時，服務器會將數據和緩存規則一併返回，緩存規則信息包含在響應header中。

對於強制緩存來講，響應header中會有兩個字段來標明失效規則（Expires/Cache-Control）
使用chrome的開發者工具，能夠很明顯的看到對於強制緩存生效時，網絡請求的狀況

Expires
　　Expires的值爲服務端返回的到期時間，即下一次請求時，請求時間小於服務端返回的到期時間，直接使用緩存數據。
不過Expires 是HTTP 1.0的東西，如今默認瀏覽器均默認使用HTTP 1.1，因此它的做用基本忽略。
另外一個問題是，到期時間是由服務端生成的，可是客戶端時間可能跟服務端時間有偏差，這就會致使緩存命中的偏差。
因此HTTP 1.1 的版本，使用Cache-Control替代。

Cache-Control
Cache-Control 是最重要的規則。常見的取值有private、public、no-cache、max-age，no-store，默認爲private。

private:            客戶端能夠緩存
public:             客戶端和代理服務器均可緩存（前端的同窗，能夠認爲public和private是同樣的）
max-age=xxx:        緩存的內容將在 xxx 秒後失效
no-cache:           須要使用對比緩存來驗證緩存數據（後面介紹）
no-store:           全部內容都不會緩存，強制緩存，對比緩存都不會觸發（對於前端開發來講，緩存越多越好，so...基本上和它說886）

四、對比緩存

對比緩存，顧名思義，須要進行比較判斷是否可使用緩存。
瀏覽器第一次請求數據時，服務器會將緩存標識與數據一塊兒返回給客戶端，客戶端將兩者備份至緩存數據庫中。
再次請求數據時，客戶端將備份的緩存標識發送給服務器，服務器根據緩存標識進行判斷，判斷成功後，返回304狀態碼，通知客戶端比較成功，可使用緩存數據。

經過兩圖的對比，咱們能夠很清楚的發現，在對比緩存生效時，狀態碼爲304，而且報文大小和請求時間大大減小。
緣由是，服務端在進行標識比較後，只返回header部分，經過狀態碼通知客戶端使用緩存，再也不須要將報文主體部分返回給客戶端。

對於對比緩存來講，緩存標識的傳遞是咱們着重須要理解的，它在請求header和響應header間進行傳遞，
一共分爲兩種標識傳遞，接下來，咱們分開介紹。

Last-Modified / If-Modified-Since

Last-Modified：
服務器在響應請求時，告訴瀏覽器資源的最後修改時間。

If-Modified-Since：
再次請求服務器時，經過此字段通知服務器上次請求時，服務器返回的資源最後修改時間。
服務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。
若資源的最後修改時間大於If-Modified-Since，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
若資源的最後修改時間小於或等於If-Modified-Since，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。

Etag / If-None-Match（優先級高於Last-Modified / If-Modified-Since）

Etag：
服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器決定）。

If-None-Match：
再次請求服務器時，經過此字段通知服務器客戶段緩存數據的惟一標識。
服務器收到請求後發現有頭If-None-Match 則與被請求資源的惟一標識進行比對，
不一樣，說明資源又被改動過，則響應整片資源內容，返回狀態碼200；
相同，說明資源無新修改，則響應HTTP 304，告知瀏覽器繼續使用所保存的cache。

四、緩存機制總結

對於強制緩存，服務器通知瀏覽器一個緩存時間，在緩存時間內，下次請求，直接用緩存，不在時間內，執行比較緩存策略。
對於比較緩存，將緩存信息中的Etag和Last-Modified經過請求發送給服務器，由服務器校驗，返回304狀態碼時，瀏覽器直接使用緩存。

五、關於 Etag 的補充

什麼是ETag
ETag：是實體標籤(Entity Tag)的縮寫。ETag通常不以明文形式相應給客戶端。在資源的各個生命週期中，它都具備不一樣的值，用於標識出資源的狀態。當資源發生變動時，若是其頭信息中一個或者多個發生變化，或者消息實體發生變化，那麼ETag也隨之發生變化。

ETag值的變動說明資源狀態已經被修改。每每能夠經過時間戳就能夠便宜的獲得ETag頭信息。在服務端中若是發回給消費者的相應從一開始起就由ETag控制，那麼能夠確保更細粒度的ETag升級徹底由服務來進行控制。服務計算ETag值，並在相應客戶端請求時將它返回給客戶端。

總的來說：Etag是資源的特定版本的標識符 表現爲一段hash，當資源更新時，ETag值也須要更新。

計算ETag值
在HTTP1.1協議中並無規範如何計算ETag。ETag值能夠是惟一標識資源的任何東西，如持久化存儲中的某個資源關聯的版本、一個或者多個文件屬性，實體頭信息和校驗值、(CheckSum)，也能夠計算實體信息的散列值。有時候，爲了計算一個ETag值可能有比較大的代價，此時能夠採用生成惟一值等方式(如常見的GUID)。
將時間戳做爲字符串做爲一種廉價的方式來獲取ETag值。對於不是常常變化的消息，它是一種足夠好的方案。計算ETag值開銷最大的通常是計算採用哈希算法獲取資源的表述值。能夠只計算資源的哈希值，也能夠將頭信息和頭信息的值也包含進去。若是包含頭信息，那麼注意不要包含計算機標識的頭信息。一樣也應該避免包含Expires、Cache-Control和Vary頭信息。注意：在經過哈希算法計算ETag值時，先要組裝資源的表述。若組裝也比較耗時，能夠採用生成GUID的方式。優化ETag值的獲取。

ETag的類型 及他們之間的區別
ETag有兩種類型：強ETag(strong ETag)與弱ETag(weak ETag)。

強ETag表示形式： "22FAA065-2664-4197-9C5E-C92EA03D0A16"

弱ETag表現形式： w/"22FAA065-2664-4197-9C5E-C92EA03D0A16"

強、弱ETag類型的出現與Apache服務器計算ETag的方式有關。Apache默認經過 FileEtag 中 FileEtag INode Mtime Size的配置自動生成ETag(固然也能夠經過用戶自定義的方式)。

INode:  文件的索引節點(inode)數
MTime:  文件的最後修改日期及時間
Size:   文件的字節數

在大型多WEB集羣時,使用ETag時有問題,因此有人建議使用WEB集羣時不要使用ETag,其實很好解決,由於多服務器時,INode不同,因此不 同的服務器生成的ETag不同,因此用戶有可能重複下載(這時ETag就會不許),明白了上面的原理和設置後,解決方法也很容易,讓ETag後面二個參 數,MTime和Size就行了.只要ETag的計算沒有INode參於計算,就會很準了.

ETag 與 Last-Modified 區別
按照HTTP標準，Last-Modified只能精確到秒級。ETag的出現能夠很好的解決這個問題。

同時設置了 Cache-Control 與 Etag服務器同時設置了Cache-Control/max-age 和 Expires時,會同時使用,也就是說在徹底匹配 If-Modified-Since 和 If-None-Match 即檢查完修改時間和 Etag 以後,服務器才能返回304.