實踐帶你瞭解--http緩存

此次文章爲了瞭解http緩存的機制,本身搭建nginx和設置nginx配置
網上的文章其實有不少,可是大部分都是文字表達,緩存這塊又比較偏向理論,致使我一開始也是雲裏霧裏的

因此此次我經過截圖和步驟圖來講明,而且進行文字補充, 不喜歡看文字的話其實看圖片就行啦

如下每次截圖都是無痕模式的

強緩存和協商緩存

在這以前咱們想要先了解強緩存和協商緩存:
強緩存: 不會向服務器發送請求，直接從緩存中讀取資源，在chrome控制檯的Network選項中能夠看到該請求返回200的狀態碼，而且Size顯示from disk cache或from memory cache。一般cache-control和Expires的屬性進行配置

協商緩存: 強制緩存失效後，瀏覽器攜帶緩存標識向服務器發起請求，由服務器根據緩存標識決定是否使用緩存的過程; 一般Last-Modified和ETag進行驗證, 返回304 not modified 狀態碼

強緩存(cache-control)

max-age

我在nginx中關閉了協商緩存, 而且nginx的sever配置中添加Expires @15h13m; (@15h13m爲天天15點13分緩存刷新)

在nginx中設置了Expires, 而服務器返回的response headers攜帶了cache-control: max-age的字段和Expires的字段, 其實兩個緩存指向同一時間點刷新

咱們能夠看到在規定的時間內瀏覽器刷新頁面會觸發緩存,過時後則從新請求

no-cache(關閉etag和Last-Modified)

no-cache: 緩存須要向服務器驗證;

當咱們開啓了no-cache, 瀏覽器沒有緩存的狀況下, 向服務器進行協商緩存, 可是咱們關閉了協商緩存的etag和Last-Modified, 因此請求從新發送

no-store(開啓Etag和Last-Modified)

no-store: 這個字段就是告訴瀏覽器不進行緩存

協商緩存

Last-Modified和f-Modified-Since(關閉Etag)

瀏覽器在第一次訪問資源時，服務器返回資源的同時，在response header中添加 Last-Modified的header，值是這個資源在服務器上的最後修改時間，瀏覽器接收後緩存文件和header；
好比:

Last-Modified: Fri, 23 Oct 2020 07:33:48 GMT

那麼下一次請求, 瀏覽器將攜帶Last-Modified的值到If-Modified-Since, 而且放在request headers 中進行緩存驗證

服務器會根據If-Modified-Since值與服務器中這個資源的最後修改時間對比
若是沒有變化，返回304和空的響應體，直接從緩存讀取
若是If-Modified-Since小於服務器的最後修改時間，說明文件有更新，因而返回新的資源文件和200

Last-Modified存在的弊端:

• 即便沒有對文件進行修改，但仍是會形成 Last-Modified 被修改，服務端不能命中緩存致使發送相同的資源
• Last-Modified 只能以秒計時, 秒如下的時間內進行修改沒法感知, 返回錯誤的資源

協商緩存ETag和If-None-Match(關閉Last-Modified)

協商緩存ETag跟Last-Modified相似, 不過etag是算法生成的字符串

etag解決Last-Modified存在的問題, 那麼爲何服務器不直接所有使用etag而淘汰Last-Modified, 而是兩者同存呢?

強緩存和協商緩存的優先級驗證

圖中咱們能夠看出第一次刷新進行了強緩存, 強緩存過時後, 瀏覽器攜帶字段向服務器進行協商緩存

緩存流程圖

喜歡該文章的話能夠點個贊哦, 這是我創做的動力哈

相關文章

瀏覽器緩存機制