摘要:不是很安全,別人可以分析存放在本地的并進行欺騙,考慮到安全應當使用。因此不是一種持久化的本地存儲,僅僅是會話級別的存儲。用于持久化的本地存儲,除非主動刪除數(shù)據(jù),否則數(shù)據(jù)是永遠不會過期的。
前言
總括:詳細講述Cookie,LocalStorge,SesstionStorge的區(qū)別和用法。
人生如畫,歲月如歌。
1. 各種存儲方案的簡單對比原文博客地址:Javascript本地存儲小結(jié)
知乎專欄&&簡書專題:前端進擊者(知乎)&&前端進擊者(簡書)
Cookies:瀏覽器均支持,容量為4KB
UserData:僅IE支持,容量為64KB
Flash:100KB,非HTML原生,需要插件支持
Google Gears SQLite :需要插件支持,容量無限制
LocalStorage:HTML5,容量為5M
SesstionStorage:HTML5,容量為5M
globalStorage:Firefox獨有的,F(xiàn)irefox13開始就不再支持這個方法
2. CookieUserData僅IE支持, Google Gears SQLite需要插件,F(xiàn)lash已經(jīng)伴隨著HTML5的出現(xiàn)漸漸退出了歷史舞臺,因此今天我們的主角只有他們?nèi)齻€:Cookie,LocalStorge,SesstionStorge;
作為一個前端和Cookie打交道的次數(shù)肯定不會少了,Cookie算是比較古老的技術了
1993 年,網(wǎng)景公司雇員 Lou Montulli 為了讓用戶在訪問某網(wǎng)站時,進一步提高訪問速度,同時也為了進一步實現(xiàn)個人化網(wǎng)絡,發(fā)明了今天廣泛使用的 Cookie。
我們先來看下Cookie的特點:
1)cookie的大小受限制,cookie大小被限制在4KB,不能接受像大文件或郵件那樣的大數(shù)據(jù)。
2)只要有請求涉及cookie,cookie就要在服務器和瀏覽器之間來回傳送(這解釋為什么本地文件不能測試cookie)。而且cookie數(shù)據(jù)始終在同源的http請求中攜帶(即使不需要),這也是Cookie不能太大的重要原因。正統(tǒng)的cookie分發(fā)是通過擴展HTTP協(xié)議來實現(xiàn)的,服務器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。
3)用戶每請求一次服務器數(shù)據(jù),cookie則會隨著這些請求發(fā)送到服務器,服務器腳本語言如PHP等能夠處理cookie發(fā)送的數(shù)據(jù),可以說是非常方便的。當然前端也是可以生成Cookie的,用js對cookie的操作相當?shù)姆爆崳瑸g覽器只提供document.cookie這樣一個對象,對cookie的賦值,獲取都比較麻煩。而在PHP中,我們可以通過setcookie()來設置cookie,通過$_COOKIE這個超全局數(shù)組來獲取cookie。
2.2 Sessioncookie的內(nèi)容主要包括:名字,值,過期時間,路徑和域。路徑與域一起構(gòu)成cookie的作用范圍。若不設置過期時間,則表示這個cookie的生命期為瀏覽器會話期間,關閉瀏覽器窗口,cookie就消失。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不存儲在硬盤上而是保存在內(nèi)存里,當然這種行為并不是規(guī)范規(guī)定的。若設置了過期時間,瀏覽器就會把cookie保存到硬盤上,關閉后再次打開瀏覽器,這些cookie仍然有效直到超過設定的過期時間。存儲在硬盤上的cookie可以在不同的瀏覽器進程間共享,比如兩個IE窗口。而對于保存在內(nèi)存里的cookie,不同的瀏覽器有不同的處理方式。
說到Cookie就不能不說Session。
Session機制。session機制是一種服務器端的機制,服務器使用一種類似于散列表的結(jié)構(gòu)(也可能就是使用散列表)來保存信息。當程序需要為某個客戶端的請求創(chuàng)建一個session時,服務器首先檢查這個客戶端的請求里是否已包含了一個session標識(稱為session id),如果已包含則說明以前已經(jīng)為此客戶端創(chuàng)建過session,服務器就按照session id把這個session檢索出來使用(檢索不到,會新建一個),如果客戶端請求不包含session id,則為此客戶端創(chuàng)建一個session并且生成一個與此session相關聯(lián)的session id,session id的值應該是一個既不會重復,又不容易被找到規(guī)律以仿造的字符串,這個session id將被在本次響應中返回給客戶端保存。保存這個session id的方式可以采用cookie,這樣在交互過程中瀏覽器可以自動的按照規(guī)則把這個標識發(fā)送給服務器。一般這個cookie的名字都是類似于SEEESIONID。但cookie可以被人為的禁止,則必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞回服務器。經(jīng)常被使用的一種技術叫做URL重寫,就是把session id直接附加在URL路徑的后面。比如:http://damonare.cn?sessionid=123456還有一種技術叫做表單隱藏字段。就是服務器會自動修改表單,添加一個隱藏字段,以便在表單提交時能夠把session id傳遞回服務器。比如:
實際上這種技術可以簡單的用對action應用URL重寫來代替。
2.3 Cookie和Session簡單對比Cookie和Session 的區(qū)別:
1)cookie數(shù)據(jù)存放在客戶的瀏覽器上,session數(shù)據(jù)放在服務器上。
2)cookie不是很安全,別人可以分析存放在本地的cookie并進行cookie欺騙,考慮到安全應當使用session。
3)session會在一定時間內(nèi)保存在服務器上。當訪問增多,會比較占用你服務器的性能考慮到減輕服務器性能方面,應當使用cookie。
4)單個cookie保存的數(shù)據(jù)不能超過4K,很多瀏覽器都限制一個站點最多保存20個cookie。
5)所以建議:
將登陸信息等重要信息存放為SESSION
其他信息如果需要保留,可以放在cookie中
2.4 document.cookie的屬性expires屬性
指定了coolie的生存期,默認情況下coolie是暫時存在的,他們存儲的值只在瀏覽器會話期間存在,當用戶推出瀏覽器后這些值也會丟失,如果想讓cookie存在一段時間,就要為expires屬性設置為未來的一個過期日期?,F(xiàn)在已經(jīng)被max-age屬性所取代,max-age用秒來設置cookie的生存期。
path屬性
它指定與cookie關聯(lián)在一起的網(wǎng)頁。在默認的情況下cookie會與創(chuàng)建它的網(wǎng)頁,該網(wǎng)頁處于同一目錄下的網(wǎng)頁以及與這個網(wǎng)頁所在目錄下的子目錄下的網(wǎng)頁關聯(lián)。
domain屬性
domain屬性可以使多個web服務器共享cookie。domain屬性的默認值是創(chuàng)建cookie的網(wǎng)頁所在服務器的主機名。不能將一個cookie的域設置成服務器所在的域之外的域。例如讓位于order.damonare.cn的服務器能夠讀取catalog.damonare.cn設置的cookie值。如果catalog.damonare.cn的頁面創(chuàng)建的cookie把自己的path屬性設置為“/”,把domain屬性設置成“.damonare.cn”,那么所有位于catalog.damonare.cn的網(wǎng)頁和所有位于orlders.damonare.cn的網(wǎng)頁,以及位于damonare.cn域的其他服務器上的網(wǎng)頁都可以訪問這個cookie。
secure屬性
2.5 cookie實戰(zhàn)它是一個布爾值,指定在網(wǎng)絡上如何傳輸cookie,默認是不安全的,通過一個普通的http連接傳輸
這里我們使用javascript來寫一段cookie,借用w3cschool的demo:
function getCookie(c_name){ if (document.cookie.length>0){ c_start=document.cookie.indexOf(c_name + "=") if (c_start!=-1){ c_start=c_start + c_name.length+1 c_end=document.cookie.indexOf(";",c_start) if (c_end==-1) c_end=document.cookie.length return unescape(document.cookie.substring(c_start,c_end)) } } return ""; } function setCookie(c_name,value,expiredays){ var exdate=new Date() exdate.setDate(exdate.getDate()+expiredays) document.cookie=c_name+ "=" +escape(value)+ ((expiredays==null) ? "" : "; expires="+exdate.toUTCString()) } function checkCookie(){ username=getCookie("username") if(username!=null && username!=""){alert("Welcome again "+username+"!")} else{ username=prompt("Please enter your name:","") if (username!=null && username!=""){ setCookie("username",username,355) } } }
3. localStorage注意這里對Cookie的生存期進行了定義,也就是355天
這是一種持久化的存儲方式,也就是說如果不手動清除,數(shù)據(jù)就永遠不會過期。
它也是采用Key - Value的方式存儲數(shù)據(jù),底層數(shù)據(jù)接口是sqlite,按域名將數(shù)據(jù)分別保存到對應數(shù)據(jù)庫文件里。它能保存更大的數(shù)據(jù)(IE8上是10MB,Chrome是5MB),同時保存的數(shù)據(jù)不會再發(fā)送給服務器,避免帶寬浪費。
3.1 localStorage的屬性方法下表是localStorge的一些屬性和方法
屬性方法 | 說明 |
---|---|
localStorage.length | 獲得storage中的個數(shù) |
localStorage.key(n) | 獲得storage中第n個元素對的鍵值(第一個元素是0) |
localStorage.getItem(key) | 獲取鍵值key對應的值 |
localStorage.key | 獲取鍵值key對應的值 |
localStorage.setItem(key, value) | 添加數(shù)據(jù),鍵值為key,值為value |
localStorage.removeItem(key) | 移除鍵值為key的數(shù)據(jù) |
localStorage.clear() | 清除所有數(shù)據(jù) |
① localStorage大小限制在500萬字符左右,各個瀏覽器不一致
② localStorage在隱私模式下不可讀取
③ localStorage本質(zhì)是在讀寫文件,數(shù)據(jù)多的話會比較卡(firefox會一次性將數(shù)據(jù)導入內(nèi)存,想想就覺得嚇人?。?/p>
④ localStorage不能被爬蟲爬取,不要用它完全取代URL傳參
4. sessionStorage和服務器端使用的session類似,是一種會話級別的緩存,關閉瀏覽器會數(shù)據(jù)會被清除。不過有點特別的是它的作用域是窗口級別的,也就是說不同窗口間的sessionStorage數(shù)據(jù)不能共享的。使用方法(和localStorage完全相同):
屬性方法 | 說明 |
---|---|
sessionStorage.length | 獲得storage中的個數(shù) |
sessionStorage.key(n) | 獲得storage中第n個元素對的鍵值(第一個元素是0) |
sessionStorage.getItem(key) | 獲取鍵值key對應的值 |
sessionStorage.key | 獲取鍵值key對應的值 |
sessionStorage.setItem(key, value) | 添加數(shù)據(jù),鍵值為key,值為value |
sessionStorage.removeItem(key) | 移除鍵值為key的數(shù)據(jù) |
sessionStorage.clear() | 清除所有數(shù)據(jù) |
sessionStorage用于本地存儲一個會話(session)中的數(shù)據(jù),這些數(shù)據(jù)只有在同一個會話中的頁面才能訪問并且當會話結(jié)束后數(shù)據(jù)也隨之銷毀。因此sessionStorage不是一種持久化的本地存儲,僅僅是會話級別的存儲。當用戶關閉瀏覽器窗口后,數(shù)據(jù)立馬會被刪除。
localStorage用于持久化的本地存儲,除非主動刪除數(shù)據(jù),否則數(shù)據(jù)是永遠不會過期的。第二天、第二周或下一年之后,數(shù)據(jù)依然可用。
5.1 測試sessionStorage:
if (sessionStorage.pagecount){ sessionStorage.pagecount=Number(sessionStorage.pagecount) +1; }else{ sessionStorage.pagecount=1; } console.log("Visits "+ sessionStorage.pagecount + " time(s).");
測試過程:我們在控制臺輸入上述代碼查看打印結(jié)果
控制臺首次輸入代碼:
關閉窗口,控制臺再次輸入代碼:
所謂的關閉窗口即銷毀,就是這樣,關閉窗口重新打開輸入代碼輸出結(jié)果還是上面圖片的樣子,也就是說關閉窗口后sessionStorage.pagecount即被銷毀,除非重心創(chuàng)建?;蛘邚臍v史記錄進入才會相關數(shù)據(jù)才會存在。好的,我們再來看下localStorge表現(xiàn):
if (localStorage.pagecount){ localStorage.pagecount=Number(localStorage.pagecount) +1; }else{ localStorage.pagecount=1; } console.log("Visits "+ localStorage.pagecount + " time(s).");
控制臺首次輸入代碼:
關閉窗口,控制臺再次輸入代碼:
6. web Storage和cookie的區(qū)別Web Storage(localStorage和sessionStorage)的概念和cookie相似,區(qū)別是它是為了更大容量存儲設計的。Cookie的大小是受限的,并且每次你請求一個新的頁面的時候Cookie都會被發(fā)送過去,這樣無形中浪費了帶寬,另外cookie還需要指定作用域,不可以跨域調(diào)用。
除此之外,Web Storage擁有setItem,getItem,removeItem,clear等方法,不像cookie需要前端開發(fā)者自己封裝setCookie,getCookie。
但是Cookie也是不可以或缺的:Cookie的作用是與服務器進行交互,作為HTTP規(guī)范的一部分而存在 ,而Web Storage僅僅是為了在本地“存儲”數(shù)據(jù)而生
后記博主盡可能思路清晰的理了一遍cookie,session,localStorage,sessionStorage之間的區(qū)別和聯(lián)系,希望可以幫到大家。
參考文章:
cookie 和session 的區(qū)別詳解
文章版權歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://m.hztianpu.com/yun/80913.html
摘要:二目的是一個經(jīng)策略性部署的整體系統(tǒng),從技術上全面解決由于網(wǎng)絡帶寬小用戶訪問量大網(wǎng)點分布不均而產(chǎn)生的用戶訪問網(wǎng)站響應速度慢的根本原因。 一、CDN全稱:??Content Delivery Network或Content Ddistribute Network,即內(nèi)容分發(fā)網(wǎng)絡。 ??二、目的:??CDN是一個經(jīng)策略性部署的整體系統(tǒng),從技術上全面解決由于網(wǎng)絡帶寬小、用戶訪問量大、網(wǎng)點分布不...
摘要:高性能小結(jié)文章轉(zhuǎn)載于我的博客最近看完了動物叢書的高性能,覺得那本書的小結(jié)部分寫得非常不錯,簡潔輕快易懂概括性很強。由于局部變量存在于作用域鏈的起始位置,因此訪問局部變量比訪問跨作用域變量更快。 高性能javascript小結(jié) 文章轉(zhuǎn)載于我的CSDN博客:http://blog.csdn.net/hello_world_20/article/details/46793317 最近看完了動...
摘要:本文已同步到中常見的設計模式如果感覺寫的還可以,就給個小星星吧,歡迎和收藏。本文中關于各種設計模式定義都是引用書中的,部分引用自百度百科已標出。下面把我整理出的常用設計模式按類型做個表格整理。 本文已同步到Github JavaScript中常見的設計模式,如果感覺寫的還可以,就給個小星星吧,歡迎star和收藏。 最近拜讀了曾探大神的《JavaScript設計模式與開發(fā)實踐》,真是醍醐...
摘要:幾乎所有的系統(tǒng)都存在生成唯一的需求,如用戶賬單等,由于系統(tǒng)通常是分布式架構(gòu),因而需要有合適的分布式生成方案。優(yōu)勢和數(shù)據(jù)庫自增方案類似缺點同樣仍然有性能上限,依賴數(shù)據(jù)庫的可用性。使用時,可以使用具體的場景選擇合適的方案。幾乎所有的系統(tǒng)都存在生成唯一ID的需求,如用戶ID、賬單ID等,由于系統(tǒng)通常是分布式架構(gòu),因而需要有合適的分布式ID生成方案。常見的分布式唯一ID方法有(歡迎補充):時間戳數(shù)據(jù)...
閱讀 2977·2021-10-14 09:42
閱讀 3675·2021-10-11 10:59
閱讀 3011·2019-08-30 11:25
閱讀 3138·2019-08-29 16:25
閱讀 3281·2019-08-26 17:40
閱讀 1325·2019-08-26 13:30
閱讀 1215·2019-08-26 11:46
閱讀 1389·2019-08-23 15:22