1.cache-control
response.setheader('cache-control','public,max-age=360')
//首先判斷快取的相對時間，如果還未超過時間，則不發起請求，直接從cache中讀取。反之，則重新請求。
2.expires
response.setheader('expires','mon jan 01 2018 08:00:00 gmt') //必須用格林威治時間格式
//伺服器在響應時，回傳格林威治時間，表示在次時間內的請求直接從cache中讀取
//那麼客戶端在下次請求時，根據上次回傳的時間，比對客戶端本地時間，
//如果本地時間未超過回傳時間，則不發起請求，直接從cache中讀取。反之，則重新請求。
//缺陷:由於返回的時間比對的是客戶端本地時間，如果本地時鐘修改，則會導致快取出現異常
3.last-modified
response.setheader('last-modified','fri,22 jul 2016 08:00:00 gmt')
//伺服器在響應時，同樣回傳格林威治時間，不同的是，它表示的是伺服器最新一次對頁面修改的時間
//那麼客戶端在下次請求時，會通過if-modified-since: last-modified-value帶上之前回傳回來的時間
//如果客戶端傳來的最後修改時間與伺服器上的依然一致，則直接回送304 和響應報頭即可。
//如果沒有匹配上，說明伺服器已對頁面做了修改，則重新相應新的頁面並回傳新的last-modified
//缺陷:
a、只要資源修改，無論內容是否發生實質性的變化，都會將該資源返回客戶端。例如週期性重寫，這種情況下該資源包含的資料實際上一樣的。
b、以時刻作為標識，無法識別一秒內進行多次修改的情況。
c、某些伺服器不能精確的得到檔案的最後修改時間。
4.etag
response.setheader('etag','3fd729c07839068ebb6f7f4374981d9f') //一般可用md5
//伺服器在響應時，回傳乙個唯一標誌符（比如md5），伺服器在把頁面響應給客戶端的時候，會在實體首部加上「etag: 唯一識別符號」一起返回給客戶端
//客服端會保留etag欄位，在下次請求時，通過在請求中新增if-none-match:etag-value 給伺服器，與伺服器的etag欄位進行匹配，如果匹配上，則直接回送304 和響應報頭即可。反之，則重新傳送資源資料並回傳新的etag欄位
HTTP協議的快取
http的快取主要是通過請求和相應報文頭部的幾個欄位來控制快取的。也就是cache control後面的字段 快取未更改的資源 etag頭的乙個典型用例是快取未更改的資源。如果使用者再次訪問給定的url 設有etag欄位 顯示資源過期了且不可用，客戶端就傳送值為etag的if none matchh...
http協議之快取
http協議快取控制 第一次請求時200 ok 第二次請求304 not modified 為修改狀態 解釋 在網路上有一些快取伺服器，另外瀏覽器自身也有快取功能。基於乙個前提 不會經常改動，伺服器在返回200的時候，還返回該的 簽名 etag 簽名可以理解為的 指紋 當瀏覽器再次訪問該時，去伺服器...
HTTP 協議快取機制
瀏覽器 http 協議快取機制詳解 收藏 xrzs 破譯 粽 子 拿最高懸賞！最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後...