HTTP緩存機制的原理

這篇文章主要介紹“HTTP緩存機制的原理”，在日常操作中，相信很多人在HTTP緩存機制的原理問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”HTTP緩存機制的原理”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

創(chuàng)新互聯建站是一家專業(yè)提供建安企業(yè)網站建設,專注與網站設計、成都網站建設、H5頁面制作、小程序制作等業(yè)務。10年已為建安眾多企業(yè)、政府機構等服務。創(chuàng)新互聯專業(yè)網站建設公司優(yōu)惠進行中。

Web緩存大致可以分為：數據庫緩存、服務器端緩存（代理服務器緩存、cdn緩存）、瀏覽器緩存。

瀏覽器緩存也包含很多內容：HTTP緩存、indexDB、cookie、localstorage等等。 這里要說的是http緩存。

使用緩存的好處

• 減少了冗余的數據傳輸

• 緩解了網絡瓶頸的問題

• 降低了對原始服務器的要求

• 降低了距離時延

術語

緩存命中率：從緩存中得到數據的請求數與所有請求數的比率。理想狀態(tài)是越高越好。

過期內容：超過設置的有效時間，被標記為“陳舊”的內容。通常過期內容不能用于回復客戶端的請求，必須重新向源服務器請求新的內容或者驗證緩存的內容是否仍然準備。

驗證：驗證緩存中的過期內容是否仍然有效，驗證通過的話刷新過期時間。

失效：失效就是把內容從緩存中移除。當內容發(fā)生改變時就必須移除失效的內容。

機制

策略

1）緩存存儲策略

緩存存儲策略決定了客戶端是否應該存儲http的response。與緩存存儲有關的http header主要為response header中的Cache-Control。該header有下面幾個對應的值：Public、Private、no-cache、max-age、no-store。除了no-store，其它幾種都會表明response應該被客戶端緩存。

指令	說明
Public	所有內容都將被緩存(客戶端和代理服務器都可緩存)
Private	內容只緩存到私有緩存中(僅客戶端可以緩存，代理服務器不可緩存)
max-age = xxx (xxx is numeric)	緩存的內容將在 xxx 秒后失效，失效前可以直接使用本地緩存，失效后必須向服務器確認資源是否已經改變。
no-store	完全不在客戶端緩存
no-cache	可以認為等同于 max-age=0 的情況，即將 response 緩存在客戶端，但是之后每次都向服務器確認資源是否已經改變

通過Cache-Control：Public設置我們可以將HTTP響應數據存儲到本地，但此時并不意味著后續(xù)瀏覽器會直接從緩存中讀取數據并使用， 因為它無法確定本地緩存的數據是否可用（可能已經失效），需通過緩存過期策略來判斷

2）緩存過期策略

緩存過期策略決定了客戶端存儲在本地的緩存數據是否已過期，如未過期則可以直接使用本地存儲的數據，否則就需要發(fā)請求到服務端嘗試重新獲取數據。 與緩存過期策略有關的http header 為Expires。

Expires表示緩存數據有效的絕對時間，告訴客戶端到了這個時間點后本地緩存就失效了，在這個時間內客戶端可以不請求服務器而直接從本地緩存中使用已存儲的結果。

需要注意的是:no-cache和max-age=xxx的優(yōu)先級高于Expires，當它們同時存在的時候，后者會被覆蓋掉。其次， 緩存數據過期只是告訴客戶端不能再直接從本地讀取緩存了，而是需要再發(fā)一次請求到服務器去確認。具體什么情況下本地存儲的數據還可以繼續(xù)使用就與緩存對比策略有關了。

3）緩存對比策略

將緩存在客戶端的數據標識發(fā)往服務端，服務端通過標識來判斷客戶端緩存數據是否仍有效，進而決定是否要重發(fā)數據?？蛻舳藱z測到數據過期或瀏覽器刷新后，會重新發(fā)起一個 http 請求到服務器，服務器此時并不急于返回數據，而是看請求頭有沒有帶標識（If-Modified-Since、If-None-Match）過來，如果判斷標識仍然有效，則返回304告訴客戶端取本地緩存數據來用即可（這里要注意的是你必須要在首次響應時輸出相應的頭信息（Last-Modified、ETags）到客戶端）。 本地緩存數據即使被認為過期，并不等于數據從此就沒用了。

緩存過期取值

存儲策略里面no-cache等同于max-age=0，假如服務端返回的響應中沒有指明max-age、no-cache或Expires時，客戶端是否會緩存 http response呢 ？通過Fiddler、Charles等抓包工具可以發(fā)現，客戶端一樣會進行緩存

其取值值為響應頭中的Date與Last-Modified之間的差值的10%作為緩存有效時間

在Fiddler的Caching面板中可以看到

HTTP/1.1 Cache-Control Header is present: private
HTTP Last-Modified Header is present: Tue, 08 Nov 2016 06:59:00 GMT
No explicit HTTP Cache Lifetime information was provided.
Heuristic expiration policies suggest defaulting to: 10% of the delta between Last-Modified and Date.
That's '05:15:02' so this response will heuristically expire 2016/11/11 0:46:01.

用一副圖來表示

緩存的控制

1）強制緩存

可以通過Expires，Cache-Control來設定，Expires指緩存過期的時間，超過了這個時間點就代表資源過期。有一個問題是由于使用具體時間，如果時間表示出錯或者沒有轉換到正確的時區(qū)都可能造成緩存生命周期出錯。 并且Expires是HTTP/1.0的標準，現在更傾向于用HTTP/1.1中定義的Cache-Control。兩個同時存在時也是Cache-Control的優(yōu)先級更高。

2）協商緩存

緩存的資源到期了，并不意味著資源內容發(fā)生了改變，如果和服務器上的資源沒有差異，實際上沒有必要再次請求。客戶端和服務器端通過某種驗證機制驗證當前請求資源是否可以使用緩存。 瀏覽器第一次請求數據之后會將數據和響應頭部的緩存標識存儲起來。再次請求時會帶上存儲的頭部字段，服務器端驗證是否可用。如果返回304 Not Modified，代表資源沒有發(fā)生改變可以使用緩存的數據，獲取新的過期時間。反之返回200就相當于重新請求了一遍資源并替換舊資源。

Last-modified/If-Modified-Since

Last-modified: 服務器端資源的最后修改時間，響應頭部會帶上這個標識。第一次請求之后，瀏覽器記錄這個時間，再次請求時，請求頭部帶上If-Modified-Since即為之前記錄下的時間。服務器端收到帶If-Modified-Since的請求后會去和資源的最后修改時間對比。若修改過就返回最新資源，狀態(tài)碼200，若沒有修改過則返回304。

Etag/If-None-Match

由服務器端上生成的一段hash字符串，第一次請求時響應頭帶上ETag: abcd，之后的請求中帶上If-None-Match: abcd，服務器檢查ETag，返回304或200。

關于 last-modified 和 Etag 區(qū)別

• 某些服務器不能精確得到資源的最后修改時間，這樣就無法通過最后修改時間判斷資源是否更新。

• Last-modified只能精確到秒。

• 一些資源的最后修改時間改變了，但是內容沒改變，使用Last-modified看不出內容沒有改變。

• Etag的精度比Last-modified高，屬于強驗證，要求資源字節(jié)級別的一致，優(yōu)先級高。如果服務器端有提供ETag的話，必須先對ETag進行Conditional Request。

注意：實際使用ETag/Last-modified要注意保持一致性，做負載均衡和反向代理的話可能會出現不一致的情況。計算ETag也是需要占用資源的，如果修改不是過于頻繁，看自己的需求用Cache-Control是否可以滿足。

實際應用

首先要明確哪些內容適合被緩存哪些不適合。

考慮緩存的內容：css樣式文件，js文件，logo、圖標，html文件，可以下載的內容一些不應該被緩存的內容：業(yè)務敏感的GET請求

可緩存的內容又分為幾種不同的情況：

不經常改變的文件：給max-age設置一個較大的值，一般設置max-age=31536000比如引入的一些第三方文件、打包出來的帶有hash后綴css、js文件。一般來說文件內容改變了，會更新版本號、hash值，相當于請求另一個文件。 標準中規(guī)定max-age的值最大不超過一年，所以設成max-age=31536000。至于過期內容，緩存區(qū)會將一段時間沒有使用的文件刪除掉。

到此，關于“HTTP緩存機制的原理”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注創(chuàng)新互聯網站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>

網頁名稱：HTTP緩存機制的原理
文章轉載：http://bm7419.com/article36/gihepg.html

成都網站建設公司_創(chuàng)新互聯，為您提供網站收錄、網站導航、外貿網站建設、App開發(fā)、做網站、定制網站

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯