天天看點

HTTP 緩存機制詳解

HTTP 緩存機制詳解

2017-08-22  艾小莫的夢  JavaScript

前言在請求一個靜态檔案的時候(圖檔,css,js)等,這些檔案的特點是檔案不經常變化,将這些不經常變化的檔案存儲起來,對用戶端來說是一個優化使用者浏覽體驗的方法。那麼這個就是用戶端緩存的意義了。

Http 緩存機制作為 web 性能優化的重要手段,對于從事 Web 開發的同學們來說,應該是知識體系庫中的一個基礎環節,同時對于有志成為前端架構師的同學來說是必備的知識技能。

但是對于很多前端同學來說,僅僅隻是知道浏覽器會對請求的靜态檔案進行緩存,但是為什麼被緩存,緩存是怎樣生效的,卻并不是很清楚。

在此,我會嘗試用簡單明了的文字,像大家系統的介紹HTTP緩存機制,期望對各位正确的了解前端緩存有所幫助。

緩存規則解析HTTP緩存有多種規則,根據是否需要重新向伺服器發起請求來分類,我将其分為兩大類(強制緩存,對比緩存)

在詳細介紹這兩種規則之前,先通過時序圖的方式,讓大家對這兩種規則有個簡單了解。

已存在緩存資料時,僅基于強制緩存,請求資料的流程如下:

HTTP 緩存機制詳解

已存在緩存資料時,僅基于對比緩存,請求資料的流程如下:

HTTP 緩存機制詳解

對緩存機制不太了解的同學可能會問,基于對比緩存的流程下,不管是否使用緩存,都需要向伺服器發送請求,那麼還用緩存幹什麼?

這個問題,我們暫且放下,後文在詳細介紹每種緩存規則的時候,會帶給大家答案。

我們可以看到兩類緩存規則的不同,強制緩存如果生效,不需要再和伺服器發生互動,而對比緩存不管是否生效,都需要與服務端發生互動。

兩類緩存規則可以同時存在,強制緩存優先級高于對比緩存,也就是說,當執行強制緩存的規則時,如果緩存生效,直接使用緩存,不再執行對比緩存規則。

強制緩存從上文我們得知,強制緩存,在緩存資料未失效的情況下,可以直接使用緩存資料,那麼浏覽器是如何判斷緩存資料是否失效呢?

我們知道,在沒有緩存資料的時候,浏覽器向伺服器請求資料時,伺服器會将資料和緩存規則一并傳回,緩存規則資訊包含在響應header中。

對于強制緩存來說,響應header中會有兩個字段來标明失效規則(Expires/Cache-Control)使用chrome的開發者工具,可以很明顯的看到對于強制緩存生效時,網絡請求的情況。

Expires

Expires的值為服務端傳回的到期時間,即下一次請求時,請求時間小于服務端傳回的到期時間,直接使用緩存資料。

不過Expires 是HTTP 1.0的東西,現在預設浏覽器均預設使用HTTP 1.1,是以它的作用基本忽略。

另一個問題是,到期時間是由服務端生成的,但是用戶端時間可能跟服務端時間有誤差,這就會導緻緩存命中的誤差。

是以HTTP 1.1 的版本,使用Cache-Control替代。

Cache-Control

Cache-Control 是最重要的規則。常見的取值有private、public、no-cache、max-age,no-store,預設為private。

private:             用戶端可以緩存              public:              用戶端和代理伺服器都可緩存(前端的同學,可以認為public和private是一樣的)              max-age=xxx:   緩存的内容将在 xxx 秒後失效              no-cache:          需要使用對比緩存來驗證緩存資料(後面介紹)              no-store:           所有内容都不會緩存,強制緩存,對比緩存都不會觸發           

(對于前端開發來說,緩存越多越好,so…基本上和它說886)

舉個例子:

HTTP 緩存機制詳解

圖中Cache-Control僅指定了max-age,是以預設為private,緩存時間為31536000秒(365天)也就是說,在365天内再次請求這條資料,都會直接擷取緩存資料庫中的資料,直接使用。

沒懂的話,我們換通俗一點的話來說一遍。當用戶端第一次通路資源的時候,服務端在傳回資源内容的同時也傳回了Expires: Sun, 16 Oct 2016 05:43:02 GMT。

服務端告訴浏覽器: 你Y的先把這個檔案給我緩存起來,在這個過期時間之前,這個檔案都不會變化了,你下次需要這個檔案的時候,你就不要過來找我要了,你就去緩存中拿就好了,又快又好。

浏覽器回答說:諾。

于是在第二次html頁面中又要通路這個資源的時候,并且通路的日期在Sun, 16 Oct 2016 05:43:02 GMT之前,浏覽器就不去伺服器那邊擷取檔案了,自己從緩存中自食其力了。

但是呢,浏覽器畢竟是在用戶端的,用戶端的時間可是不準确的,使用者可以随着自己的喜好修改自己機器的時間,比如我把我機器的時間調成Sun, 16 Oct 2016 05:43:03 GMT,那麼呢?我的浏覽器就不會再使用緩存了,而每次都去伺服器擷取檔案。于是,伺服器怒了:給你個絕對時間,你由于環境被修改沒法判斷過期,那麼我就給你相對時間吧。于是就傳回了Cache-Control: max-age:600,浏覽器你給我緩存個10分鐘去。于是浏覽器隻有乖乖的緩存10分鐘了。

但是問題又來了,如果有的伺服器同時設定了Expires和Cache-Control怎麼辦呢?(不是閑的沒事幹,而是由于Cache-Controll是HTTP1.1中才有的)那麼就是根據更先進的設定Cache-Control來為标準。

好了,現在有個問題,我有個檔案可能時不時會更新,服務端非常希望用戶端能時不時過來問一下這個檔案是否過期,如果沒有過期,服務端不傳回資料給你,隻告訴浏覽器你的緩存還沒有過期(304)。然後浏覽器使用自己存儲的緩存來做顯示。這個就叫做條件請求。

對比緩存對比緩存,顧名思義,需要進行比較判斷是否可以使用緩存。浏覽器第一次請求資料時,伺服器會将緩存辨別與資料一起傳回給用戶端,用戶端将二者備份至緩存資料庫中。

再次請求資料時,用戶端将備份的緩存辨別發送給伺服器,伺服器根據緩存辨別進行判斷,判斷成功後,傳回304狀态碼,通知用戶端比較成功,可以使用緩存資料。

對于對比緩存來說,緩存辨別的傳遞是我們着重需要了解的,它在請求header和響應header間進行傳遞,一共分為兩種辨別傳遞,接下來,我們分開介紹。

Last-Modified / If-Modified-Since

Last-Modified:伺服器在響應請求時,告訴浏覽器資源的最後修改時間。

HTTP 緩存機制詳解

If-Modified-Since:

再次請求伺服器時,通過此字段通知伺服器上次請求時,伺服器傳回的資源最後修改時間。

伺服器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。

若資源的最後修改時間大于If-Modified-Since,說明資源又被改動過,則響應整片資源内容,傳回狀态碼200;若資源的最後修改時間小于或等于If-Modified-Since,說明資源無新修改,則響應HTTP 304,告知浏覽器繼續使用所儲存的cache。

HTTP 緩存機制詳解

Etag / If-None-Match(優先級高于Last-Modified / If-Modified-Since)

第一次用戶端通路資源的時候,服務端傳回資源内容的同時傳回了ETag:1234,告訴用戶端:這個檔案的标簽是1234,我如果修改了我這邊的資源的話,這個标簽就會不一樣了。

第二次用戶端通路資源的時候,由于緩存中已經有了Etag為1234的資源,用戶端要去服務端查詢的是這個資源有木有過期呢?是以帶上了If-None-Match: 1234。告訴服務端:如果你那邊的資源還是1234标簽的資源,你就傳回304告訴我,不需要傳回資源内容了。如果不是的話,你再傳回資源内容給我就行了。服務端就比較下Etag來看是傳回304還是200。

HTTP 緩存機制詳解

各種重新整理了解了上面的緩存标簽之後就很好了解各種重新整理了。

重新整理有三種

  • 浏覽器中寫位址,回車
  • F5
  • Ctrl+F5

假設對一個資源:

浏覽器第一次通路,擷取資源内容和cache-control: max-age:600,Last_Modify: Wed, 10 Aug 2013 15:32:18 GMT于是浏覽器把資源檔案放到緩存中,并且決定下次使用的時候直接去緩存中取了。

浏覽器url回車

浏覽器發現緩存中有這個檔案了,好了,就不發送任何請求了,直接去緩存中擷取展現。(最快)

下面我按下了F5重新整理

F5就是告訴浏覽器,别偷懶,好歹去伺服器看看這個檔案是否有過期了。于是浏覽器就膽膽襟襟的發送一個請求帶上If-Modify-since:Wed, 10 Aug 2013 15:32:18 GMT

然後伺服器發現:诶,這個檔案我在這個時間後還沒修改過,不需要給你任何資訊了,傳回304就行了。于是浏覽器擷取到304後就去緩存中歡歡喜喜擷取資源了。

但是呢,下面我們按下了Ctrl+F5

這個可是要命了,告訴浏覽器,你先把你緩存中的這個檔案給我删了,然後再去伺服器請求個完整的資源檔案下來。于是用戶端就完成了強行更新的操作…

還有說一下,那個ETag實際上很少人使用,因為它的計算是使用算法來得出的,而算法會占用服務端計算的資源,所有服務端的資源都是寶貴的,是以就很少使用etag了。

作者:艾小莫的夢

原文:https://segmentfault.com/a/1190000010775131

繼續閱讀