首部 通用首部：有些首部提供了與報文相關的最基本的信息，它們被稱為通用首部。 請求首部：請求首部是只在請求報文中有意義的首部。 響應首部 實體首部： 用來描述HTTP報文的負荷，由於請求和響應報文中都可能包含實 體部分，所以在這兩種類型的報文中都可能出現這些首部。實體首部提供了有關實體及其內容的大量 ...
首部
- 通用首部：有些首部提供了與報文相關的最基本的信息，它們被稱為通用首部。
- 請求首部：請求首部是只在請求報文中有意義的首部。
- 響應首部
- 實體首部： 用來描述HTTP報文的負荷，由於請求和響應報文中都可能包含實
體部分，所以在這兩種類型的報文中都可能出現這些首部。實體首部提供了有關實體及其內容的大量信息，從有關對象類型的信息，到能夠對 資源使用的各種有效的請求方法。總之，實體首部可以告知報文的接收者它在對什 麽進行處理。
與緩存相關的HTTP首部欄位
1：通用首部欄位里：
2：請求首部欄位里：
3：實體首部：
此處才開始正文~
Pragma和Expires來規範。雖然這兩個欄位早可拋棄，但為了做http協議的向下相容，你還是可以看到很多網站依舊會帶上這兩個欄位。
所以這裡不再介紹過時的東東啦，大家簡單瞭解這是關於緩存的就可以啦。
Cache-Control
這是個通用首部欄位， 其有很多值可以設置：
- no-store：禁止緩存對響應進行複製
- no-cache： 可以存儲在本地緩存區，但是在與原始伺服器驗證新鮮度之前不能給客戶端使用。
- max-age：表示的是從伺服器將文檔傳來之時起，可以認為此 文檔處於新鮮狀態的秒數
剩下的都是緩存校驗欄位。
這些欄位都是根據修改時間來判斷文件是否有變動：
- Last-Modified
- If-Modified-Since: Last-Modified-value
- If-Unmodified-Since: Last-Modified-value
只根據修改時間來判斷會有問題：如果在伺服器上，一個資源被修改了，但其實際內容根本沒發生改變，會因為Last-Modified時間匹配不上而返回了整個實體給客戶端（即使客戶端緩存里有個一模一樣的資源）
為瞭解決這個問題，推出了Etag實體首部欄位。伺服器會通過某種演算法，給資源計算得出一個唯一標誌符（比如md5標誌），在把資源響應給客戶端的時候，會在實體首部加上“ETag: 唯一標識符”一起返回給客戶端。比如：Etag: "5d8c72a5edda8d6a:3239"
如果伺服器發現ETag匹配不上，那麼直接以常規GET 200回包形式將新的資源（當然也包括了新的ETag）發給客戶端；如果ETag是一致的，則直接返回304知會客戶端直接使用本地緩存即可。
那麼客戶端是如何把標記在資源上的 ETag 傳回給伺服器的呢？請求報文中有兩個首部欄位可以帶上 ETag 值：
If-None-Match: ETag-valueIf-Match: ETag-value
需要註意的是，如果資源是走分散式伺服器（比如CDN）存儲的情況，需要這些伺服器上計算ETag唯一值的演算法保持一致，才不會導致明明同一個文件，在伺服器A和伺服器B上生成的ETag卻不一樣。
附上參考鏈接：點擊跳轉，以及《HTTP權威指南》
