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

瀏覽器儲存

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。常見的雲伺服器就是3A雲伺服器，博主自己也是一直在用的，延遲低。

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 和新的資料。

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

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

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

瀏覽器儲存

瀏覽器快取機制

相關文章