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

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

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

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

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

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

第四，每一次請求，服務器可以讀取cookie，獲取cookie中包含的信息（用戶資料、特定頁面信息等），然后向瀏覽器返回相應的內(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()方法向服務器朝/sign_in路徑發(fā)送了一個請求，將變量hash傳給了服務器。
第二步，后端代碼（服務器）在//your code里對變量hash處理后，將處理結(jié)果變成"sign_in_email=${email}"的字符串（其中${email}表示變量email代表的數(shù)據(jù)），然后設(shè)置了響應頭Set-Cookie返回給瀏覽器，并加諸了像HttpOnly、Max-Age等各類設(shè)置（詳細說明請參見https://developer.mozilla.org...）。
第三步，瀏覽器收到了服務器返回的響應頭Set-Cookie和cookie（字符串），說明請求成功了，會將網(wǎng)頁重定向為/index.html（這里使用了promise：.then((response)=>{window.location.href = "/index.html"）。所以瀏覽器又向服務器發(fā)送了一次請求。這次請求會帶上cookie

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

cookie的幾個特點


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


cookie存在硬盤的某一個神秘文件里

cookie很容易被修改，用戶可以自己進入瀏覽器控制臺修改cookie
看到下圖，Firfox的控制臺進入存儲、進入Cookies，我們修改了兩個值，并且刷新后，一個值會變回來，一個值沒有變回來




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



cookie應用
可想而知，cookie最常用的就是注冊&登陸啦~~~

先在瀏覽器注冊，注冊好了就向瀏覽器發(fā)送請求，報告！請求注冊成功頁面??！

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


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

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

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

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

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

第四，之后，瀏覽器每請求一次服務器，就會帶上這個含有sessionId的cookie，服務器就會讀取sessionId，并在session哈希里查找sessionId對應的值，然后作出相應的操作

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作對比知道：

第一，在服務器我們設(shè)置了一個哈希let session = {}

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

第四，瀏覽器請求成功，網(wǎng)頁重定向為/index.html，重新發(fā)送請求，帶有cookie，其中帶有sessionId

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

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


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


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


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


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


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


localStorage的特點

和http無關(guān)，意味著它不會存在于瀏覽器和服務器之間的通信，請求響應時不會帶上localStorage的值
只有相同域名的頁面才能互相讀取localStorage

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



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


永久有效，除非手動清理

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

小結(jié)


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




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


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


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

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


http緩存
Cache-Control
顧名思義，控制緩存
若服務器設(shè)置了該項設(shè)置，意味著頁面將被放在緩存里，當瀏覽器需要請求服務器的時候，將不會將請求發(fā)送至服務器，而是直接調(diào)用緩存里的頁面。
各類屬性詳細請參考：https://developer.mozilla.org...
請看下圖，右側(cè)瀏覽器Chorme向服務器Server請求/main.js，服務器Server返回瀏覽器Chorme一個Max-Age=30的Cache-Control的響應頭。那么接下來的30s內(nèi)，瀏覽器Chorme再向服務器Server請求/main.js，注意！?。”仨毷峭耆嗤腢RL?。?！，會直接從緩存（內(nèi)存）里調(diào)用main.js，直到過了30s從能再從服務器端獲取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的時間內(nèi)，任何以post方法向服務器/sign_in路徑的請求，都不會被發(fā)送，而會直接調(diào)用緩存里/index.html的頁面
Cache-Control的幾個特點

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

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


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

Expires
曾經(jīng)，我們使用Expires設(shè)置緩存控制響應頭：
if(path === "/sign_in" && method === "post"){
    //your code
    response.setHeader("Expires","Sun, 04 Feb 2018 14:00:05 GM");
    //your code
}
區(qū)別在于Expires設(shè)置的是過期時間點，且該過期時間點參考的是本地時間，本地時間會因為機器故障、人為修改等原因不盡相同。而Cache-Control設(shè)置的則是過期時間段
另外，如果同時設(shè)置了Cache-Control和Expires，Expires會被覆蓋、會被忽略
ETag
MD5
全稱：MD5信息摘要算法
英文：Message Digest Algorithm MD5
作用：比較兩個文件的差異
原理：一個文件通過幾個步驟將產(chǎn)生出一個128位（16字節(jié)）的散列值（hash value）
特點：兩個文件，差異越小，算出來的MD5值差別越大
使用：專門生成MD5的軟件，npm安裝。。。
ETag
若需要啟用ETag設(shè)置，服務器要設(shè)置ETag響應頭，該響應頭將服務器端的頁面的MD5值返回給瀏覽器。這樣，瀏覽器在下次請求的時候，會多提交一個請求頭if-none-match，里面存放即是服務器響應回來的MD5值。如此，服務器能夠?qū)Ρ茸约含F(xiàn)在的MD5和瀏覽器發(fā)送過來的MD5，如果一樣就不用返回服務器端頁面了，如果不一樣才將服務器端的新頁面返回給瀏覽器
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
}
來來來，看這里：

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


第二，等瀏覽器再次發(fā)送請求的時候，就會多帶上一個請求頭if-none-match


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


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


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

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

ETag：對比兩端文件的MD5值

Last-Modify：對比兩端文件的最后修改時間點