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

瀏覽器儲存

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

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