日本免费全黄少妇一区二区三区-高清无码一区二区三区四区-欧美中文字幕日韩在线观看-国产福利诱惑在线网站-国产中文字幕一区在线-亚洲欧美精品日韩一区-久久国产精品国产精品国产-国产精久久久久久一区二区三区-欧美亚洲国产精品久久久久

  1. 首頁(yè) > 云知道 > >

cookie與session的區(qū)別,session和cookie的區(qū)別( 二 )

云知道


Cookie 技術(shù)產(chǎn)生源于 HTTP 協(xié)議在互聯(lián)網(wǎng)上的急速發(fā)展 。隨著互聯(lián)網(wǎng)時(shí)代的策馬奔騰，帶寬等限制不存在了，人們需要更復(fù)雜的互聯(lián)網(wǎng)交互活動(dòng)，就必須同服務(wù)器保持活動(dòng)狀態(tài)（簡(jiǎn)稱：?；睿?。于是，在瀏覽器發(fā)展初期，為了適應(yīng)用戶的需求技術(shù)上推出了各種保持 Web 瀏覽狀態(tài)的手段，其中就包括了 Cookie 技術(shù) 。
搞不懂Session、Cookie、Token有何關(guān)系和區(qū)別？

cookie與session的區(qū)別,session和cookie的區(qū)別


前段時(shí)間，剛好大致的了解過(guò)這三者的區(qū)別 。為了方便理解，我們可以從傳統(tǒng)的Session到Token的身份驗(yàn)證演變過(guò)程，來(lái)理解Session、Cookie、Token之間的關(guān)系 。很久很久以前，Web應(yīng)用基本用于文檔的瀏覽，例如，網(wǎng)絡(luò)黃頁(yè) 。既然是瀏覽，服務(wù)器也就不需要去記錄具體用戶在哪段時(shí)間里瀏覽了哪些文檔，每一次請(qǐng)求都是一個(gè)新的HTTP協(xié)議，對(duì)服務(wù)器來(lái)說(shuō)都是全新的，這時(shí)候沒(méi)有Session、Cookie、Token 。
基于Session的身份驗(yàn)證隨著交互式Web應(yīng)用的發(fā)展，比如，像購(gòu)物等需要用戶登錄的網(wǎng)站 。引出了一個(gè)問(wèn)題，那就是網(wǎng)站需要記錄哪些用戶登錄了系統(tǒng)進(jìn)行了哪些操作，即要進(jìn)行管理會(huì)話（什么是會(huì)話？簡(jiǎn)單的講如果用戶需要登錄，那么就可以簡(jiǎn)單的理解為會(huì)話，如果不需要登錄，那么就是簡(jiǎn)單的連接 。），比如，不同用戶將不同商品加入到自己的購(gòu)物車中，也就是說(shuō)必須將每個(gè)用戶區(qū)分開(kāi) 。
但因?yàn)镠TTP請(qǐng)求是無(wú)狀態(tài)的，所以想出了一個(gè)解決辦法，那就是給每個(gè)用戶發(fā)一個(gè)會(huì)話標(biāo)識(shí)(Session id)，簡(jiǎn)單的說(shuō)就是給每個(gè)用戶發(fā)一個(gè)既不重復(fù)，又不容易被找到規(guī)律進(jìn)行仿造的隨機(jī)字符串，以使每個(gè)用戶收到的會(huì)話標(biāo)識(shí)都不一樣 。這樣每次用戶從客戶端向服務(wù)端發(fā)起HTTP請(qǐng)求的時(shí)候，把這個(gè)字符串給一起發(fā)送過(guò)來(lái)，服務(wù)端就可以區(qū)分開(kāi)誰(shuí)是誰(shuí)了 。
那么客戶端（瀏覽器）如何保存這個(gè)“身份標(biāo)識(shí)”的呢？，一般默認(rèn)采用 Cookie（存儲(chǔ)在瀏覽器目錄中的文本文件） 的方式，這個(gè)會(huì)話標(biāo)識(shí)(Session id)會(huì)存在客戶端的Cookie中 。雖然上面的方法解決了區(qū)分用戶的問(wèn)題，但同時(shí)也引入了一個(gè)新的問(wèn)題，那就是每個(gè)用戶（客戶端）只需要保存自己的會(huì)話標(biāo)識(shí)(Session id)，而服務(wù)端則要保存所有用戶的會(huì)話標(biāo)識(shí)(Session id) 。
當(dāng)訪問(wèn)服務(wù)端的用戶逐漸變多，服務(wù)端那就需要存儲(chǔ)成千上萬(wàn)，甚至幾千萬(wàn)個(gè)，這對(duì)服務(wù)器說(shuō)是一個(gè)難以接受的開(kāi)銷。我們?cè)倥e一個(gè)簡(jiǎn)單的例子，假如服務(wù)端是由2臺(tái)服務(wù)器組成的一個(gè)集群，小明通過(guò)服務(wù)器A登錄了系統(tǒng)，那 Session id會(huì)保存在服務(wù)器A上，假設(shè)小明的下一次請(qǐng)求被轉(zhuǎn)發(fā)到服務(wù)器B怎么辦？ 服務(wù)器B可沒(méi)有小明 的 Session id 。
可能會(huì)有人講，如果使小明登錄時(shí)，始終在服務(wù)器A上進(jìn)行登錄（sticky session），豈不解決了這個(gè)問(wèn)題？那如果服務(wù)器A掛掉怎么辦呢？ 還是會(huì)將小明的請(qǐng)求轉(zhuǎn)發(fā)到服務(wù)器B上，問(wèn)題仍然存在 。如此一來(lái)，那只能做集群間的 Session 復(fù)制共享了，就是把 Session id 在兩個(gè)機(jī)器之間進(jìn)行復(fù)制，如下圖，但這又對(duì)服務(wù)器的性能和內(nèi)存提出了巨大的挑戰(zhàn) 。
因此，又想到如果將所有用戶的Session集中存儲(chǔ)呢，也就想到了緩存服務(wù)Memcached——由于 Memcached 是分布式的內(nèi)存對(duì)象緩存系統(tǒng)，因此可以用來(lái)實(shí)現(xiàn) Session 同步 。把Session id 集中存儲(chǔ)到一臺(tái)服務(wù)器上，所有的服務(wù)器都來(lái)訪問(wèn)這個(gè)地方的數(shù)據(jù)，如此就避免了復(fù)制的方式，但是這種“集萬(wàn)千寵愛(ài)于一身”使得又出現(xiàn)了單點(diǎn)故障的可能，就是說(shuō)這個(gè)負(fù)責(zé)存儲(chǔ) Session 的服務(wù)器掛了，所有用戶都得重新登錄一遍，這是用戶難以接受的 。
那么索性將存儲(chǔ)Session的服務(wù)器也設(shè)計(jì)為集群，增加可靠性，避免單點(diǎn)故障，但無(wú)論如何，Session 引發(fā)出來(lái)的問(wèn)題似乎層出不窮 。于是有人開(kāi)始思考，為什么服務(wù)端必須要保存 Session呢，只讓每個(gè)客戶端去保存不行嗎？可是服務(wù)端如果不保存這些Session id，又將如何驗(yàn)證客戶端發(fā)送的 Session id 的確是服務(wù)端生成的呢？ 如果不驗(yàn)證，服務(wù)端無(wú)法判斷是否是合法登錄的用戶，對(duì)，這里的問(wèn)題是驗(yàn)證，session 只是解決這個(gè)驗(yàn)證問(wèn)題的而產(chǎn)生的一個(gè)解決方案，是否還有其它方案呢？——于是，引出了基于Token 的身份驗(yàn)證 。

推薦閱讀