HTTP CACHE 中的ETAG,LAST_MODIFY,MAX-AGE實驗

RayKr 發布于2019-08-06 13:20 / 985人閱讀

摘要：稍后的里有比較詳細的說明我們常用的就是和一起來用，上代碼這樣做的好處是雙重驗證，同時滿足兩者條件才會緩存失效，彌補了的粒度最多為秒的問題以及的打開關閉即更改時間的問題。防止的就是代理服務器等自作聰明，認為沒有過期。

用世界上最好的語言演示一下etag

第一次請求，服務器返回200.我分別列下請求頭【RequsetHeaders】和響應頭【ResponseHeaders】

請求頭

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
Cache-Control:no-cache
Connection:keep-alive
Host:kache.com
Pragma:no-cache
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.

響應頭

Request URL:http://kache.com/etag.php
Request Method:GET
Status Code:200 OK
Remote Address:127.0.0.1:80

Connection:Keep-Alive
Content-Type:text/html
Date:Tue, 07 Mar 2017 13:02:13 GMT
Etag:966aa4bd5183fd9358fd222647c5c6a3
Keep-Alive:timeout=5, max=99
Server:Apache/2.4.10 (Win32) OpenSSL/0.9.8zb mod_fcgid/2.3.9
Transfer-Encoding:chunked
X-Powered-By:PHP/5.4.33

需要注意第一次請求頭沒有If-None-Match:，注意第一次響應頭有Etag:這個標簽,注意第一次是200

第二次請求

請求頭：

Accept:text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding:gzip, deflate, sdch
Accept-Language:zh-CN,zh;q=0.8,en;q=0.6
Cache-Control:max-age=0
Connection:keep-alive
Host:kache.com
If-None-Match:966aa4bd5183fd9358fd222647c5c6a3
Upgrade-Insecure-Requests:1
User-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2924.87 Safari/537.36

響應頭:

Request URL:http://kache.com/etag.php
Request Method:GET
Status Code:304 Not Modified
Remote Address:127.0.0.1:80

Connection:Keep-Alive
Date:Tue, 07 Mar 2017 13:02:16 GMT
Keep-Alive:timeout=5, max=98
Server:Apache/2.4.10 (Win32) OpenSSL/0.9.8zb mod_fcgid/2.3.9

需要注意第二次請求頭有If-None-Match:，注意第二次響應為304

再用php語言演示一下Last-Modified

If-Modified-Since[請求頭的] 和 Last-Modified [響應頭的]這一對關系的HADER頭我這里就不貼了。稍后的ppt里有比較詳細的說明

我們常用的就是Last-Modified和Etag一起來用，上php代碼

這樣做的好處是雙重驗證，同時滿足兩者條件才會緩存失效，彌補了modify的粒度最多為秒的問題以及modify的打開關閉即更改時間的問題。當然etag也會有坑，不同物理機可能會導致相同文件不同結果（沒實驗過）

直接上NGINX配置示例

畢竟php做服務端水平有限，大家可以參考 swoole framework OR workerman中對etag和modify的處理。

不多說，上NGINX配置段，為了演示modify ，可以在/etc/nginx/nginx.conf中把etag關閉

http {

        ##
        # Basic Settings
        ##
        etag  off;
        ...

關于其他靜態文件緩存的設置

location ~* .(?:css)$ {
  #expires 1y;
  add_header  Cache-Control max-age=5;
  add_header Cache-Control "public";
  add_header  Last-Modified "";
}

簡單對以上括號內代碼說明：

expires 1y; 是http協議1.0寫法，1.1對應的是cache-contorl:max-age="";前者為GMT絕對時間，后者為相對時間。

add_header Cache-Control max-age=5; 緩存5秒，如果沒有Last-Modified（即設置了 add_header Last-Modified "";），期間會一直直接請求服務器，服務器一直返回200，如果有設置Last-Modified，5秒后會請求一次服務器，5秒前會返回304.

簡單歸納Last-Modified和max-age（expires）關系

如果設置了max-age=0，而沒有啟用modify，那么不會緩存

如果單單啟用modify，而沒有max-age==0.也會緩存

如果啟用了modify，并且 max-age=0，那么不會緩存

如果設置了max-age=1000，但沒有啟用modify ，不會緩存

再此說明上面配置導致的結果：5秒內如果文件有變化，那么客戶端不會有任何感知。5秒后將會重新發起請求，得到200響應。然后再緩存5秒【注意沒有開啟etag】

下面這個例子和上面一樣，是針對圖片等，緩存1一個月，即使服務端刪除了，1個月內也會正常顯示（除非ctrl+f5，或者服務端重啟了）public代表任何代理服務器都可以緩存，對應的為private，只允許客戶端瀏覽器緩存。

location ~* .(?:jpg|jpeg|gif|png|ico|cur|gz|svg|svgz|mp4|ogg|ogv|webm|htc)$ {
  expires 1M;
  add_header Cache-Control "public";
  add_header  Last-Modified "";
}

那需要有更改就更新，怎么辦？

location ~* .(?:css)$ {
  expires 1y;
 # add_header  Cache-Control max-age=5;
 # add_header Cache-Control "public";
 # add_header  Last-Modified "";
}

以上配置雖然過期時間是一年，但是服務端會返回Last-Modified，來確認，意思為你就vim了一下xx.css,即使沒有做任何更改，瀏覽器也會重新發起請求。你要是沒改，那八成就一年后見了。

那我就不想緩存怎么辦？

用cache-control：控制
用no-cahce【瀏覽器端等可以緩存，但是沒有什么卵用】
用no-store【瀏覽器端等不用緩存，不用費勁。每次都跟我服務端請求】
用must-revalidate，瀏覽器端別整沒用的，到期了就馬上跟我請求。麻溜的必須。防止的就是代理服務器等自作聰明，認為沒有過期。

location ~* .(?:js)$ {
  add_header  Cache-Control no-cache;
  add_header  Cache-Control must-revalidate;
}

測試代碼和PPT在這里

云服務器 GPU云服務器 LAST_MODIFY ETag etag?if-none-match 阿里云服務器etag怎么設置

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/61838.html

HTTP緩存機制詳解

摘要：在此，我會嘗試用簡單明了的文字，像大家系統的介紹緩存機制，期望對各位正確的理解前端緩存有所幫助。兩類緩存規則可以同時存在，強制緩存優先級高于對比緩存，也就是說，當執行強制緩存的規則時，如果緩存生效，直接使用緩存，不再執行對比緩存規則。前言在請求一個靜態文件的時候（圖片，css，js）等，這些文件的特點是文件不經常變化，將這些不經常變化的文件存儲起來，對客戶端來說是一個優化用戶瀏覽體...

tinna 2019-08-21 12:04 評論0 收藏0
HTTP緩存機制詳解

摘要：在此，我會嘗試用簡單明了的文字，像大家系統的介紹緩存機制，期望對各位正確的理解前端緩存有所幫助。兩類緩存規則可以同時存在，強制緩存優先級高于對比緩存，也就是說，當執行強制緩存的規則時，如果緩存生效，直接使用緩存，不再執行對比緩存規則。前言在請求一個靜態文件的時候（圖片，css，js）等，這些文件的特點是文件不經常變化，將這些不經常變化的文件存儲起來，對客戶端來說是一個優化用戶瀏覽體...

yzzz 2019-08-06 13:24 評論0 收藏0
web性能優化之：no-cache與must-revalidate深入探究

摘要：本文僅挑這兩個進行值進行探究對比。注意變化了，表示源服務器資源已發生變化。從日志來看，緩存服務器訪問源服務器，并返回給瀏覽器。緩存服務器上已有該資源副本，且該副本未過期。緩存服務器本身優化算法對實驗結果的影響。引言稍微了解HTTP協議的前端同學，想必對Cache-Control不會感到陌生，性能優化時經常都會跟它打交道。常見的值有有private、public、no-store、...

alexnevsky 2019-08-06 13:19 評論0 收藏0
緩存淺析

摘要：概念緩存是一種保存資源副本并在下次請求時直接使用該副本的技術。緩存能緩解服務器壓力，提高響應速度，提升用戶體驗。以下討論的緩存是針對對資源而言的，且緩存策略都是依靠報文的首部來實現。參考緩存控制小結淺談瀏覽器的緩存機制概念緩存是一種保存資源副本并在下次請求時直接使用該副本的技術。——MDN 緩存能緩解服務器壓力，提高響應速度，提升用戶體驗。以下討論的緩存是針對對img/scrip...

Shonim 2019-08-06 13:26 評論0 收藏0
緩存淺析

摘要：概念緩存是一種保存資源副本并在下次請求時直接使用該副本的技術。緩存能緩解服務器壓力，提高響應速度，提升用戶體驗。以下討論的緩存是針對對資源而言的，且緩存策略都是依靠報文的首部來實現。參考緩存控制小結淺談瀏覽器的緩存機制概念緩存是一種保存資源副本并在下次請求時直接使用該副本的技術。——MDN 緩存能緩解服務器壓力，提高響應速度，提升用戶體驗。以下討論的緩存是針對對img/scrip...

VishKozus 2019-08-22 11:18 評論0 收藏0