摘要：理解進公園背景這個公園有一個總公園總公園里有許多小公園總公園是登錄頁面小公園是域名相同的頁面第一次進總公園第一次請求某個服務(wù)器工作人員檢查你的入園是否符合條件后端查看是否是注冊以后的用戶通過條件的話工作人員會給你一張票后端會給你一個響應(yīng)頭這

Cookie, Session, LocalStorage, SessionStorage Cookie 理解

進公園

背景: 這個公園有一個總公園, 總公園里有許多小公園(總公園是登錄頁面, 小公園是域名相同的頁面)

第一次進總公園, (第一次請求某個服務(wù)器)

工作人員檢查你的入園是否符合條件(后端查看是否是注冊以后的用戶)

通過條件的話工作人員會給你一張票(后端會給你一個響應(yīng)頭, 這個響應(yīng)頭的作用是設(shè)置一個 cookie )

票的內(nèi)容是只有工作人員才知道是否可以入園的字符串

第二次進總公園(第二次請求相同的域名)

你要帶上這個票進公園(瀏覽器會在請求頭帶上cookie)

工作人員看到這個票, 確認里面的內(nèi)容正確就給你進去(后端看到這個cookie就會讓你直接進入登錄后的頁面)

Cookie 的實現(xiàn)

服務(wù)器通過 Set-Cookie 頭給客戶端一串字符串(背)

客戶端每次訪問相同域名的網(wǎng)頁時，必須帶上這段字符串(背)

客戶端要在一段時間內(nèi)保存這個Cookie(背)

Cookie 默認在用戶關(guān)閉頁面后就失效，后臺代碼可以任意設(shè)置 Cookie 的過期時間

大小大概在 4kb 以內(nèi)

Session的理解

進公園

? 背景: 我是一個壞游客, 我知道什么樣的字符串就可以進入公園, 于是我可以偽造假的門票, 工作人員發(fā)現(xiàn)了這個問題, 所以工作人員采用更安全的方法來審查門票

第一次進總公園, (第一次請求某個服務(wù)器)

工作人員檢查你的入園是否符合條件(后端查看是否是注冊以后的用戶)

通過條件的話工作人員會給你一張票(后端會給你一個響應(yīng)頭, 這個響應(yīng)頭的作用是設(shè)置一個 cookie , cookie 的值是一個隨機數(shù))

并且工作人員把票的字符串和你的名字寫到一張表里(后端設(shè)置一個session, 保存在服務(wù)器內(nèi)存中, session的內(nèi)容是之前的隨機數(shù)對應(yīng)你的用戶信息)

票的內(nèi)容是只有工作人員才知道是否可以入園的字符串

第二次進總公園(第二次請求相同的域名)

你要帶上這個票進公園(瀏覽器會在請求頭帶上cookie)

工作人員看到這個票, 通過判斷票的字符串是否和表的字符串匹配, 如果匹配,那么說明可以進入(后端拿到請求內(nèi)容的cookie的隨機數(shù), 會和sessions的內(nèi)容進行比對, 看請求的cookie的隨機數(shù)有沒有在sessions上出現(xiàn),如果出現(xiàn)了, 就會讓你進入登錄后的頁面)

比cookie多做兩件事情(標(biāo)了粗體)

sessions其實就是服務(wù)器的一塊內(nèi)存, key:value, 分別是隨機數(shù)和用戶的信息

Session的實現(xiàn)

將 SessionID（隨機數(shù)）通過 Cookie 發(fā)給客戶端

客戶端訪問服務(wù)器時，服務(wù)器讀取 SessionID

服務(wù)器有一塊內(nèi)存（哈希表）保存了所有 session

通過 SessionID 我們可以得到對應(yīng)用戶的隱私信息，如 id、email

這塊內(nèi)存（哈希表）就是服務(wù)器上的所有 session

?

localStorage

掛在window的一個對象, 是瀏覽器的hash

掌握localStorage的三個 api

localStorage.setItem("xxx", "yyy") 如果 yyy 是對象, 那么要用 JSON 轉(zhuǎn)一下再存儲

localStorage.getItem("xxx")

localStorage.clear()

localStorage存在c盤文件

LocalStorage 跟 HTTP 無關(guān)

HTTP 不會帶上 LocalStorage 的值

只有相同域名的頁面才能互相讀取 LocalStorage（沒有同源那么嚴格）

每個域名 localStorage 最大存儲量為 5Mb 左右（每個瀏覽器不一樣）

常用場景：記錄有沒有提示過用戶（沒有用的信息，不能記錄密碼）demo

LocalStorage 永久有效，除非用戶清理緩存

SessionStorage（會話存儲）

4,5,6,7同上

9不同: 在用戶關(guān)閉頁面（會話結(jié)束）后就失效 === 關(guān)閉頁面

Session 通過 LocalStorage + 查詢參數(shù)實現(xiàn)

未完成

Cache-Control

寫在后端的相應(yīng)大文件AA的路由中, 給響應(yīng)內(nèi)容的第二部分加上這里的某些語法

那么在第二次瀏覽器想請求同樣的大文件AA時, 服務(wù)器發(fā)現(xiàn)了, 直接不產(chǎn)生 HTTP 請求,

瀏覽器直接在本地內(nèi)存拿到大文件AA

在實際工作中, 入口文件(一般是index)不設(shè)置Cache-Control, 其他的文件都設(shè)置Cache-Control, 時間越長越好

首頁不能設(shè)置Cache-Control的原因

假設(shè)設(shè)置了百度首頁的Cache-Control為一天

用戶一般進入百度首頁只能是在 URL 中輸入www.baidu.com, 那么首頁在一天的時間內(nèi)都不能獲得最新的版本, 也可以理解為沒有接口去更新頁面了, 因為所有的路口都封鎖了

但是為什么js文件, css文件又可以設(shè)置Cache-Control呢?

因為用戶一般不會自己去請求js文件, css文件

如果遇到j(luò)s文件更新版本, 那么怎么辦?

在前端請求js文件中, 給路徑加個查詢參數(shù)即可

這是原來的: