摘要：那要是被刪了呢那沒辦法了，只能重新登陸，意味著重新提交重新分配隨機(jī)數(shù)。它是一個(gè)哈希，作用就是字面意思，本地存儲(chǔ)，只不過這里的本地指的是瀏覽器。

標(biāo)簽可以保留回車和空格等你怎么寫它就怎么展示的內(nèi)容

cookie
cookie可以看作是一種設(shè)置，允許瀏覽器在電腦本地硬盤的某一個(gè)隱蔽的地方開發(fā)一塊存儲(chǔ)空間，用來(lái)存放某些特定的內(nèi)容。
如果在服務(wù)器端設(shè)置了允許使用cookie，那么，之后瀏覽器每次向同域名服務(wù)器發(fā)送請(qǐng)求，都會(huì)帶上cookie，意味著每發(fā)送一次請(qǐng)求，瀏覽器都會(huì)把存在本地硬盤那某一個(gè)隱蔽地方里的文件發(fā)送給服務(wù)器，交由服務(wù)器處理。
通常，我們習(xí)慣將用戶的登陸信息存放在cookie里，所以，服務(wù)器能夠通過瀏覽器發(fā)送給它的cookie判斷用戶注冊(cè)了沒有？、用戶名密碼是否正確？、用戶名密碼是否匹配？、該用戶多少等級(jí)了？。。。由此，返回相應(yīng)的網(wǎng)頁(yè)內(nèi)容。
在這里為什么總感覺難以理解？？這是因?yàn)椋?b>cookie的概念要涉及服務(wù)器和瀏覽器，兩者感覺交織在一起。所以，有必要理清一下思路：cookie的基本操作流程。
cookie的基本操作流程

第一，瀏覽器會(huì)發(fā)送一個(gè)請(qǐng)求，將一個(gè)東西（對(duì)象、哈希、數(shù)組，隨便你怎么叫）發(fā)送給服務(wù)器

第二，服務(wù)器將發(fā)送給它的這個(gè)東西進(jìn)行處理，得到的結(jié)果以字符串的形式、通過Set-Cookie響應(yīng)頭返回給瀏覽器，該字符串稱之為cookie

第三，現(xiàn)在瀏覽器得到Set-Cookie響應(yīng)頭并獲允使用cookie，之后，用戶每次向相同域名網(wǎng)站的服務(wù)器發(fā)送的請(qǐng)求，都會(huì)帶上該cookie

第四，每一次請(qǐng)求，服務(wù)器可以讀取cookie，獲取cookie中包含的信息（用戶資料、特定頁(yè)面信息等），然后向瀏覽器返回相應(yīng)的內(nèi)容

cookie示例
前端代碼：
$.post("/sign_in", hash)
     .then((response)=>{
         window.location.href = "/index.html"
     }, (request)=>{
         alert("郵箱與密碼不匹配")
})
使用node.js寫的后端代碼示意：
if(path === "/sign_in" && method === "post"){
    //your code
    response.setHeader("Set-Cookie","sign_in_email=${email}"; HttpOnly; Max-Age=3000");
    //your code
}else if(path === "/index.html"){
    //your code
    let cookies = request.headers.cookie;
    //your code
}
在上述示例代碼中，

第一步，前端代碼（瀏覽器）使用jquery的post()方法向服務(wù)器朝/sign_in路徑發(fā)送了一個(gè)請(qǐng)求，將變量hash傳給了服務(wù)器。
第二步，后端代碼（服務(wù)器）在//your code里對(duì)變量hash處理后，將處理結(jié)果變成"sign_in_email=${email}"的字符串（其中${email}表示變量email代表的數(shù)據(jù)），然后設(shè)置了響應(yīng)頭Set-Cookie返回給瀏覽器，并加諸了像HttpOnly、Max-Age等各類設(shè)置（詳細(xì)說明請(qǐng)參見https://developer.mozilla.org...）。
第三步，瀏覽器收到了服務(wù)器返回的響應(yīng)頭Set-Cookie和cookie（字符串），說明請(qǐng)求成功了，會(huì)將網(wǎng)頁(yè)重定向?yàn)?b>/index.html（這里使用了promise：.then((response)=>{window.location.href = "/index.html"）。所以瀏覽器又向服務(wù)器發(fā)送了一次請(qǐng)求。這次請(qǐng)求會(huì)帶上cookie

第四步，服務(wù)器又收到了一次請(qǐng)求，這次請(qǐng)求的路徑是/index.html，并且?guī)в?b>cookie。那么，服務(wù)器可以使用request.headers.cookie來(lái)獲取cookie，然后在//your code里處理后，在//your code里給瀏覽器返回相應(yīng)的頁(yè)面

cookie的幾個(gè)特點(diǎn)


不同瀏覽器之間的cookie不通用
這就好像Firfox的www.segmentfault.com不是chorme的www.segmentfault.com


cookie存在硬盤的某一個(gè)神秘文件里

cookie很容易被修改，用戶可以自己進(jìn)入瀏覽器控制臺(tái)修改cookie
看到下圖，Firfox的控制臺(tái)進(jìn)入存儲(chǔ)、進(jìn)入Cookies，我們修改了兩個(gè)值，并且刷新后，一個(gè)值會(huì)變回來(lái)，一個(gè)值沒有變回來(lái)




cookie的有效期默認(rèn)由瀏覽器自己決定，當(dāng)然可以通過后端設(shè)置cookie的保存時(shí)間
當(dāng)然，不同后端語(yǔ)法不一樣寫法不一樣，通常都是設(shè)定Max-Age或者Expires屬性
詳細(xì)可以參見：
Set-Cookie：https://developer.mozilla.org...
HTTP cookies：https://developer.mozilla.org...



cookie應(yīng)用
可想而知，cookie最常用的就是注冊(cè)&登陸啦~~~

先在瀏覽器注冊(cè)，注冊(cè)好了就向瀏覽器發(fā)送請(qǐng)求，報(bào)告！請(qǐng)求注冊(cè)成功頁(yè)面??！

服務(wù)器檢查下自己的數(shù)據(jù)庫(kù)，這是個(gè)新兵，存下來(lái)存下來(lái)，然后返回包含新兵狗牌的cookie和注冊(cè)成功頁(yè)面
這個(gè)cookie有時(shí)間限制，在這個(gè)時(shí)間段里，新兵訪問服務(wù)器不用再報(bào)告了（瀏覽器發(fā)送請(qǐng)求一直帶著這個(gè)cookie）
過了這個(gè)時(shí)間段，cookie失效了（瀏覽器發(fā)送請(qǐng)求不帶上cookie了），不好意思，請(qǐng)證明你自己（登陸，并獲得新的老兵狗牌的cookie和登陸成功頁(yè)面）


session
cookie好啊，可以讓服務(wù)器知道我們是VIP用戶了，不過因?yàn)槟鼙惠p松的查看并且容易被篡改，所以引出新概念session，而session更像是一種技術(shù)，而不是一種設(shè)置
從前，服務(wù)器直接將用戶信息存在cookie里，現(xiàn)在，服務(wù)器將sessionId放在cookie里，再通過sessionId到session表里查找sessionId對(duì)應(yīng)的相關(guān)內(nèi)容。
那為什么就防止了cookie容易被篡改的問題呢？因?yàn)?b>sessionId里存放的是隨機(jī)數(shù)Math.random()，你取個(gè)很多位的隨機(jī)數(shù)，那普通人就沒辦法猜了，完全不知道哪個(gè)隨機(jī)數(shù)對(duì)應(yīng)的是用戶、哪個(gè)不是。
那要是sessionId被刪了呢？那沒辦法了，只能重新登陸，意味著重新提交、重新分配隨機(jī)數(shù)。

看上圖，上圖是在chorme里控制臺(tái)的Application → Storage → Cookies選項(xiàng)，看到服務(wù)器向瀏覽器發(fā)送了帶有sessionId的cookie，一個(gè)隨機(jī)數(shù)，之后，瀏覽器再向服務(wù)器發(fā)送請(qǐng)求就會(huì)帶上這個(gè)cookie
session其實(shí)本質(zhì)上就是cookie，只不過加了一個(gè)中間量sessionId，我們還是來(lái)看看session的基本流程
session的基本流程

第一，瀏覽器會(huì)發(fā)送一個(gè)請(qǐng)求，將一個(gè)東西（對(duì)象、哈希、數(shù)組，隨便你怎么叫）發(fā)送給服務(wù)器

第二，服務(wù)器有一個(gè)哈希叫作session，該哈希的key就是sessionId(隨機(jī)數(shù))、value是第一步里送送給服務(wù)器的東西的處理結(jié)果：一個(gè)字符串，以前的cookie

第三，服務(wù)器會(huì)設(shè)置響應(yīng)頭Set-Sookie，將sessionId(隨機(jī)數(shù))通過cookie的形式發(fā)送給瀏覽器

第四，之后，瀏覽器每請(qǐng)求一次服務(wù)器，就會(huì)帶上這個(gè)含有sessionId的cookie，服務(wù)器就會(huì)讀取sessionId，并在session哈希里查找sessionId對(duì)應(yīng)的值，然后作出相應(yīng)的操作

session示例
前端代碼：
$.post("/sign_in", hash)
     .then((response)=>{
         window.location.href = "/index.html"
     }, (request)=>{
         alert("郵箱與密碼不匹配")
})
使用node.js寫的后端代碼示意：
let sessions = {};
if(path === "/sign_in" && method === "post"){
    //your code
    let sessionId = Math.random()*100000000;
    session[sessionId] = {sign_in_email:email};
    response.setHeader("Set-Cookie","sessionId=${sessionId}"; HttpOnly; Max-Age=3000");
    //your code
}else if(path === "/index.html"){
    //your code
    let cookies = request.headers.cookie;
    let sessionId = ;
    let email = session[sessionId];
    //your code
}
上面發(fā)生了什么可以通過和cookie作對(duì)比知道：

第一，在服務(wù)器我們?cè)O(shè)置了一個(gè)哈希let session = {}

第二，在服務(wù)器我們生成一個(gè)隨機(jī)數(shù)sessionId作為session的鍵，獲取email作為該鍵的值
第三，服務(wù)器設(shè)置Set-Cookie響應(yīng)頭，將sessionId作為cookie傳回給瀏覽器

第四，瀏覽器請(qǐng)求成功，網(wǎng)頁(yè)重定向?yàn)?b>/index.html，重新發(fā)送請(qǐng)求，帶有cookie，其中帶有sessionId

第五，服務(wù)器接收到cookie，得到sessionId，搜尋session，獲得相應(yīng)email，在//your code里返回相應(yīng)內(nèi)容

localStorage
localStorage是HTML5發(fā)布的新api。它是一個(gè)哈希，作用就是字面意思，本地存儲(chǔ)，只不過這里的本地指的是瀏覽器。
請(qǐng)參考：https://developer.mozilla.org...
用法也不難，你可以通過localStorage自己的方法往這個(gè)哈希里面的數(shù)據(jù)，再通過localStorage自己的方法調(diào)用里面的數(shù)據(jù)。
localStorage的方法


設(shè)置一個(gè)localStorage值：setItem
localStorage.setItem("cat","rainy");


獲取一個(gè)localStorage值：getItem
var cat = localStorage.getItem("cat");


移除一個(gè)localStorage值：removeItem
localStorage.removeItem("cat");


清除所有localStorage值：clear
localStorage.clear();


查看localStorage哈希：localStorage
console.log(localStorage);


localStorage的特點(diǎn)

和http無(wú)關(guān)，意味著它不會(huì)存在于瀏覽器和服務(wù)器之間的通信，請(qǐng)求響應(yīng)時(shí)不會(huì)帶上localStorage的值
只有相同域名的頁(yè)面才能互相讀取localStorage

當(dāng)然，localStorage是瀏覽器自己的存儲(chǔ)空間，所以不同瀏覽器之間也是不能相互讀取的
當(dāng)頁(yè)面刷新或者關(guān)閉后，localStorage里的值也不會(huì)消失，所以叫local呀~



localStorage的物理地址存在硬盤里的某個(gè)文件里
每個(gè)域名的localStorage最大存儲(chǔ)空間都是瀏覽器自定的，一般在5MB左右，如果溢出就會(huì)有下面這樣的提示


永久有效，除非手動(dòng)清理

sessionStorage
此接口作用和localStorage一樣樣，也是開辟了一塊地方供瀏覽器存儲(chǔ)數(shù)據(jù)用。
請(qǐng)參考：https://developer.mozilla.org...
sessionStorage的方法請(qǐng)參考上一章localStorage的方法。請(qǐng)將localStorage都替換成為sessionStorage。
sessionStorage的特點(diǎn)請(qǐng)參考上一章localStorage的特點(diǎn)。唯一的區(qū)別在于sessionStorage在關(guān)閉頁(yè)面后就被清空了。請(qǐng)看下動(dòng)圖。

小結(jié)


形象理解cookie&session
就好像要去游樂園（服務(wù)器）玩，你可以選擇買票（登陸，獲得cookie）或者不買票（不登陸，隨便逛逛），不買票只能玩一些項(xiàng)目（網(wǎng)頁(yè)公共內(nèi)容），買了票能解鎖更多項(xiàng)目（網(wǎng)頁(yè)私有內(nèi)容）。那么關(guān)于這張票，如果實(shí)名認(rèn)證的，你的姓名、身份證號(hào)都在上面，這是cookie的做法，如果票上面只有一個(gè)編號(hào)，游樂園需要通過編號(hào)查找數(shù)據(jù)庫(kù)才能認(rèn)證你，那這就是session的做法




cookie和session有啥區(qū)別？
session是基于cookie實(shí)現(xiàn)的。session就是不直接將用戶信息存放在cookie里，而是將sessionId放在cookie里傳給服務(wù)器，服務(wù)器通過sessionId在session哈希里查找相應(yīng)的值


cookie和localstorage有啥區(qū)別？
cookie會(huì)隨著每一次請(qǐng)求發(fā)送給服務(wù)器，而localStorage則不會(huì)帶給服務(wù)器，它是瀏覽器的一塊存儲(chǔ)地。另外，cookie一般只有5KB左右的大小，而localStorage一般則有5MB左右的大小


sessionStorage和localStorage有啥區(qū)別？
sessionStorage在頁(yè)面關(guān)閉（會(huì)話結(jié)束）后就被全部清空，而localStorage則不會(huì)。

作為前端，最好不要直接讀/寫cookie。cookie的內(nèi)容越多，發(fā)送給服務(wù)器的時(shí)間越長(zhǎng)，影響請(qǐng)求時(shí)間，導(dǎo)致訪問變慢。如果一般的數(shù)據(jù)，不需要特別發(fā)給服務(wù)器的，請(qǐng)使用localStorage


http緩存
Cache-Control
顧名思義，控制緩存
若服務(wù)器設(shè)置了該項(xiàng)設(shè)置，意味著頁(yè)面將被放在緩存里，當(dāng)瀏覽器需要請(qǐng)求服務(wù)器的時(shí)候，將不會(huì)將請(qǐng)求發(fā)送至服務(wù)器，而是直接調(diào)用緩存里的頁(yè)面。
各類屬性詳細(xì)請(qǐng)參考：https://developer.mozilla.org...
請(qǐng)看下圖，右側(cè)瀏覽器Chorme向服務(wù)器Server請(qǐng)求/main.js，服務(wù)器Server返回瀏覽器Chorme一個(gè)Max-Age=30的Cache-Control的響應(yīng)頭。那么接下來(lái)的30s內(nèi)，瀏覽器Chorme再向服務(wù)器Server請(qǐng)求/main.js，注意?。。”仨毷峭耆嗤腢RL?。。?/em>，會(huì)直接從緩存（內(nèi)存）里調(diào)用main.js，直到過了30s從能再?gòu)?strong>服務(wù)器端獲取main.js

Cache-Control的使用
前端代碼：
$.post("/sign_in", hash)
     .then((response)=>{
         window.location.href = "/index.html"
     }, (request)=>{
         alert("郵箱與密碼不匹配")
})
使用Node.js寫的后端：
if(path === "/sign_in" && method === "post"){
    //your code
    response.setHeader("Cache-Control","max-age=30");
    //your code
}
上面的代碼顯示，在30s的時(shí)間內(nèi)，任何以post方法向服務(wù)器/sign_in路徑的請(qǐng)求，都不會(huì)被發(fā)送，而會(huì)直接調(diào)用緩存里/index.html的頁(yè)面
Cache-Control的幾個(gè)特點(diǎn)

通常首頁(yè)請(qǐng)不要設(shè)置緩存，如果設(shè)置了，就意味著做任何操作后，頁(yè)面都從緩存里調(diào)用，這樣就不會(huì)再更新新的頁(yè)面。

除去首頁(yè)，其它資源可以設(shè)置為10年，300000000，3后面8個(gè)0
什么？10年？那需要更改了怎么辦？
修改url
原來(lái)頁(yè)面里引用的js例如說像這樣：
那么現(xiàn)在只需要改正這樣：
看出區(qū)別了嗎？多了?/v=1，但是兩個(gè)路徑都調(diào)用的同一個(gè)文件


同樣，Cache-Control控制的緩存的物理地址在硬盤里的某一個(gè)位置，瀏覽器會(huì)設(shè)置一個(gè)固定大小，多了就將之前的緩存清掉

Expires
曾經(jīng)，我們使用Expires設(shè)置緩存控制響應(yīng)頭：
if(path === "/sign_in" && method === "post"){
    //your code
    response.setHeader("Expires","Sun, 04 Feb 2018 14:00:05 GM");
    //your code
}
區(qū)別在于Expires設(shè)置的是過期時(shí)間點(diǎn)，且該過期時(shí)間點(diǎn)參考的是本地時(shí)間，本地時(shí)間會(huì)因?yàn)闄C(jī)器故障、人為修改等原因不盡相同。而Cache-Control設(shè)置的則是過期時(shí)間段
另外，如果同時(shí)設(shè)置了Cache-Control和Expires，Expires會(huì)被覆蓋、會(huì)被忽略
ETag
MD5
全稱：MD5信息摘要算法
英文：Message Digest Algorithm MD5
作用：比較兩個(gè)文件的差異
原理：一個(gè)文件通過幾個(gè)步驟將產(chǎn)生出一個(gè)128位（16字節(jié)）的散列值（hash value）
特點(diǎn)：兩個(gè)文件，差異越小，算出來(lái)的MD5值差別越大
使用：專門生成MD5的軟件，npm安裝。。。
ETag
若需要啟用ETag設(shè)置，服務(wù)器要設(shè)置ETag響應(yīng)頭，該響應(yīng)頭將服務(wù)器端的頁(yè)面的MD5值返回給瀏覽器。這樣，瀏覽器在下次請(qǐng)求的時(shí)候，會(huì)多提交一個(gè)請(qǐng)求頭if-none-match，里面存放即是服務(wù)器響應(yīng)回來(lái)的MD5值。如此，服務(wù)器能夠?qū)Ρ茸约含F(xiàn)在的MD5和瀏覽器發(fā)送過來(lái)的MD5，如果一樣就不用返回服務(wù)器端頁(yè)面了，如果不一樣才將服務(wù)器端的新頁(yè)面返回給瀏覽器
ETag示例
前端代碼：
$.post("/sign_in", hash)
     .then((response)=>{
         window.location.href = "/index.html"
     }, (request)=>{
         alert("郵箱與密碼不匹配")
})
使用Node.js寫的后端：
if(path === "/sign_in" && method === "post"){
    //your code
    let string = fs.readFileSync("./sign_in.html","utf-8");
    let fileMD5 = md5(string);
    let lastMD5 = request.headers["if-none-match"];
    if(fileMD5 === lastMD5){
        response.statusCode = 304;
    }else{
        response.setHeader("ETag",fileMD5);
        response.write(string);
    }
    //your code
}
來(lái)來(lái)來(lái)，看這里：

第一，瀏覽器的第一個(gè)請(qǐng)求是沒有if-none-match這個(gè)請(qǐng)求的，所以，服務(wù)器會(huì)設(shè)置一個(gè)響應(yīng)頭response.setHeader("ETag",fileMD5);，將服務(wù)器端頁(yè)面的MD5返回給瀏覽器


第二，等瀏覽器再次發(fā)送請(qǐng)求的時(shí)候，就會(huì)多帶上一個(gè)請(qǐng)求頭if-none-match


第三，看到后端代碼，取到瀏覽器請(qǐng)求過來(lái)的MD5let lastMD5 = request.headers["if-none-match"];，得到服務(wù)器端文件現(xiàn)在的MD5let fileMD5 = md5(string);（已經(jīng)用npm安裝過生成MD5的程序），如果相同，返回304if(fileMD5 === lastMD5){response.statusCode = 304;}，如果不同，返回新的MD5和新的頁(yè)面else{response.setHeader("ETag",fileMD5);response.write(string);}


Last-Modify
Last-Modify和Etag作用一樣，用法也一樣，唯一不同的地方是ETag返回的是一個(gè)MD5值，而Last-Modify返回的是一個(gè)時(shí)間點(diǎn)。也就是說，ETag對(duì)比瀏覽器和服務(wù)器頁(yè)面的MD5，Last-Modify對(duì)比瀏覽器和服務(wù)器頁(yè)面的時(shí)間點(diǎn)。
如果更新時(shí)間間隔較短，請(qǐng)選用ETag，更新時(shí)間中等，可以選用Last-Modify。當(dāng)然，ETag優(yōu)先級(jí)是要高于Last-Modify的。另外，Lsat-Modify不支持秒級(jí)別更新。這一段請(qǐng)參考：https://www.zhihu.com/questio...
小結(jié)
關(guān)于HTTP緩存有下面幾種控制：


Cache-Control：使用Max-Age設(shè)定緩存過期時(shí)間段

Expires：直接設(shè)定緩存過期時(shí)間點(diǎn)

ETag：對(duì)比兩端文件的MD5值

Last-Modify：對(duì)比兩端文件的最后修改時(shí)間點(diǎn)