http協議快取控制
第一次請求時200 ok
第二次請求304 not modified 為修改狀態
解釋： 在網路上有一些快取伺服器，另外瀏覽器自身也有快取功能。
基於乙個前提-不會經常改動，伺服器在返回200的時候，還返回該的」簽名「 -- etag (簽名可以理解為的「指紋」)
當瀏覽器再次訪問該時，去伺服器校驗「指紋」
如果沒有變化，直接使用快取中的，這樣減輕了伺服器負擔
抓包觀察：
第一次請求：
etag:"321397979879-fndlsh32yfsh894392"
last-modified: tue, 10 jun 2018 12:12:12 gmt
第二次請求頭：
第二次請求頭裡面：
if-modified-since: tue, 10 jun 2018 12:12:12 gmt
如果自tue, 10 jun 2018 12:12:12 gmt這個時間後沒有修改則不會重新請求，如果有修改則會重新請求
if-none-match: "321397979879-fndlsh32yfsh894392"
如果該最新的etag值 和 if-none-match 的值不匹配，則重新請求
第二次響應頭：
status code 304 not modified
如果是304就以為這瀏覽器從本地的快取中取資料，節省了在網路上傳輸的時間
大**的快取：
如果**比較大，有n臺快取伺服器，那麼這n臺快取伺服器如何處理主伺服器上的檔案？
要不要快取？
如果快取該快取多久呢？
快取伺服器與主伺服器之間應該有一些協議，來說明這2個問題
用什麼協議來說明這兩個問題？
答：還是http協議，用頭資訊，cache-control 來控制
利用協議控制快取（apache伺服器）：
利用協議控制快取：相關模組是---mod_expires
expiresactive on
expiresbytype image/jpeg 'access plus 1 month'
控制是否快取以及快取週期
在.htaccess中，具體語法如下：
expiresdefault "[plus] {}*"
expiresbytype type/encoding "[plus] {}*"
expiresdefault 是設定預設的快取引數
expiresbytype 是按照檔案型別來設計獨特的快取引數
我們用第二種來做測試給jpg設定乙個月的生存週期
後面4個引數怎麼理解？
base: 基於哪個時間點來計算快取有效期
access/now: 基於請求響應的那一瞬間，比如從此瞬間到乙個月之後
modification: 基於被請求檔案的最後修改日期來計算，比如最後修改日期的後一周內仍然有效
num: 快取時間的大小 （30）
type: 快取時間的單位 （天）
例項：如果這是在集群環境裡，快取伺服器得到此，將會認為乙個月內有效，從而減輕了主伺服器的負擔
利用協議取消快取（apache伺服器）：
如果有些資訊不要快取，必須要去主伺服器獲取，那麼要這樣
客戶端：
cache-control：no-cache
pragma:no-cache
伺服器端清除快取：相關模組是：mod_header
cache-control:no-cache
header unset etag
header unset last-modified
revalidate：使重新生效,使從新有法律效力
多次重新整理瀏覽器請求效果gif會始終都請求， jpeg 的會有快取
HTTP 協議快取機制
瀏覽器 http 協議快取機制詳解 收藏 xrzs 破譯 粽 子 拿最高懸賞！最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後...
HTTP協議的快取
http的快取主要是通過請求和相應報文頭部的幾個欄位來控制快取的。也就是cache control後面的字段 快取未更改的資源 etag頭的乙個典型用例是快取未更改的資源。如果使用者再次訪問給定的url 設有etag欄位 顯示資源過期了且不可用，客戶端就傳送值為etag的if none matchh...
http協議的快取
1.cache control response.setheader cache control public,max age 360 首先判斷快取的相對時間，如果還未超過時間，則不發起請求，直接從cache中讀取。反之，則重新請求。2.expires response.setheader expi...