理解HTTP緩存和304狀態碼

理解

最近研究nginx日誌的時候,對於304這個狀態碼產生了好奇。之前一直知道3XX系列的狀態碼錶示重定向,但對於304的具體原理沒有仔細研究過。

304 的標準解釋是:客戶端有緩衝的文檔併發出了一個條件性的請求。服務器告訴客戶端,原來緩衝的文檔還可以繼續使用。

完成這個幾個動作包括服務器確認返回304給予客戶端,主要包含幾個http頭信息,請求頭If-None-Match、響應頭ETag和響應頭Cache-Control。

測試

爲了更好的理解304狀態碼以及緩存,直接實驗一把:
爲了方便就使用express啓動一個服務了(express幾行代碼就搞定了)

var express = require('express');
var app = express();

app.get('/', function(req, res) {
  res.send('hello world');
});
app.listen('8080')

啓動之後,瀏覽器訪問localhost:8080並觀察請求,響應頭。

第一次請求:
在這裏插入圖片描述
第二次請求:
在這裏插入圖片描述
第二次請求服務器返回了一個304。

在第一次請求服務器的時候在獲取資源之後是會先把該資源緩存在本地的,同時服務器response返回了一個響應頭ETag,ETag全稱Entity Tag,用來標識一個資源。在具體的實現中,ETag可以是資源的hash值,也可以是一個內部維護的版本號。但不管怎樣,ETag應該能反映出資源內容的變化,這是Http緩存可以正常工作的基礎。服務器對於hello world這個字符串使用上述返回的ETag來表示,只要hello world這個資源不變,這個Etag就不會變。

客戶端第二次請求服務器的時候,利用請求頭If-None-Match來告訴服務器自己已經有個ETag爲xxx的資源。如果服務器上的資源沒有變化,也就是說服務器上的資源的ETag也是xxx的話,服務器就不會再返回該資源的內容,而是返回一個304的響應,告訴瀏覽器該資源沒有變化,緩存有效,瀏覽器將直接調用本地緩存。

響應頭Cache-Control

每個資源都可以通過Http頭Cache-Control來定義自己的緩存策略,Cache-Control控制誰在什麼條件下可以緩存響應以及可以緩存多久。 最快的請求是不必與服務器進行通信的請求:通過響應的本地副本,我們可以避免所有的網絡延遲以及數據傳輸的數據成本。爲此,HTTP 規範允許服務器返回一系列不同的 Cache-Control 指令,控制瀏覽器或者其他中繼緩存如何緩存某個響應以及緩存多長時間。

Cache-Control 頭在 HTTP/1.1 規範中定義,取代了之前用來定義響應緩存策略的頭(例如 Expires)。當前的所有瀏覽器都支持 Cache-Control,因此,使用它就夠了。

以下我來介紹可以再Cache-Control中設置的常用指令。

max-age

該指令指定從當前請求開始,允許獲取的響應被重用的最長時間(單位爲秒。例如:Cache-Control:max-age=60表示響應可以再緩存和重用 60 秒。需要注意的是,在max-age指定的時間之內,瀏覽器不會向服務器發送任何請求,包括驗證緩存是否有效的請求,也就是說,如果在這段時間之內,服務器上的資源發生了變化,那麼瀏覽器將不能得到通知,而使用老版本的資源。所以在設置緩存時間的長度時,需要慎重。

public和private

如果設置了public,表示該響應可以再瀏覽器或者任何中繼的Web代理中緩存,public是默認值,即Cache-Control:max-age=60等同於Cache-Control:public, max-age=60。

在服務器設置了private比如Cache-Control:private, max-age=60的情況下,表示只有用戶的瀏覽器可以緩存private響應,不允許任何中繼Web代理對其進行緩存 - 例如,用戶瀏覽器可以緩存包含用戶私人信息的 HTML 網頁,但是 CDN 不能緩存。

no-cache

如果服務器在響應中設置了no-cache即Cache-Control:no-cache,那麼瀏覽器在使用緩存的資源之前,必須先與服務器確認返回的響應是否被更改,如果資源未被更改,可以避免下載。這個驗證之前的響應是否被修改,就是通過上面介紹的請求頭If-None-match和響應頭ETag來實現的。

需要注意的是,no-cache這個名字有一點誤導。設置了no-cache之後,並不是說瀏覽器就不再緩存數據,只是瀏覽器在使用緩存數據時,需要先確認一下數據是否還跟服務器保持一致。如果設置了no-cache,而ETag的實現沒有反應出資源的變化,那就會導致瀏覽器的緩存數據一直得不到更新的情況。

no-store

如果服務器在響應中設置了no-store即Cache-Control:no-store,那麼瀏覽器和任何中繼的Web代理,都不會存儲這次相應的數據。當下次請求該資源時,瀏覽器只能重新請求服務器,重新從服務器讀取資源。

部分內容參考自: www.cnblogs.com/xinzhao/p/5099807.html

————————————————
版權聲明:本文爲CSDN博主「不能說的祕密go」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:https://blog.csdn.net/canot/article/details/76359917
注:部分內容和排版有所修改。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章