[前端面試]前端快取問題看這篇,讓面試官愛上你
阿新 • • 發佈:2020-11-25
寫在前面的話
快取是前端面試中的必問題目
快取對於web開發有重要作用,尤其是大負荷web系統開發中
想了解更多關於效能優化的知識,請移步[三分鐘小文]前端效能優化-HTML、CSS、JS部分、[三分鐘小文]前端效能優化-頁面載入速度優化、[三分鐘小文]前端效能優化-網路傳輸層優化
文章建議閱讀時間:5分鐘
本篇文章同時收錄【前端知識點】中,連結直達
閱讀本文您將收穫
- 快取的相關概念
- 快取的作用
- 快取機制
- 快取策略詳解
快取的概念知識
- 快取的分類:伺服器快取(代理伺服器快取、CDN 快取),第三方快取,瀏覽器快取等。
- 快取的相關術語:
- 快取命中率:從快取中得到資料的請求數與所有請求數的比率。理想狀態是越高越好。
- 過期內容:超過設定的有效時間,被標記為 '陳舊' 的內容。通常過期內容不能用於回覆客戶端的請求,必須重新向源伺服器請求新的內容或者驗證快取的內容是否仍然可用。
- 驗證:驗證快取中的過期內容是否仍然有效,驗證通過的話重新整理過期時間或策略。
- 失效:失效就是把內容從快取中移除。當內容發生改變時就必須移除失效的內容。
- 另: 瀏覽器快取是代價最小的,因為瀏覽器快取依賴的是客戶端,而幾乎不耗費伺服器端的資源(極端情況下相當於純靜態頁面)。
快取的作用
- 減少網路頻寬消耗
- 降低伺服器壓力
- 減少網路延遲,加快頁面開啟速度
快取機制
- 強快取優先於協商快取,強快取生效則使用強快取,若強快取失敗,則進行協商快取
- 協商快取由伺服器決定是否使用快取,若協商快取失效,那麼代表該請求的快取失效,重新獲取請求結果,再存入瀏覽器快取中;生效則返回304,繼續使用快取
涉及快取機制的HTTP-header
Expires(過期時間)(強快取機制)
- 值:是一個GMT時間格式的絕對時間,
Expires
的日期時間必須是格林威治時間(GMT),而不是本地時間。舉例:Expires: Fri, 30 Oct 1998 14:19:41
- 作用:告訴快取器相關副本在多長時間內是新鮮的。過了這個時間,快取器就會向源伺服器傳送請求,檢查文件是否被修改。
- 相容性:幾乎所有的快取伺服器都支援Expires(過期時間)屬性
- 規則:基於客戶最後檢視副本的時間(最後訪問時間)或者根據伺服器上文件最後被修改的時間
- 應用:
- 對於設定靜態圖片檔案(例如導航欄和圖片按鈕)快取特別有用;因為這些圖片修改很少,你可以給它們設定一個特別長的過期時間,這會使你的網站對使用者變得相應非常快
- 對於控制有規律改變的網頁也很有用,例如:你每天早上6點更新新聞頁,你可以設定副本的過期時間也是這個時間,這樣快取伺服器就知道什麼時候去取一個更新版本,而不必讓使用者去按瀏覽器的"重新整理"按鈕。
- 過期時間頭資訊屬性值只能是HTTP格式的日期時間,其他的都會被解析成當前時間"之前",副本會過期
- 侷限性:雖然過期時間屬性非常有用,但是它還是有些侷限,
- 首先:是牽扯到了日期,這樣Web伺服器的時間和快取伺服器的時間必須是同步的,如果有些不同步,要麼是應該快取的內容提前過期了,要麼是過期結果沒及時更新。
- 如果你設定的過期時間是一個固定的時間,如果你返回內容的時候又沒有連帶更新下次過期的時間,那麼之後所有訪問請求都會被髮送給源Web伺服器,反而增加了負載和響應時間
Cache-Control(快取控制)(強快取機制)
- 值:
max-age=[秒]
— 執行快取被認為是最新的最長時間。- 相對時間,不是絕對時間
- 單位是秒:從請求時間 開始到過期時間之間的秒數。
- 作用:讓網站的釋出者可以更全面的控制他們的內容,並定位過期時間的限制。是http 1.1中為了彌補
Expires
缺陷新加入的。 - 相關控制欄位:
s-maxage=[秒]
— 類似於max-age屬性,除了他應用於共享(如:代理伺服器)快取public
— 標記認證內容也可以被快取,一般來說: 經過HTTP認證才能訪問的內容,輸出是自動不可以快取的;no-cache
— 強制每次請求直接傳送給源伺服器,而不經過本地快取版本的校驗。這對於需要確認認證應用很有用(可以和public結合使用),或者嚴格要求使用最新資料 的應用(不惜犧牲使用快取的所有好處);no-store
— 強制快取在任何情況下都不要保留任何副本must-revalidate
— 告訴快取必須遵循所有你給予副本的新鮮度的proxy-revalidate
— 和must-revalidate
類似,除了他只對快取代理伺服器起作用
Last-Modified/If-Modified-Since (協商快取機制)
- 通常伺服器知道你所請求的資料的最後修改時間,並且 HTTP 為伺服器提供了一種將最近修改資料連同你請求的資料一同傳送的方法。
- 如果你第二次 (或第三次,或第四次) 請求相同的資料,告訴伺服器上一次獲得的最後修改日期:在請求中傳送一個
If-Modified-Since
頭資訊,它包含了上一次從伺服器連同資料所獲得的日期。 - 如果資料從那時起沒有改變,伺服器將返回一個特殊的 HTTP 狀態程式碼 304,這意味著 “從上一次請求後這個資料沒有改變”。
- 當伺服器傳送狀態編碼 304 時,不再重新發送資料。所以當資料沒有更新時,你不需要一次又一次地下載相同的資料
- 相容性 :所有現代的瀏覽器都支援 (
last-modified
) 的資料檢查。
ETag/If-None-Match (協商快取機制)
- 作用: 沒有變化時不重新下載資料
- 工作方式 :
Etag
是上一次載入資源時,伺服器返回的response header
,是對該資源的一種唯一標識,只要資源有變化,Etag
就會重新生成- 瀏覽器在下一次載入資源向伺服器傳送請求時,會將上一次返回的
Etag
值放到request header
裡的If-None-Match
裡,伺服器比較客戶端傳來的If-None-Match
跟自己伺服器上該資源的ETag
是否一致 - 如果伺服器發現
ETag
匹配不上,那麼直接以常規GET 200
回包形式將新的資源(當然也包括了新的ETag
)發給客戶端;如果ETag
是一致的,則直接返回304知會客戶端直接使用本地快取即可。
幾種快取策略的對比
兩種強快取機制對比 Expires
VS Cache-Control
- 差別不大,區別就是
Expires
是HTTP1.0
的產物,而Cache-Control
是HTTP1.1
的產物 - 優先順序上,兩者同時存在的話,
Cache-Control
優先順序高於Expires
,Expires
更像是一種備選方案,在某些不支援Cache-Control
的環境中發揮作用 - 二者共同的弊端 就是這種強快取的機制僅僅關心快取是否超出或者超過某個過期時間,並不關心伺服器端的資源是否已經更新,所以單純使用這兩種快取策略會導致客戶端拿到的資源不是最新的
兩種協商快取機制對比 Last-Modified/If-Modified-Since
VS ETag/If-None-Match
- 精度上,
ETag
要明顯優於前者,Last-Modified/If-Modified-Since
策略的時間單位為秒,這就意味著在秒級的請求上,做不到真正的及時更新,但是ETag
每次請求都會對其進行改變從而確保精度,並且在使用負載均衡的伺服器上,各個伺服器生成的Last-Modified
也有可能不相同 - 效能上,
ETag
要遜於Last-Modified/If-Modified-Since
策略,畢竟Last-Modified/If-Modified-Since
策略只是記錄時間,而ETag
需要進行一步hash運算 - 優先順序上,伺服器會優先考慮
ETag
使用者行為對快取策略的影響
並不是所有的操作都會啟用正常的快取機制,在某些使用者行為下,快取機制是可以正常跳過的
- 位址列訪問,連結跳轉是正常使用者行為,將會觸發瀏覽器快取機制
- F5重新整理,瀏覽器會設定
max-age=0
,跳過強快取判斷,會進行協商快取判斷 - ctrl+F5重新整理,跳過強快取和協商快取,直接從伺服器拉取資源
寫在最後
- 如果你覺得這篇文章對你有益,煩請點贊以及分享給更多需要的人!