Cookie, Session, LocalStorage, SessionStorage, Etag, Expire

Cookie, Session, LocalStorage, SessionStorage

Cookie 理解

進公園

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

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

   工做人員檢查你的入園是否符合條件(後端查看是不是註冊之後的用戶)

   經過條件的話工做人員會給你一張票(後端會給你一個響應頭, 這個響應頭的做用是設置一個 cookie )

   票的內容是隻有工做人員才知道是否能夠入園的字符串

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

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

   工做人員看到這個票, 確認裏面的內容正確就給你進去(後端看到這個cookie就會讓你直接進入登陸後的頁面)

Cookie 的實現

1. 服務器經過 Set-Cookie 頭給客戶端一串字符串(背)
2. 客戶端每次訪問相同域名的網頁時，必須帶上這段字符串(背)
3. 客戶端要在一段時間內保存這個Cookie(背)
4. Cookie 默認在用戶關閉頁面後就失效，後臺代碼能夠任意設置 Cookie 的過時時間
5. 大小大概在 4kb 之內

Session的理解

進公園

​ 背景: 我是一個壞遊客, 我知道什麼樣的字符串就能夠進入公園, 因而我能夠僞造假的門票, 工做人員發現了這個問題, 因此工做人員採用更安全的方法來審查門票

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

   工做人員檢查你的入園是否符合條件(後端查看是不是註冊之後的用戶)

   經過條件的話工做人員會給你一張票(後端會給你一個響應頭, 這個響應頭的做用是設置一個 cookie , cookie 的值是一個隨機數)

   而且工做人員把票的字符串和你的名字寫到一張表裏(後端設置一個session, 保存在服務器內存中, session的內容是以前的隨機數對應你的用戶信息)

   票的內容是隻有工做人員才知道是否能夠入園的字符串

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

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

   工做人員看到這個票, 經過判斷票的字符串是否和表的字符串匹配, 若是匹配,那麼說明能夠進入(後端拿到請求內容的cookie的隨機數, 會和sessions的內容進行比對, 看請求的cookie的隨機數有沒有在sessions上出現,若是出現了, 就會讓你進入登陸後的頁面)

3. 比cookie多作兩件事情(標了粗體)
4. sessions其實就是服務器的一塊內存, key:value, 分別是隨機數和用戶的信息

Session的實現

1. 將 SessionID（隨機數）經過 Cookie 發給客戶端
2. 客戶端訪問服務器時，服務器讀取 SessionID
3. 服務器有一塊內存（哈希表）保存了全部 session
4. 經過 SessionID 咱們能夠獲得對應用戶的隱私信息，如 id、email
5. 這塊內存（哈希表）就是服務器上的全部 session

   ​

localStorage

1. 掛在window的一個對象, 是瀏覽器的hash
2. 掌握localStorage的三個 api

   localStorage.setItem("xxx", "yyy") 若是 yyy 是對象, 那麼要用 JSON 轉一下再存儲

   localStorage.getItem("xxx")

   localStorage.clear()

3. localStorage存在c盤文件
4. LocalStorage 跟 HTTP 無關
5. HTTP 不會帶上 LocalStorage 的值
6. 只有相同域名的頁面才能互相讀取 LocalStorage（沒有同源那麼嚴格）
7. 每一個域名 localStorage 最大存儲量爲 5Mb 左右（每一個瀏覽器不同）
8. 經常使用場景：記錄有沒有提示過用戶（沒有用的信息，不能記錄密碼）demo
9. LocalStorage 永久有效，除非用戶清理緩存

SessionStorage（會話存儲）

4,5,6,7同上

9不一樣: 在用戶關閉頁面（會話結束）後就失效 === 關閉頁面

Session 經過 LocalStorage + 查詢參數實現

未完成

Cache-Control

1. 寫在後端的相應大文件AA的路由中, 給響應內容的第二部分加上這裏的某些語法

   那麼在第二次瀏覽器想請求一樣的大文件AA時, 服務器發現了, 直接不產生 HTTP 請求,

   瀏覽器直接在本地內存拿到大文件AA

   在實際工做中, 入口文件(通常是index)不設置Cache-Control, 其餘的文件都設置Cache-Control, 時間越長越好

2. 首頁不能設置Cache-Control的緣由

   • 假設設置了百度首頁的Cache-Control爲一天
   • 用戶通常進入百度首頁只能是在 URL 中輸入www.baidu.com, 那麼首頁在一天的時間內都不能得到最新的版本, 也能夠理解爲沒有接口去更新頁面了, 由於全部的路口都封鎖了
   • 可是爲何js文件, css文件又能夠設置Cache-Control呢?
   • 由於用戶通常不會本身去請求js文件, css文件
   • 若是遇到js文件更新版本, 那麼怎麼辦?
   • 在前端請求js文件中, 給路徑加個查詢參數便可

     這是原來的: <script src="./js/main.js">

     這是如今的: <script src="./js/main.js?v=1">

Expire

1. 和Cache-Control寫的位置同樣, 語法,不一樣的是控制緩存的時間要寫成何時過時的時間, 如Wed, 21 Oct 2015 07:28:00 GMT, 而用戶有可能把本地的時間弄錯, 因此如今都使用 Cache-Control

Etag

1. 與 MD5 有關係

   MD5是一種摘要算法, 用於確認信息傳輸是否一致

   如你下載一部電影, 網上的電影的文件對應一個MD5值,

   你下載電影后, 本地的電影也對應一個MD5值

   兩個MD5值若是徹底相同,就說明確實是一個文件了

   特色: 若是兩個文件內容越類似, 那麼兩個MD5的值差別越大

2. 在後端中, 將相應的文件內容給一個 MD5的值, 而且把這個MD5的值設置爲響應內容的第二部分中Etag(key)的value

   那麼前端在從新請求這個文件的時候,請求內容就會帶上if-None-Match: MDXXXXXXX這個請求頭

   後端發現請求內容的if-None-Match: MDXXXXXXX和服務器中相應文件的MD5相同, 那麼後端知道這個文件不須要下載

   給前端的響應內容沒有第四部分,只有第一和第二部分, 而且返回的狀態碼是304

Cache-Control直接不請求, Etag直接不下載(要請求)

一些區別

更多文章在個人github上

https://github.com/wojiaofeng...