一文讀懂瀏覽器儲存與快取機制

撈起月亮的漁民發表於2022-09-09

瀏覽器儲存

Cookie

Cookie 是 HTTP 協議的一種無狀態協議。當請求伺服器時,HTTP 請求都需要攜帶 Cookie,用來驗證使用者身份。Cookie 由服務端生成,儲存在客戶端,用來維持狀態。

通常 Cookie 由以下值構成:

 名稱(name)
 值(value)
 域(Domain)
 值(value)
 路徑(Path)
 失效時間(Expiers/Max-Age)
 大小(Size)
 是否為 HTTP 請求(HttpOnly)
 安全性(Secure)

 提示:域、路徑、失效時間和安全性都是伺服器給瀏覽器的指示,它們不會隨著請求傳送給伺服器,傳送給伺服器的只有名稱與值對。

Cookie 有一些限制,它可以設定有過期時間,但是如果沒有設定,則會和 session 一個級別,一旦關閉瀏覽器就會消失。

Cookie 擁有以下優點:

  • 可以控制過期時間,不會永久有效,有一定的安全保障。

  • 可進行擴充套件,可跨域共享。

  • 通過加密與安全傳輸技術 (SSL),可以減少 Cookie 被破解的可能性。

  • 有較高的相容性。

缺點則如下:

  • 有一定的數量與長度限制,每個 Cookie 長度不能超過 4KB ,否則超出部分會被截掉。

  • 請求頭上的資料容易被攔截攻擊。

  • 單個 Cookie 大小不超過 4KB,很多瀏覽器都限制一個站點最多儲存 20 個 Cookie。

web Storage

H5 可以在本地儲存使用者的瀏覽資料,以前用 Cookie,但是 web Storage 更快速、安全。可以儲存大量的資料,而不影響網站效能,以鍵/值對存在。

web Storage 分為兩種:sessionStorage 和 localStorage。

sessionStorage

sessionStorage 將資料儲存在 session 中,當瀏覽器關閉就會消失。它具有以下特色:

- 大小 5Mb
- 頁面重新整理資料不會消失,頁面關閉就消失。
- 不可以跨頁面(僅在當前頁面使用)。
- 使用 window.open 開啟頁面和改變 location.href 方式可以獲取到 sessionStorage 內部的資料。

主要被應用在下面這些場景中:

  • 主要針對會話級的小資料的儲存。

  • 儲存一些在當前頁面重新整理仍然需要儲存,但是關閉後不需要留下的資訊。

  • 很適合單頁應用的使用,可以用來儲存登入態資訊等。

localStorage

localStorage 會把資料一直存在客戶端本地。其 API 提供瞭如下的方法進行操作:

  • setItem (key,value) —— 儲存資料,以鍵值對的方式儲存。

  • getItem (key) —— 讀取資料,傳入鍵值(key),獲得對應的值(value)。

  • removeItem (key) —— 刪除某個資料,刪除鍵值對。

  • clear () —— 刪除所有資料。

  • key (index) —— 獲取某個索引的key。

下面是 localStora 的特性:

- 大小 5Mb。
- 可以跨頁面。
- 永久儲存,需要手動刪除。
- 使用 window.open 開啟頁面和改變 location.href 方式可以獲取到 sessionStorage 內部的資料。

它通常都被運用在下列場景中:

  • 永續性的儲存客戶端資料,只能通過 JavaScript 刪除或者使用者清除瀏覽器快取。

  • 如果有一些稍大量的資料,例如編輯器的自動儲存等。

  • 多頁面間訪問共同資料。sessionStorage 只能用於一個標籤頁,而localStorage可以在多個標籤頁之間共享。

瀏覽器快取機制

瀏覽器的快取機制是將已訪問過的資源進行快取,這樣當客戶端下次訪問時,就能直接訪問已經快取的資源,從而減少伺服器請求次數,讓頁面能夠更快地載入。

而判斷是否訪問快取則是依靠 HTTP 的各種 Header,比如下面的這幾種:

  • Expires:響應頭,表示該資源的過期時間。

  • Cache-Control:請求頭/響應頭,是快取控制欄位。

  • Etag (HTTP1.1):響應頭,是資源標識,伺服器儲存。一旦資源被修改,Etag 就會隨之發生變化。

  • lf-None-Match (HTTP1.1):請求頭,一般伺服器會將 If-None-Match 與被請求資源的最新 ETag 進行比對。

  • Last-Modified (HTTP1.0):響應頭,表示資源最後一次修改的時間。

  • If-Modified-Since (HTTP1.0):請求頭,資源最後一次修改時間(後面詳情)。

這些 Header 共同組成了 HTTP 的請求和響應,也支撐著瀏覽器快取,但是這種快取方式是有缺陷的。

首先,如果資源更新的速度是秒以下單位,那麼這個快取是不能被使用的。因為它的時間單位最低是秒。

其次,如果檔案是通過伺服器動態生成的,那麼該方法的更新時間永遠是生成的時間。哪怕檔案可能沒有變化,它也會自動更新,所以起不到快取的作用。

強快取

通常伺服器會通知瀏覽器一個快取時間,這個資訊在 Cache-Control 和 Expires 中,瀏覽器通過這個判斷是快取否過期。如果時間未過期。則直接從快取中取。這就是所謂的“強快取”。

Expires

在 HTTP1.0 中。使用 Expires 欄位來表示快取的到期時間,即有效時間+當時伺服器的時間。但是這種方式的缺陷是,使用者只需要修改客戶端本地時間,讓客戶端和伺服器時間不一致時,瀏覽器就會判斷快取失效,然後重新請求資源。

Cache-control

Cache-Control 是一個 HTTP 協議中關於快取的響應頭,它可以由以下值組成:

  • max-age:用於設定快取的最大週期。與 Expires 相反,它的時間是相對於請求的時間。

  • s-maxage:和 max-age 相同,僅用於共享快取,如 CDN 快取。

  • public:相應可以被任何物件快取,即使是通常不可快取的內容。

  • private:快取只能被單個使用者快取,不能作為共享快取(即代理伺服器不可快取)。

  • no-cache:可以快取在客戶端,但每次都必須去伺服器檢查新鮮度,來決定從伺服器獲取最新資源(200)還是讀取快取(304),即協商快取。

  • no-store:不允許在客戶端儲存,每次都要從伺服器請求新的資源。

協商快取

如果未命中強快取,即強快取失效(可能是 Cache-Control 設定了 no-store 或 no-cache),則判斷協商快取。

Last-Modified & If-Modified-Since(HTTP1.0)

當第一次請求資源後,伺服器會返回改資源最後一次修改的時間。之後再次請求時,伺服器會對比 If-Modified-Since 和 Last-Modified 欄位。如果兩者相同,則表示資源未修改,返回 304 狀態碼。如果兩者不同,則表示資源已經修改了,所以返回資料和 200 狀態碼(沒有傳送請求)。

但是如果伺服器更新資源的時間單位為秒,而上面提到的方法是無法識別一秒內進行多次修改的情況的。同時如果資源更新的速度不到 1ms,也是無法生成新的最後修改時間的。為了避免這種情況,在 HTTP1.1 中出現了一組新的欄位:Etag 和 If-None-Match。

Etag & If-None-Match (HTTP1.1)

Etag 是 HTTP1.1 的屬性。它由伺服器生成並返回給客戶端,優先順序高於 Last-Modified。

在 HTTP1.1 中,當瀏覽器第一次發起 HTTP 請求時,伺服器回返回一個 Etag。瀏覽器第二次發起同一個請求時,客戶端會傳送一個 If-None-Match,它的值就是 Etag。伺服器會比較瀏覽器傳送過來的 Etag 和伺服器的 Etag,如果相同就將 If-None-Match 的值設定為 false,並返回304,表示使用瀏覽器快取。如果不同,伺服器就將 If-None-Match 的值設定為 true,返回 200 和新的資料。

網頁載入速度的加快絕不僅僅是網速加快就能完成的,在我們流暢訪問的背後,瀏覽器儲存和快取機制也功不可沒,希望本文能夠幫助大家增加對這個機制的瞭解。

參考資料:

深入理解瀏覽器的快取機制 https://www.jianshu.com/p/54cc04190252

一文讀懂前端快取 https://juejin.cn/post/6844903747357769742?utm_source=gold_browser_extension

瀏覽器的儲存與快取機制 https://blog.csdn.net/wantingtr/article/details/100559520

推薦閱讀

上網時遇到的 404 是什麼意思

全站 HTTPS 就一定安全了嗎?

相關文章