瀏覽器存盤

• 前言
• 一、Cookie
  • 1.Cookie的來源
  • 2.什么是Cookie及應用場景
  • 3.Cookie的原理及生成方式
  • 4.Cookie的缺陷
  • 5.Cookie與安全
• 二、LocalStorage
  • 1.LocalStorage的特點
  • 2.存入/讀取資料
  • 3.使用場景
• 三、sessionStorage
  • 1.sessionStorage的特點
  • 2.使用場景
  • 3.sessionStorage 、localStorage 和 cookie 之間的區別
• 四、IndexedDB
  • 1.IndexedDB的特點
  • 2.IndexedDB的常見操作
  • 3.WebStorage、cookie 和 IndexedDB之間的區別
• 總結
• 參考文章

前言

隨著移動網路的發展與演化，我們手機上現在除了有原生 App，還能跑“WebApp”——它即開即用，用完即走，一個優秀的 WebApp 甚至可以擁有和原生 App 媲美的功能和體驗，WebApp 優異的性能表現，有一部分原因要歸功于瀏覽器存盤技術的提升，cookie存盤資料的功能已經很難滿足開發所需，逐漸被WebStorage、IndexedDB所取代，本文將介紹這幾種存盤方式的差異和優缺點，

一、Cookie

1.Cookie的來源

Cookie 的本職作業并非本地存盤，而是“維持狀態”，
因為HTTP協議是無狀態的，HTTP協議自身不對請求和回應之間的通信狀態進行保存，通俗來說，服務器不知道用戶上一次做了什么，這嚴重阻礙了互動式Web應用程式的實作，在典型的網上購物場景中，用戶瀏覽了幾個頁面，買了一盒餅干和兩瓶飲料，最后結帳時，由于HTTP的無狀態性，不通過額外的手段，服務器并不知道用戶到底買了什么，于是就誕生了Cookie，它就是用來繞開HTTP的無狀態性的“額外手段”之一，服務器可以設定或讀取Cookies中包含資訊，借此維護用戶跟服務器會話中的狀態，

我們可以把Cookie 理解為一個存盤在瀏覽器里的一個小小的文本檔案，它附著在 HTTP 請求上，在瀏覽器和服務器之間“飛來飛去”，它可以攜帶用戶資訊，當服務器檢查 Cookie 的時候，便可以獲取到客戶端的狀態，

在剛才的購物場景中，當用戶選購了第一項商品，服務器在向用戶發送網頁的同時，還發送了一段Cookie，記錄著那項商品的資訊，當用戶訪問另一個頁面，瀏覽器會把Cookie發送給服務器，于是服務器知道他之前選購了什么，用戶繼續選購飲料，服務器就在原來那段Cookie里追加新的商品資訊，結帳時，服務器讀取發送來的Cookie就行了，

2.什么是Cookie及應用場景

Cookie指某些網站為了辨別用戶身份而儲存在用戶本地終端上的資料(通常經過加密)， cookie是服務端生成，客戶端進行維護和存盤，通過cookie,可以讓服務器知道請求是來源哪個客戶端，就可以進行客戶端狀態的維護，比如登陸后重繪，請求頭就會攜帶登陸時response header中的set-cookie,Web服務器接到請求時也能讀出cookie的值，根據cookie值的內容就可以判斷和恢復一些用戶的資訊狀態，

如上圖所示，Cookie 以鍵值對的形式存在，

典型的應用場景有：

• 記住密碼，下次自動登錄，

• 購物車功能，

• 記錄用戶瀏覽資料，進行商品（廣告）推薦，

3.Cookie的原理及生成方式

Cookie的原理

第一次訪問網站的時候，瀏覽器發出請求，服務器回應請求后，會在回應頭里面添加一個Set-Cookie選項，將cookie放入到回應請求中，在瀏覽器第二次發請求的時候，會通過Cookie請求頭部將Cookie資訊發送給服務器，服務端會辨別用戶身份，另外，Cookie的過期時間、域、路徑、有效期、適用站點都可以根據需要來指定，

Cookie的生成方式主要有兩種：

• 生成方式一：http response header中的set-cookie

我們可以通過回應頭里的 Set-Cookie 指定要存盤的 Cookie 值，默認情況下，domain 被設定為設定 Cookie 頁面的主機名，我們也可以手動設定 domain 的值，

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2018 07:28:00 GMT;//可以指定一個特定的過期時間（Expires）或有效期（Max-Age）

當Cookie的過期時間被設定時，設定的日期和時間只與客戶端相關，而不是服務端，

• 生成方式二：js中可以通過document.cookie可以讀寫cookie，以鍵值對的形式展示

例如我們在掘金社區控制臺輸入以下三句代碼，便可以在Chrome 的 Application 面板查看生成的cookie:

document.cookie="userName=hello"

document.cookie="gender=male"

document.cookie='age=20;domain=.baidu.com'

從上圖中我們可以得出：

Domain 標識指定了哪些域名可以接受Cookie，如果沒有設定domain，就會自動系結到執行陳述句的當前域，
如果設定為”.baidu.com”,則所有以”baidu.com”結尾的域名都可以訪問該Cookie，所以在掘金社區上讀取不到第三條代碼存盤Cookie值，

4.Cookie的缺陷

• Cookie 不夠大

Cookie的大小限制在4KB左右，對于復雜的存盤需求來說是不夠用的，當 Cookie 超過 4KB 時，它將面臨被裁切的命運，這樣看來，Cookie 只能用來存取少量的資訊，此外很多瀏覽器對一個站點的cookie個數也是有限制的，

這里需注意：各瀏覽器的cookie每一個name=value的value值大概在4k，所以4k并不是一個域名下所有的cookie共享的,而是一個name的大小，

• 過多的 Cookie 會帶來巨大的性能浪費

Cookie 是緊跟域名的，同一個域名下的所有請求，都會攜帶 Cookie，大家試想，如果我們此刻僅僅是請求一張圖片或者一個 CSS 檔案，我們也要攜帶一個 Cookie 跑來跑去（關鍵是 Cookie 里存盤的資訊并不需要），這是一件多么勞民傷財的事情，Cookie 雖然小，請求卻可以有很多，隨著請求的疊加，這樣的不必要的 Cookie 帶來的開銷將是無法想象的，

cookie是用來維護用戶資訊的，而域名(domain)下所有請求都會攜帶cookie，但對于靜態檔案的請求，攜帶cookie資訊根本沒有用，此時可以通過cdn（存盤靜態檔案的）的域名和主站的域名分開來解決，

• 由于在HTTP請求中的Cookie是明文傳遞的，所以安全性成問題，除非用HTTPS，

5.Cookie與安全

對于 cookie 來說，我們還需要注意安全性，

HttpOnly 不支持讀寫，瀏覽器不允許腳本操作document.cookie去更改cookie，
所以為避免跨域腳本 (XSS) 攻擊，通過JavaScript的 Document.cookie API無法訪問帶有 HttpOnly 標記的Cookie，它們只應該發送給服務端，如果包含服務端 Session 資訊的 Cookie 不想被客戶端 JavaScript 腳本呼叫，那么就應該為其設定 HttpOnly 標記，

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

標記為 Secure 的Cookie只應通過被HTTPS協議加密過的請求發送給服務端，但即便設定了 Secure 標記，敏感資訊也不應該通過Cookie傳輸，因為Cookie有其固有的不安全性，Secure 標記也無法提供確實的安全保障，

為了彌補 Cookie 的局限性，讓“專業的人做專業的事情”，Web Storage 出現了，

HTML5中新增了本地存盤的解決方案----Web Storage，它分成兩類：sessionStorage和localStorage，這樣有了WebStorage后，cookie能只做它應該做的事情了——作為客戶端與服務器互動的通道，保持客戶端狀態，

二、LocalStorage

1.LocalStorage的特點

• 保存的資料長期存在，下一次訪問該網站的時候，網頁可以直接讀取以前保存的資料，
• 大小為5M左右
• 僅在客戶端使用，不和服務端進行通信
• 介面封裝較好

基于上面的特點，LocalStorage可以作為瀏覽器本地快取方案，用來提升網頁首屏渲染速度(根據第一請求回傳時，將一些不變資訊直接存盤在本地)，

2.存入/讀取資料

localStorage保存的資料，以“鍵值對”的形式存在，也就是說，每一項資料都有一個鍵名和對應的值，所有的資料都是以文本格式保存，
存入資料使用setItem方法，它接受兩個引數，第一個是鍵名，第二個是保存的資料，
localStorage.setItem("key","value");
讀取資料使用getItem方法，它只有一個引數，就是鍵名，
var valueLocal = localStorage.getItem("key");

具體步驟，請看下面的例子：

<script>
if(window.localStorage){
  localStorage.setItem（'name','world'）
  localStorage.setItem（“gender','female'）
}
</script>

<body>
<div id="name"></div>
<div id="gender"></div>
<script>
var name=localStorage.getItem('name')
var gender=localStorage.getItem('gender')
document.getElementById('name').innerHTML=name
document.getElementById('gender').innerHTML=gender
</script>
</body>

3.使用場景

LocalStorage在存盤方面沒有什么特別的限制，理論上 Cookie 無法勝任的、可以用簡單的鍵值對來存取的資料存盤任務，都可以交給 LocalStorage 來做，

這里給大家舉個例子，考慮到 LocalStorage 的特點之一是持久，有時我們更傾向于用它來存盤一些內容穩定的資源，比如圖片內容豐富的電商網站會用它來存盤 Base64 格式的圖片字串：

三、sessionStorage

sessionStorage保存的資料用于瀏覽器的一次會話，當會話結束（通常是該視窗關閉），資料被清空；sessionStorage 特別的一點在于，即便是相同域名下的兩個頁面，只要它們不在同一個瀏覽器視窗中打開，那么它們的 sessionStorage 內容便無法共享；localStorage 在所有同源視窗中都是共享的；cookie也是在所有同源視窗中都是共享的，除了保存期限的長短不同，SessionStorage的屬性和方法與LocalStorage完全一樣，

1.sessionStorage的特點

• 會話級別的瀏覽器存盤
• 大小為5M左右
• 僅在客戶端使用，不和服務端進行通信
• 介面封裝較好

基于上面的特點，sessionStorage 可以有效對表單資訊進行維護，比如重繪時，表單資訊不丟失，

2.使用場景

sessionStorage 更適合用來存盤生命周期和它同步的會話級別的資訊，這些資訊只適用于當前會話，當你開啟新的會話時，它也需要相應的更新或釋放，比如微博的 sessionStorage就主要是存盤你本次會話的瀏覽足跡：

lasturl 對應的就是你上一次訪問的 URL 地址，這個地址是即時的，當你切換 URL 時，它隨之更新，當你關閉頁面時，留著它也確實沒有什么意義了，干脆釋放吧，這樣的資料用 sessionStorage 來處理再合適不過，

3.sessionStorage 、localStorage 和 cookie 之間的區別

• 共同點：都是保存在瀏覽器端，且都遵循同源策略，
• 不同點：在于生命周期與作用域的不同

作用域：localStorage只要在相同的協議、相同的主機名、相同的埠下，就能讀取/修改到同一份localStorage資料，sessionStorage比localStorage更嚴苛一點，除了協議、主機名、埠外，還要求在同一視窗（也就是瀏覽器的標簽頁）下

生命周期：localStorage 是持久化的本地存盤，存盤在其中的資料是永遠不會過期的，使其消失的唯一辦法是手動洗掉；而 sessionStorage 是臨時性的本地存盤，它是會話級別的存盤，當會話結束（頁面被關閉）時，存盤內容也隨之被釋放，

Web Storage 是一個從定義到使用都非常簡單的東西，它使用鍵值對的形式進行存盤，這種模式有點類似于物件，卻甚至連物件都不是——它只能存盤字串，要想得到物件，我們還需要先對字串進行一輪決議，

說到底，Web Storage 是對 Cookie 的拓展，它只能用于存盤少量的簡單資料，當遇到大規模的、結構復雜的資料時，Web Storage 也愛莫能助了，這時候我們就要清楚我們的終極大 boss——IndexedDB！

四、IndexedDB

IndexedDB 是一種低級API，用于客戶端存盤大量結構化資料(包括檔案和blobs)，該API使用索引來實作對該資料的高性能搜索，IndexedDB 是一個運行在瀏覽器上的非關系型資料庫，既然是資料庫了，那就不是 5M、10M 這樣小打小鬧級別了，理論上來說，IndexedDB 是沒有存盤上限的（一般來說不會小于 250M），它不僅可以存盤字串，還可以存盤二進制資料，

1.IndexedDB的特點

• 鍵值對儲存，

IndexedDB 內部采用物件倉庫（object store）存放資料，所有型別的資料都可以直接存入，包括 JavaScript 物件，物件倉庫中，資料以"鍵值對"的形式保存，每一個資料記錄都有對應的主鍵，主鍵是獨一無二的，不能有重復，否則會拋出一個錯誤，

• 異步

IndexedDB 操作時不會鎖死瀏覽器，用戶依然可以進行其他操作，這與 LocalStorage 形成對比，后者的操作是同步的，異步設計是為了防止大量資料的讀寫，拖慢網頁的表現，

• 支持事務，

IndexedDB 支持事務（transaction），這意味著一系列操作步驟之中，只要有一步失敗，整個事務就都取消，資料庫回滾到事務發生之前的狀態，不存在只改寫一部分資料的情況，

• 同源限制

IndexedDB 受到同源限制，每一個資料庫對應創建它的域名，網頁只能訪問自身域名下的資料庫，而不能訪問跨域的資料庫，

• 儲存空間大

IndexedDB 的儲存空間比 LocalStorage 大得多，一般來說不少于 250MB，甚至沒有上限，

• 支持二進制儲存，

IndexedDB 不僅可以儲存字串，還可以儲存二進制資料（ArrayBuffer 物件和 Blob 物件），

2.IndexedDB的常見操作

在IndexedDB大部分操作并不是我們常用的呼叫方法，回傳結果的模式，而是請求——回應的模式，

• 建立打開IndexedDB ----window.indexedDB.open("testDB")

這條指令并不會回傳一個DB物件的句柄，我們得到的是一個IDBOpenDBRequest物件，而我們希望得到的DB物件在其result屬性中

除了result，IDBOpenDBRequest介面定義了幾個重要屬性:

onerror: 請求失敗的回呼函式句柄

onsuccess:請求成功的回呼函式句柄

onupgradeneeded:請求資料庫版本變化句柄

<script>
function openDB(name){
var request=window.indexedDB.open(name)//建立打開IndexedDB
request.onerror=function (e){
console.log('open indexdb error')
}
request.onsuccess=function (e){
myDB.db=e.target.result//這是一個 IDBDatabase物件，這就是IndexedDB物件
console.log(myDB.db)//此處就可以獲取到db實體
}
}
var myDB={
name:'testDB',
version:'1',
db:null
}
openDB(myDB.name)
</script>

控制臺得到一個 IDBDatabase物件，這就是IndexedDB物件

• 關閉IndexedDB----indexdb.close()

function closeDB(db){
    db.close();
}

• 洗掉IndexedDB----window.indexedDB.deleteDatabase(indexdb)

function deleteDB(name) {
  indexedDB.deleteDatabase(name)
}

3.WebStorage、cookie 和 IndexedDB之間的區別

從上表可以看到，cookie 已經不建議用于存盤，如果沒有大量資料存盤需求的話，可以使用 localStorage 和 sessionStorage ，對于不怎么改變的資料盡量使用 localStorage 存盤，否則可以用 sessionStorage 存盤，

總結

正是瀏覽器存盤、快取技術的出現和發展，為我們的前端應用帶來了無限的轉機，近年來基于存盤、快取技術的第三方庫層出不絕，此外還衍生出了 PWA 這樣優秀的 Web 應用模型，總結下本文幾個核心觀點：

• Cookie 的本職作業并非本地存盤，而是“維持狀態”
• Web Storage 是 HTML5 專門為瀏覽器存盤而提供的資料存盤機制，不與服務端發生通信
• IndexedDB 用于客戶端存盤大量結構化資料

參考文章

• 把cookie聊清楚
• HTML5本地存盤——IndexedDB（一：基本使用）
• 詳說 Cookie, LocalStorage 與 SessionStorage
• 前端性能優化原理與實踐
• localstorage 必知必會
• 瀏覽器資料庫 IndexedDB 入門教程

作者：浪里行舟
鏈接：瀏覽器存盤
來源：github
著作權歸作者所有，商業轉載請聯系作者獲得授權，非商業轉載請注明出處，

標籤：JavaScript

上一篇：原生js制作表單驗證，基本的表單驗證方法

下一篇：【JavaScript PAT乙級】1001 害死人不償命的(3n+1)猜想