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

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

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

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

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

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

第四，每一次請求，服務器可以讀取cookie，獲取cookie中包含的信息（用戶資料、特定頁面信息等），然后向瀏覽器返回相應的內容

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

第四步，服務器又收到了一次請求，這次請求的路徑是/index.html，并且帶有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的有效期默認由瀏覽器自己決定，當然可以通過后端設置cookie的保存時間
當然，不同后端語法不一樣寫法不一樣，通常都是設定Max-Age或者Expires屬性
詳細可以參見：
Set-Cookie：https://developer.mozilla.org...
HTTP cookies：https://developer.mozilla.org...



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

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

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


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

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

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

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

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

第四，之后，瀏覽器每請求一次服務器，就會帶上這個含有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
}
上面發生了什么可以通過和cookie作對比知道：

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

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

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

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

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


設置一個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無關，意味著它不會存在于瀏覽器和服務器之間的通信，請求響應時不會帶上localStorage的值
只有相同域名的頁面才能互相讀取localStorage

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



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


永久有效，除非手動清理

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

小結


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




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


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


sessionStorage和localStorage有啥區別？
sessionStorage在頁面關閉（會話結束）后就被全部清空，而localStorage則不會。

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


http緩存
Cache-Control
顧名思義，控制緩存
若服務器設置了該項設置，意味著頁面將被放在緩存里，當瀏覽器需要請求服務器的時候，將不會將請求發送至服務器，而是直接調用緩存里的頁面。
各類屬性詳細請參考：https://developer.mozilla.org...
請看下圖，右側瀏覽器Chorme向服務器Server請求/main.js，服務器Server返回瀏覽器Chorme一個Max-Age=30的Cache-Control的響應頭。那么接下來的30s內，瀏覽器Chorme再向服務器Server請求/main.js，注意！！！必須是完全相同的URL！！！，會直接從緩存（內存）里調用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的時間內，任何以post方法向服務器/sign_in路徑的請求，都不會被發送，而會直接調用緩存里/index.html的頁面
Cache-Control的幾個特點

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

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


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

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


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


第三，看到后端代碼，取到瀏覽器請求過來的MD5let lastMD5 = request.headers["if-none-match"];，得到服務器端文件現在的MD5let fileMD5 = md5(string);（已經用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優先級是要高于Last-Modify的。另外，Lsat-Modify不支持秒級別更新。這一段請參考：https://www.zhihu.com/questio...
小結
關于HTTP緩存有下面幾種控制：


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

Expires：直接設定緩存過期時間點

ETag：對比兩端文件的MD5值

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