cookie會(huì)被用戶改,怎么解決?用Session來(lái)解決
弄一個(gè)sessionId





這就是sessions
服務(wù)器通過(guò)cookie給用戶一個(gè)sessionId
sessionId對(duì)應(yīng)服務(wù)器內(nèi)一小塊內(nèi)存,每次用戶訪問(wèn)服務(wù)器的時(shí)候,服務(wù)器就通過(guò)sessionId去讀取對(duì)應(yīng)的session,然后知道用戶的隱私信息
這里的這個(gè)安全是通過(guò)隨機(jī)數(shù)來(lái)保證的
cookie
1、服務(wù)器通過(guò)Set-Cookie響應(yīng)頭設(shè)置cookie(一段字符串)
2、客戶每次訪問(wèn)相同域名的頁(yè)面時(shí),必須帶上這段字符串
3、客戶端要在一段時(shí)間內(nèi)保存這個(gè)cookie
4、默認(rèn)在用戶關(guān)閉頁(yè)面的時(shí)候就失效,后臺(tái)代碼可以任意的設(shè)置cookie的過(guò)期時(shí)間
Session 是服務(wù)器上的hash 缺點(diǎn):占內(nèi)存
1、將sessionId(隨機(jī)數(shù))通過(guò)cookie發(fā)給客戶端
2、客戶端訪問(wèn)服務(wù)器時(shí),服務(wù)器讀取sessionId
3、服務(wù)器有一塊內(nèi)存(哈希表)保存了所有session
4、通過(guò)sessionId我們可以得到對(duì)應(yīng)用戶的隱私信息,如ID、email
5、這塊內(nèi)存(哈希表)就是服務(wù)器上的所有session

接下里localstorage 是HTML5技術(shù)提供的一個(gè)API

localstorage實(shí)質(zhì)是個(gè)hash,是瀏覽器上的hash



只能存string




接下來(lái)localstorage的用法
比如我在一個(gè)頁(yè)面里寫了var a=1并打印,我在控制臺(tái)改下a的值為2,刷新頁(yè)面,之前的a不存在了,現(xiàn)在是新的a,a仍然為1,那如何讓一個(gè)變量在第一個(gè)頁(yè)面的時(shí)候存在,到第二個(gè)頁(yè)面的時(shí)候還是之前那個(gè)值呢?
通過(guò)localstorage
對(duì)于windows用戶來(lái)說(shuō),localstorage存在C盤的一個(gè)文件里




過(guò)程
實(shí)際應(yīng)用場(chǎng)景:
比如某網(wǎng)址要改版了,進(jìn)入頁(yè)面提示“我們網(wǎng)址改版了”,再刷新繼續(xù)提示,再刷新,繼續(xù)提示,這個(gè)就很不友好,我們把這個(gè)不要存在變量里,存在localstorage里


localstorage
1、localstorage與http無(wú)關(guān)
2、http不會(huì)帶上localstorage的值
3、只有相同域名的頁(yè)面才能互相讀取localstorage(沒(méi)有同源那么嚴(yán)格)
4、每個(gè)域名localstorage的最大存儲(chǔ)量5Mb左右(每個(gè)瀏覽器不一樣)
5、常用場(chǎng)景:記錄有沒(méi)有提示過(guò)用戶(沒(méi)有用的信息,不能記錄密碼)

)及其他網(wǎng)站數(shù)據(jù)就包括localstorage
sessionstorage(會(huì)話存儲(chǔ))
1、2、3、4同上,


一般來(lái)說(shuō),session是基于cookie實(shí)現(xiàn)的,session是依賴于cookie的,cookie是session的基石
cookie一般是4K,localstorage是5M
不基于cookie的session,通過(guò)查詢參數(shù)和localstorage來(lái)存儲(chǔ)id

到登錄頁(yè)

然后到server.js里的路由

然后到首頁(yè)


為什么會(huì)有把cookie和localstorage放在一起比較?
因?yàn)閘ocalstorage是新的API,之前前端如何做跨頁(yè)面的持久化存儲(chǔ)呢?只能通過(guò)cookie,cookie也是存在C盤的,之前的前端經(jīng)常把數(shù)據(jù)存到cookie上,用來(lái)跨頁(yè)面調(diào)用,cookie上的數(shù)據(jù)都會(huì)隨著請(qǐng)求被帶到服務(wù)器上去,如果數(shù)據(jù)很大,那么請(qǐng)求會(huì)很慢
前端要寫cookie嗎?千萬(wàn)不要,后端寫后端讀
接下來(lái)是http緩存
cache-control
加2個(gè)路由


把cdn上的bootstrap.css拷貝到本地

來(lái)找一個(gè)比較大的js


有沒(méi)有辦法讓其變快呢?




整個(gè)過(guò)程

問(wèn)題:為什么不能在首頁(yè)設(shè)置緩存?

就是路由是/的
因?yàn)槿绻氵B首頁(yè)都設(shè)置緩存(比如30天),當(dāng)你的頁(yè)面有更新的時(shí)候,客戶是不知道你最新的頁(yè)面的,客戶打開的還是你緩存里的
如果max-age設(shè)置的比較長(zhǎng),那如果在這期間,服務(wù)器需要更新怎么辦?
只需要讓URL稍微的不一樣即可(因?yàn)槿绻峭瑯拥腢RL,瀏覽器不需要向服務(wù)器發(fā)請(qǐng)求,直接使用緩存)
比如我deault.css變了點(diǎn),那么我URL加查詢參數(shù)即可,但是還是訪問(wèn)的是同樣的css


在cache-control之前是用Expires來(lái)加緩存
格式如下:

右邊是格林威治時(shí)間格式,

Expires表示具體到什么時(shí)候過(guò)期,指的是本地時(shí)間,如果用戶本地時(shí)間錯(cuò)亂了,那就有問(wèn)題了
如果2個(gè)同時(shí)使用,則優(yōu)先使用cache-control
接下來(lái)是last-modified
ETag是為了給文件一個(gè)版本號(hào)的
md5是一個(gè)摘要算法
假設(shè)你下載一個(gè)文件,下載過(guò)程中,你怎么知道自己下的對(duì)不對(duì)呢?萬(wàn)一少下載一個(gè)字節(jié)怎么辦
md5就是解決這個(gè)的,假設(shè)這個(gè)文件算了一個(gè)MD5,你下載完了之后也給文件算一個(gè)MD5值,2個(gè)值一比較,理論應(yīng)該一樣
內(nèi)容差異越小,md5算法算出的結(jié)果就越大
先安裝md5

https://www.npmjs.com/package/md5
然后開始用


設(shè)置響應(yīng)頭

頁(yè)面刷新下

請(qǐng)求頭了多了一個(gè)if -None-Match,值和上面的響應(yīng)頭里的ETag一樣
如果新請(qǐng)求的版本和之前一樣,那么就不需要下載


很小,因?yàn)椴恍枰螺d
ETag是發(fā)請(qǐng)求,但是如果md5值一樣,則不需要下載內(nèi)容
cache-control是根本就不發(fā)請(qǐng)求,直接用緩存里的