HTTP快取字段總結

首部

請求首部：請求首部是只在請求報文中有意義的首部。

響應首部

實體首部：用來描述http報文的負荷，由於請求和響應報文中都可能包含實

體部分，所以在這兩種型別的報文中都可能出現這些首部。實體首部提供了有關實體及其內容的大量資訊，從有關物件型別的資訊，到能夠對資源使用的各種有效的請求方法。總之，實體首部可以告知報文的接收者它在對什麼進行處理。

與快取相關的http首部字段

1：通用首部欄位裡：

2：請求首部欄位裡：

3：實體首部：

此處才開始正文~

pragma和expires來規範。雖然這兩個欄位早可拋棄，但為了做http協議的向下相容，你還是可以看到很多**依舊會帶上這兩個字段。

所以這裡不再介紹過時的東東啦，大家簡單了解這是關於快取的就可以啦。

這是個通用首部字段，其有很多值可以設定：

剩下的都是快取校驗字段。

這些欄位都是根據修改時間來判斷檔案是否有變動：

只根據修改時間來判斷會有問題：如果在伺服器上，乙個資源被修改了，但其實際內容根本沒發生改變，會因為last-modified時間匹配不上而返回了整個實體給客戶端（即使客戶端快取裡有個一模一樣的資源）

為了解決這個問題，推出了etag實體首部字段。伺服器會通過某種演算法，給資源計算得出乙個唯一標誌符（比如md5標誌），在把資源響應給客戶端的時候，會在實體首部加上「etag: 唯一識別符號」一起返回給客戶端。比如：etag: "5d8c72a5edda8d6a:3239"

如果伺服器發現etag匹配不上，那麼直接以常規get 200回包形式將新的資源（當然也包括了新的etag）發給客戶端；如果etag是一致的，則直接返回304知會客戶端直接使用本地快取即可。

那麼客戶端是如何把標記在資源上的 etag 傳回給伺服器的呢？請求報文中有兩個首部字段可以帶上 etag 值：

需要注意的是，如果資源是走分布式伺服器（比如cdn）儲存的情況，需要這些伺服器上計算etag唯一值的演算法保持一致，才不會導致明明同乙個檔案，在伺服器a和伺服器b上生成的etag卻不一樣。