一、Last-Modified瀏覽器
在瀏覽器第一次請求某一個URL時,服務器端的返回狀態會是200,內容是你請求的資源,同時有一個Last-Modified的屬性標記(HttpReponse Header)此文件在服務期端最後被修改的時間,格式相似這樣:緩存
Last-Modified:Tue, 24 Feb 2009 08:01:04 GMT服務器
客戶端第二次請求此URL時,根據HTTP協議的規定,瀏覽器會向服務器傳送If-Modified-Since報頭(HttpRequest Header),詢問該時間以後文件是否有被修改過:負載均衡
If-Modified-Since:Tue, 24 Feb 2009 08:01:04 GMT分佈式
若是服務器端的資源沒有變化,則自動返回HTTP304(NotChanged.)狀態碼,內容爲空,這樣就節省了傳輸數據量。當服務器端代碼發生改變或者重啓服務器時,則從新發出資源,返回和第一次請求時相似。從而保證不向客戶端重複發出資源,也保證當服務器有變化時,客戶端可以獲得最新的資源。spa
注:若是If-Modified-Since的時間比服務器當前時間(當前的請求時間request_time)還晚,會認爲是個非法請求blog
二、Etag工做原理資源
HTTP協議規格說明定義ETag爲「被請求變量的實體標記」(參見14.19)。簡單點即服務器響應時給請求URL標記,並在HTTP響應頭中將其傳送到客戶端,相似服務器端返回的格式:ast
Etag:「5d8c72a5edda8d6a:3239″變量
客戶端的查詢更新格式是這樣的:
If-None-Match:「5d8c72a5edda8d6a:3239″
若是ETag沒改變,則返回狀態304。
即:在客戶端發出請求後,HttpReponse Header中包含Etag:「5d8c72a5edda8d6a:3239″
標識,等於告訴Client端,你拿到的這個的資源有表示ID:5d8c72a5edda8d6a:3239。當下次須要發Request索要同一個URI的時候,瀏覽器同時發出一個If-None-Match報頭(Http RequestHeader)此時包頭中信息包含上次訪問獲得的Etag:「5d8c72a5edda8d6a:3239″標識。
If-None-Match:「5d8c72a5edda8d6a:3239「
,這樣,Client端等於Cache了兩份,服務器端就會比對2者的etag。若是If-None-Match爲False,不返回200,返回304(Not Modified) Response。
三、Expires
給出的日期/時間後,被響應認爲是過期。如Expires:Thu, 02 Apr 2009 05:14:08 GMT
需和Last-Modified結合使用。用於控制請求文件的有效時間,當請求數據在有效期內時客戶端瀏覽器從緩存請求數據而不是服務器端.當緩存中數據失效或過時,才決定從服務器更新數據。
四、Last-Modified和Expires
Last-Modified標識可以節省一點帶寬,可是仍是逃不掉髮一個HTTP請求出去,並且要和Expires一塊兒用。而Expires標識卻使得瀏覽器乾脆連HTTP請求都不用發,好比當用戶F5或者點擊Refresh按鈕的時候就算對於有Expires的URI,同樣也會發一個HTTP請求出去,因此,Last-Modified仍是要用的,並且要和Expires一塊兒用。
五、Etag和Expires
若是服務器端同時設置了Etag和Expires時,Etag原理一樣,即與Last-Modified/Etag對應的HttpRequestHeader:If-Modified-Since和If-None-Match。咱們能夠看到這兩個Header的值和WebServer發出的Last-Modified,Etag值徹底同樣;在徹底匹配If-Modified-Since和If-None-Match即檢查完修改時間和Etag以後,服務器才能返回304.
六、Last-Modified和Etag
分佈式系統裏多臺機器間文件的last-modified必須保持一致,以避免負載均衡到不一樣機器致使比對失敗
分佈式系統儘可能關閉掉Etag(每臺機器生成的etag都會不同)
Last-Modified和ETags請求的http報頭一塊兒使用,服務器首先產生Last-Modified/Etag標記,服務器可在稍後使用它來判斷頁面是否已經被修改,來決定文件是否繼續緩存
過程以下:
注:
因此一旦從新下載的頁面後,expires就從新計算一次,但last-modified不會變化