缓存、cookie、token、session、localSto
一、缓存分类
- 服务器端缓存(CDN缓存)
- 客户端缓存(浏览器缓存);
二、浏览器缓存
- 强缓存:
浏览器在加载资源时,先根据这个资源的一些http header判断它是否命中强缓存,强缓存如果命中,浏览器直接从自己的缓存中读取资源,不会发送请求到浏览器,比如某个css文件,如果浏览器在加载它所在的网页时,这个css文件的缓存配置命中了强缓存,浏览器就直接从缓存中加载这个css,连请求都不会发送到网页所在的服务器; - 协商缓存:
当强缓存没有命中的时候,浏览器一定会发送一个请求到服务器,通过服务器依据资源的另外一些HTTP header验证这个资源是否命中协商缓存;
如果命中协商缓存,服务器会将这个请求返回(304),但是不会返回这个资源的数据,而是告诉客户端可以直接从缓存中加载这个资源,于是浏览器就会又从自己的缓存中去加载这个资源;
若未命中请求,则将资源返回客户端,并更新本地缓存数据(200); - 协商缓存与强缓存的区别:
强缓存不发送请求到服务器,协商缓存会发送请求到服务器; - 如何设置缓存:
1)HTML Meta标签控制缓存(非HTTP协议定义)
<META HTTP-EQUIV="Pragma" CONTENT="no-cache">
上述代码的作用是告诉浏览器当前页面不被缓存,每次访问都需要去服务器拉取,这种方法使用上很简单,但只有部分浏览器可以支持,而且有缓存代理的服务器都不支持,因为代理不解析HTML内容本身;
2)HTTP头信息控制缓存:HTTP头信息控制缓存是通地Expires(强缓存)、Cache-control(强缓存)、Last-Modified/If-Modified-Slice(协商缓存)、Etag/If-None-Match(协商缓存)实现;
- Expires:是Http1.0提出的一个表示资源过期时间的header,它描述的是一个绝对时间,由服务器返回,用GMT格式的字符串表示,如
Expires:Thu,31 Dec 2016 23:55:55 GMT
读取缓存数据条件:缓存过期时间(服务器的)<当前时间(客户端的);缺点是Expires是较老的强缓存管理header,由于它是服务器返回的一个绝对时间,这样存在一个问题,如果客户端的时间与服务器的时间相差很大(比如时钟不同步,或者跨时区),那么误差就较大,所以在HTTP1.1版本开始,使用Cache-Control: max-age=秒代替;
- Cache-Control描述的是一个相对时间,在进行缓存命中的时候,都是利用客户端时间进行判断,所以相比较Expires,Cache-Control的缓存管理更加有效,安全一些,读取缓存的数据条件:上次缓存时间(客户端的)+max-age<当前时间(客户端的),Cache-Control的值可以是public(指示响应可被任何缓存区缓存),private(指示对于单个用户的整个或部分响应消息,不能被共享缓存处理,这允许服务器仅仅描述当前用户的部分响应消息,此响应消息对于其他用户的请求无效),no-cache(请求或响应消息不能缓存,该选项并不是说可以设置“不缓存”,而是需要和服务器确认),no-store(在请求消息中发送将使得请求和响应消息都不使用缓存,完全存不下来),max-age(指示客户机可以接收生存期不大于指定时间,以秒为单位的响应),这两个header可以只启用一个,也可以同时启用,当response header中,Expires和Cache-Control同时存在时,Cache-Control的优先级高于Expires;
- Last-Modified/If-Modified-Since:要配合Cache-Control使用,Last-Modified标志这个响应资源的最后修改时间,web服务器在响应请求时,告诉浏览器资源的最后修改时间,If-Modified-Since:当资源过期时(强缓存失效),发现资源具有Last-Modified声明,则再次向web服务器请求时带上If-Modified-Since,表示请求时间,web服务器收到请求后发现有头If-Modified-Since,则与被请求资源的最后修改时间进行比对,若最后修改时间较新,说明资源被改动过,则响应整片资源内容(写在响应消息包体内),HTTP 200;若最后修改时间较旧,说明资源无新修改,则响应HTTP 304(无需包体,节省浏览),告知浏览器继续使用所保存的cache;缺点是:Last-Modified标注的最后修改只能精确到秒级,如果某些文件在1秒钟以内被修改多次的话,它将不能准确标注文件的修改时间(无法及时更新文件);如果某些文件会被定期生成,当有时内容并没有任何变化,但Last-Modified却被改变了,导致文件没法使用缓存,有可能存在服务器没有准确获取文件修改时间,或者与代理服务器时间不一致等情形(无法使用缓存);
- Etag/If-None-Match:需要配合Cache-Control使用;
Etag:web服务器响应请求时,告诉浏览器当前资源在服务器的唯一标识(生成规则由服务器决定);
If-None-Match:当资源过期时(使用Cache-Control标识的max-age),发现资源具有Etag声明,则再次向web服务器请求时带上头If-None-Match(Etag的值),web服务器收到请求后发现有头If-None-Match则与被请求资源的相应校验串进行比对,决定返回200或304,Etag是服务器自动生成或由开发者生成的对应资源在服务器端的唯一标识符,能够更加准确的控制缓存,Last-Modified与Etag一起使用时,服务器会优先验证Etag; - 304:如果客户端发送了一个带条件的GET 请求且该请求已被允许,而文档的内容(自上次访问以来或者根据请求的条件)并没有改变,则服务器应当返回这个304状态码。简单的表达就是:客户端已经执行了GET,但文件未变化;
三、服务器端缓存
- CDN缓存:属于Cache服务器的一种,CDN(Content Delivery Network内容分发网络),其目的是通过现在的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络“边缘”,即通过调试系统将用户的请求路由引导到离用户接入网络最近或者访问效果最佳的缓存服务器上,由该缓存服务器为用户提供内容服务,相对于直接访问源站,这种方式缩短了用户和内容之间的网络距离,从而达到加速的效果;使用户可以就近取得所需的内容,解决Internet网络拥塞状况,提高用户访问网站的响应速度,从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因,解决用户访问网站的响应速度慢的根本原因;
使用CDN缓存后的网站的访问过程为:
1)用户向浏览器提供要访问的域名;
2)浏览器调用域名解析库对域名进行解析,由于CDN对域名解析过程进行了调整,所以解析函数库一般得到的是该域名对应的CNAME记录,为了得到实际IP地址,浏览器需要再次对获得的CNAME域名进行解析以得到实际IP地址;在此过程中,使用的全局负载均衡DNS解析,如根据地理位置信息解析对应的IP地址,使用户能就近访问;
3)此次解析得到的CDN缓存服务器的IP地址,浏览器在得到实际IP地址以后,向缓存服务器发出访问请求;
4)若请求文件并未修改,返回304(充当服务器的角色),若当前文件已经过期,则缓存服务器根据提供的要访问的域名,通过Cache内部专用DNS解析得到此域名的实际IP地址,再由缓存服务器向此实际IP地址提交访问请求;
5)缓存服务器从实际IP地址得到内容以后,一方面在本地进行保存,以备以后使用,二方面把获取的数据返回给客户端,完成数据服务过程;
6)客户端得到由缓存服务器返回的数据以后显示出来并完成整个浏览的数据请求过程;
四、cookie与session
-
cookie为本地缓存机制;
-
cookie:正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在 HTTP的响应头中添加一行特殊的指示以提示浏览器按照指示生成相应的cookie;用户每请求一次服务器数据,cookie则会随着这些请求发送到服务器,服务器脚本语言如PHP等能够处理cookie发送的数据,可以说是非常方便的,当然前端也是可以生成cookie的,用js对cookie的操作相当繁琐,浏览器只提供document.cookie这样一个对象,对cookie的赋值,获取都比较麻烦,而在PHP中,我们可以通过setcookie()来设置cookie,通过$_COOKIE这个超全局数组来获取cookie;
-
cookie的内容主要包括:名字,值,过期时间,路径和域,路径与域一起构成cookie的作用范围,路径和域就是对应的域名,a网站的cookie自然不能给b用,若不设置过期时间,则表示这个cookie的生命期为浏览器会话期间,关闭浏览器窗口,cookie就消失,这种生命期为浏览器会话期的cookie被称为会话cookie,会话cookie一般不存储在硬盘上而是保存在内存里,当然这种行为并不是规范规定的,若设置了过期时间,浏览器就会把cookie保存在硬盘上,关闭后再次打开浏览器,这些cookie仍然有效直到超过设定的过期时间,存储在硬盘上的cookie可以在不同的浏览器进程间共享,比如两个IE窗口,而对于保存在内存里的cookie,不同的浏览器有不同的处理方式;
-
session:是一种服务器端的机制,服务器使用一种类似于散列表的结构来保存信息,当程序需要为某个客户端的请求创建一个session标识(称为session id),如果已经包含则说明此前为此客户端创建过session,服务器就按照session id把这个session检索出来使用,检索不到会新建一个,如果客户端请求不包含session id,则为此客户端创建一个session并且生成一个与此session相关联的session id,session id的值应该是一个既不会重复,又不容易被找到规律以仿造的字符串,这个session id将被在本次响应中返回给客户端保存,同一客户端启动二次session_start的话,session_id是不一样的,保存这个session id的方式可以采用cookie,这样在交互过程中浏览器可以自动的按照规则把这个标识发送给服务器,一般这个cookie的名字都是类似于session id,但cookie可以被人为的禁止,则必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器,经常使用的一种技术叫做URL重写,就是把session id直接附加在URL路径的后面,比如:http://damonare.cn?sessionid=123456,还有一种技术叫做表单隐藏字段,就是服务器会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器;
-
cookie和session的区别:
1)cookie数据存放在客户的浏览器上,session数据存放在服务器上;
2)cookie不是很安全,别人可以分析存放在本地的cookie并进行欺骗,考虑到安全应当使用session,cookie是以明文形式存放在客户端的,安全性低,可以通过一个加密算法来进行加密后存放,session存放于服务器的内存中,所以安全性好
3)session会在一定时间内保存在服务器上,当访问增多,会比较占用服务器性能,考虑到减轻服务器性能方面,应当使用cookie;
4)单个cookie保存的数据不能超过4k,很多浏览器都限制在一个站点最多保存20个cookie,所以建议:将登录信息等重要信息存放为session,其他信息如果需要保留,可以放在cookie中;
5)cookie的生命周期是累计的,从创建时就开始计时,20分钟后,cookie生命周期结束;session的生命周期是间隔的,从创建时,开始计时如在20分钟,没有访问session,那么session生命周期被销毁,但是如果在20分钟内(如在第19分钟时)访问过session,那么将重新计算session的生命周期,关机会造成session生命周期的结束,但是对cookie没有影响;
6)访问范围:cookie为多个用户浏览器共享,session为一个用户浏览器独享; -
session为什么出现?
HTTP本身是无状态协议,这样就无法确定本次请求和上次请求是否是同一个人所发送的,如果要进行类似论坛登录的相关操作,就实现不了; -
为什么说session比cookie更安全?
真正的cookie存在于客户端硬盘上的一个文本文件,如果两者一样的话,只要cookie就好了,让客户端来分担服务器的负担,并且对于用户来说又是透明的,但实际上并不是;session的sessionID是放在cookie里的,要想攻破session的话,得分为两步:
1)首先要得到sessionID,攻破cookie后,要得到sessionID,sessionID是要有人登录,或者启动session_start才会有,无法确定什么时候会有人登录;
2)第二步是取有效sessionID,sessionID是加密的,第二次session_start的时候,前一次的sessionID就没有用了,session过期时sessionID也会失效,想在短时间内攻破加密的sessionID很难,session是针对某一次的通信而言,会话结束session也就随着消失了;
使session失效的方法:1)关闭tomcat;2)重启web应用;3)session时间到;4)无效的session;
五、token
- token为什么出现:首先session的存储是需要空间的,其次,session的传递一般都是通过cookie来传递的,或者URL重写的方式,而token在服务器是可以不需要存储用户的信息的,而token的传递方式也不限于cookie传递,当然token也是可以保存起来的;
- token的生成方式:浏览器第一次访问服务器,根据传过来的唯一标识userID,服务端会通过一些算法,如常用的HMAC-SHA256算法,然后加一个密钥,生成一个token,然后通过BASE64编码一下之后将这个token发送给客户端,客户端将token保存起来,下次请求时,带着token,服务器收到请求时,然后会用相同 的算法和密钥去验证token,如果通过,执行业务操作,不通过则返回不通过信息;
-
token和session的区别:token和session其实都是为了身份验证,session一般翻译为会话,而token更多的时候是翻译为令牌,session服务器会保存一份,可能保存到缓存,文件,数据库,同样session和token都是有过期时间一说,都需要去管理过期时间,其实token和session的问题是一种时间与空间的博弈问题,session是空间换时间,而token是时间换空间,两者的选择要看具体情况而定;
虽然确实都是“客户端记录,每次访问携带”,但token很容易设计为自包含的,也就是说,后端不需要记录什么东西,每次一个无状态请求,每次解密验证,每次当场得出合法/非法结论,这一切判断依据,除了固化在CS两端的一些逻辑之外,整个信息是自包含的,这才是真正的无状态;而sessionID,一般都是一段随机字符串,需要到后端去检索id的有效性,万一服务器重启导致内存里的session没了呢,万一redis服务器挂了呢?
方案session:我发给你一张身份证,但只是一张写着身体证号码的纸片,你每次来办事,我去后台查一下你的id是不是有效;
方案token:我发给你一张加密的身份证,以后你只要出示这张卡片,我就知道你一定是自己人;
session和token并不矛盾,作为身份认证token安全性比session好,因为每个请求都有签名还能防止监听以及重放攻击,而session就必须靠链路层来保障通讯安全了,如上所说,如果你需要实现有状态的会话,仍然可以增加session来在服务器端保存一些状态;
App通常用restful api跟server打交道,rest是stateless的,也就是app不需要像browser那样用cookie来保存session,因此用session token来标示自己就够了,session/state由api server的逻辑处理,如果你的后端不是stateless的rest api,那么你可能需要在app里保存session,可以在app里嵌入webkit,用一个隐藏的browser来管理cookie session;
session是一种http存储机制,目的是为无状态的http提供的持久机制,所谓session认证只是简单的把user信息存储到session里,因为sid的不可预测性,暂且认为是安全的,这是一种认证手段,而token如果指的是OAuth Token或类似的机制的话,提供的是认证和授权,认证是针对用户,授权是针对APP,其目的是让某APP有权访问某用户的信息,这里的token是唯一的,不可以转移到其它App上,也不可以转到其它用户上,转过来说session,它只提供一种简单的认证,即有此sid,即认为有此user的全部权利,是需要严格保密的,这个数据应该只保存在站方,不应该共享给其它网站或第三方App,所有简单来说,如果你的用户数据可能需要和第三方共享,或都允许第三方调用API接口,用token,如果永远只是自己的网站,自己的APP,用什么就无所谓了;
token就是令牌,比如你授权(登录)一个程序时,他就是个依据,判断你是否已经授权该软件;cookie就是写在客户端的一个txt文件,里面包括你登录信息之类的,这样你下次登录某个网站,就会自动调用cookie自动登录用户名,session和cookie差不多,只是session是写在服务器端的文件,只需要在客户端写入cookie文件,但是文件里是你的浏览器编号,session的状态是存储在服务器端,客户端只有sessionID,而token的状态是存储在客户端的;
session:每个人只需要保存自己的session id,而我需要保存所有人的session id ! 如果访问我的人多了, 就得由成千上万,甚至几十万个,这对我来说是一个巨大的开销 , 严重的限制了我的扩展能力, 比如说我用两个机器组成了一个集群, 小F通过机器A登录了系统, 那session id会保存在机器A上, 假设小F的下一次请求被转发到机器B怎么办? 机器B可没有小F的 session id啊,有时候我会采用一点小伎俩: session sticky , 就是让小F的请求一直粘连在机器A上, 但是这也不管用, 要是机器A挂掉了, 还得转到机器B去,那我只好做session 的复制了, 把session id 在两个机器之间搬来搬去, 快累死了;
屏幕快照 2018-08-19 下午6.39.51.png
token:如果我不保存这些session id , 我怎么验证客户端发给我的session id 的确是我生成的呢? 如果我不去验证,我都不知道他们是不是合法登录的用户, 那些不怀好意的家伙们就可以伪造session id , 为所欲为了,嗯,对了,关键点就是验证 !
比如说, 小F已经登录了系统, 我给他发一个令牌(token), 里边包含了小F的 user id, 下一次小F 再次通过Http 请求访问我的时候, 把这个token 通过Http header 带过来不就可以了,不过这和session id没有本质区别啊, 任何人都可以可以伪造, 所以我得想点儿办法, 让别人伪造不了,那就对数据做一个签名吧, 比如说我用HMAC-SHA256 算法,加上一个只有我才知道的密钥, 对数据做一个签名, 把这个签名和数据一起作为token , 由于密钥别人不知道, 就无法伪造token了;
这个token 我不保存, 当小F把这个token 给我发过来的时候,我再用同样的HMAC-SHA256 算法和同样的密钥,对数据再计算一次签名, 和token 中的签名做个比较, 如果相同, 我就知道小F已经登录过了,并且可以直接取到小F的user id , 如果不相同, 数据部分肯定被人篡改过, 我就告诉发送者: 对不起,没有认证;
Token 中的数据是明文保存的(虽然我会用做下编码, 但那不是加密), 还是可以被别人看到的, 所以我不能在其中保存像密码这样的敏感信息,当然, 如果一个人的token 被别人偷走了, 那我也没办法, 我也会认为小偷就是合法用户, 这其实和一个人的session id 被别人偷走是一样的,这样一来, 我就不保存session id 了, 我只是生成token , 然后验证token , 我用我的CPU计算时间获取了我的session 存储空间 !
参考:https://blog.csdn.net/jek123456/article/details/64923545
六、sessionStorage和Localstorage
- Localstorage:持久化的存储方式,如果不手动清除,数据就永远不会过期,采用key-value的方式存储数据,底层数据接口是sqlite,按域名将数据分别保存到对应数据库文件里,它能保存更大的数据,同时保存的数据不会再发送给服务器,避免带宽浪费;
- sessionStorage:和服务器端使用的session类似,是一种会话级别的缓存,关闭浏览器数据会被清除,不过有点特别的是它的作用域是窗口级别的,也就是说不同窗口间的sessionStorage数据不能共享;
- sessionStorage和Localstorage的区别:sessionStorage用于本地存储一个会话(session)中的一个数据,这时数据只有在同一个会话中的页面才能访问并且当会话结束后数据也随之销毁,因此sessionStorage不是一种持久化的本地存储,仅仅是会话级别的存储,当用户关闭浏览器窗口时,数据立马会被删除;localStorage用于持久化的本地存储,除非主动删除数据,否则数据是永远不会过期的;
- Cookie 、sessionStorage和Localstorage的区别:
1)cookie兼容所有的浏览器,是H5提供的storage存储方式,Document.cookie,Window.localstorage,Window.sessionstorage;cookie数据始终在同源的http请求中携带(即使不需要),即cookie在浏览器和服务器间来回传递,因此cookie不能太大,而sessionStorage和localStorage不会自动把数据发送给服务器,仅在本地保存;
2)存储大小限制也不同,cookie数据不能超过4k,因为每次http请求都会携带cookie,所以cookie只适合保存很小的数据,如会话标识,不能用于接受大文件或邮件那样的大数据;sessionStorage和localStorage虽然也有存储大小的限制,但比cookie大得多,可以达到5M或更大;
3)数据有效期不同:sessionStorage仅在当前浏览器窗口关闭前有效,自然也就不可能持久保持,localStorage始终有效,窗口或浏览器关闭也一直保存,因此用作持久数据,cookie只在设置的cookie过期时间之前一直有效,即使窗口或浏览器关闭;
4)作用域不同:sessionStorage不在不同的浏览器窗口中共享,即使是同一个页面;localStorage在所有同源窗口中都是共享的,cookie也是在所有同源窗口中都是共享的;
七、cookie和localStorage的区别
- cookie:指某些网站为了辨别用户身份而存储在用户本地终端上的数据;
1)内存cookie:由浏览器维护,保存在内存中,浏览器关闭就消失,存在时间短;
2)硬盘cookie:保存在硬盘中,除非用户手工清朝或到了过期时间,一般不会删除;
3)用途:服务器可以设置或读取cookie中包含的信息,借此维护用户跟服务器会话中的状态,因为HTTP协议是无状态的,就是说服务器不知道用户上一次做了什么,为实现交互,就用cookie来记录;
比如,网上购物,用户选购了一个商品,服务器在向用户发送网页时还发送一段记录商品信息的cookie,当用户访问另一个页面,浏览器会把cookie发送给服务器端,于是服务器就知道用户选购了什么;
登录网站勾选“下次自动登录”,那么下次访问就不用再输入密码等信息,这是因为在第一次登录时,如果勾选了自动登录,那么服务器发送包含登录凭据(用户加密码的某种加密形式)的cookie到用户的硬盘上,第二次登录时,浏览器就会发送该cookie,服务器验证凭据,就不用再次输入密码等;
5)Web Storage是为了更大容量存储设计的,Cookie的大小是受限的,并且每次请求一个新的页面的时候Cookie都会被发送过去,这样无形中浪费了带宽,另外cookie还需要指定作用域,不可以跨域调用;cookie数据始终在同源的http请求中携带(即使不需要),即cookie在浏览器和服务器间来回传递,而sessionStorage和localStorage不会自动把数据发给服务器,仅在本地保存,cookie数据还有路径(path)的概念,可以限制cookie只属于某个路径下;
6)Web Storage拥有setItem,getItem,removeItem,clear等方法,不像cookie需要前端开发者自己封装setCookie,getCookie;
7)缺陷:cookie会被附加到每个http请求中,无形增加了流量;
http请求中的cookie是明文传递,安全性成问题(https不会);
cookie大小限制在4kb,对于复杂的存储需求是不够用的;
cookie会过期
8)sessionStorage与页面 js 数据对象的区别:页面中一般的 js 对象或数据的生存期是仅在当前页面有效,因此刷新页面或转到另一页面这样的重新加载页面的情况,数据就不存在了,而sessionStorage 只要同源的同窗口(或tab)中,刷新页面或进入同源的不同页面,数据始终存在。也就是说只要这个浏览器窗口没有关闭,加载新页面或重新加载,数据仍然存在; - Web Storage 有两种机制
sessionStorage 为每一个给定的源维持一个独立的存储区域,该存储区域在页面会话期间可用(浏览器是打开状态,包括页面重载和恢复);
localStorage 同上,但浏览器关闭之后,重新打开数据还是存在;
WebStorage 支持事件通知机制,可以将数据更新的通知发送给监听者,Web Storage 的 api 接口使用更方便;
八、WebStorage和cookie的操作异同
- cookie
// 保存cookie
var dataCookie='110';
document.cookie = 'token' + "=" +dataCookie;
// 获取指定名称的cookie
function getCookie(name) { //获取指定名称的cookie值
// (^| )name=([^;]*)(;|$),match[0]为与整个正则表达式匹配的字符串,match[i]为正则表达式捕获数组相匹配的数组;
var arr = document.cookie.match(new RegExp("(^| )"+name+"=([^;]*)(;|$)"));
if(arr != null) {
console.log(arr);
return unescape(arr[2]);
}
return null;
}
var cookieData=getCookie('token'); //cookie赋值给变量。
- webStorage
var name='sessionData';
var num=120;
sessionStorage.setItem(name,num);//存储数据
sessionStorage.setItem('value2',119);
let dataAll=sessionStorage.valueOf();//获取全部数据
console.log(dataAll,'获取全部数据');
var dataSession=sessionStorage.getItem(name);//获取指定键名数据
var dataSession2=sessionStorage.sessionData;//sessionStorage是js对象,也可以使用key的方式来获取值
console.log(dataSession,dataSession2,'获取指定键名数据');
sessionStorage.removeItem(name); //删除指定键名数据
console.log(dataAll,'获取全部数据1');
sessionStorage.clear();//清空缓存数据:localStorage.clear();
console.log(dataAll,'获取全部数据2');
三者的异同比较:
生命周期:
cookie:可设置失效时间,没有设置的话,默认是关闭浏览器后失效
localStorage:除非被手动清除,否则将会永久保存。
sessionStorage: 仅在当前网页会话下有效,关闭页面或浏览器后就会被清除。
存放数据大小:
cookie:4KB左右
localStorage和sessionStorage:可以保存5MB的信息。
http请求:
cookie:每次都会携带在HTTP头中,如果使用cookie保存过多数据会带来性能问题
localStorage和sessionStorage:仅在客户端(即浏览器)中保存,不参与和服务器的通信
易用性:
cookie:需要程序员自己封装,源生的Cookie接口不友好
localStorage和sessionStorage:源生接口可以接受,亦可再次封装来对Object和Array有更好的支持
应用场景:
从安全性来说,因为每次http请求都会携带cookie信息,这样无形中浪费了带宽,所以cookie应该尽可能少的使用,另外cookie还需要指定作用域,不可以跨域调用,限制比较多。但是用来识别用户登录来说,cookie还是比stprage更好用的。其他情况下,可以使用storage,就用storage。
storage在存储数据的大小上面秒杀了cookie,现在基本上很少使用cookie了,因为更大总是更好的,哈哈哈你们懂得。
localStorage和sessionStorage唯一的差别一个是永久保存在浏览器里面,一个是关闭网页就清除了信息。localStorage可以用来夸页面传递参数,sessionStorage用来保存一些临时的数据,防止用户刷新页面之后丢失了一些参数。
浏览器支持情况:
localStorage和sessionStorage是html5才应用的新特性,可能有些浏览器并不支持,这里要注意。
数据存放处
Application<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta name="viewport"
content="width=device-width, user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0">
<meta http-equiv="X-UA-Compatible" content="ie=edge">
<title>本地存储</title>
</head>
<body>
<div>打开控制台查看console</div>
<p><a target="_blank" href="https://github.com/OBKoro1/article-demo/blob/master/2017/cookieStorage/index.html">查看代码文件</a></p>
<script>
cookieFn();
strogeFn();
function cookieFn() {
var dataCookie='110';
document.cookie = 'token' + "=" +dataCookie;//直接设置cookie
function getCookie(name) { //获取指定名称的cookie值
// (^| )name=([^;]*)(;|$),match[0]为与整个正则表达式匹配的字符串,match[i]为正则表达式捕获数组相匹配的数组;
var arr = document.cookie.match(new RegExp("(^| )"+name+"=([^;]*)(;|$)"));
if(arr != null) {
console.log(arr,'正则表达式捕获数组相匹配的数组');
return unescape(arr[2]);
}
return null;
}
var cookieData=getCookie('token');
console.log(cookieData,'获取指定名称的cookie值');
function setTime() {
//存储cookie值并且设置cookie过期时间
var date=new Date();
var expiresDays=10;//设置十天过期
date.setTime(date.getTime()+expiresDays*24*3600*1000);
document.cookie="userId=828; expires="+date.toGMTString();
console.log(document.cookie,'存储cookie值并且设置cookie过期时间');
}
setTime();
function delCookie(cookieName1) {
//删除cookie
var date2=new Date();
date2.setTime(date2.getTime()-10001);//把时间设置为过去的时间,会自动删除
document.cookie= cookieName1+"=v; expires="+date2.toGMTString();
console.log(document.cookie,'删除cookie');
}
delCookie('userId');
}
function strogeFn() {
var name='sessionData';
var num=120;
sessionStorage.setItem(name,num);//存储数据
sessionStorage.setItem('value2',119);
let dataAll=sessionStorage.valueOf();//获取全部数据
console.log(dataAll,'获取全部数据');
var dataSession=sessionStorage.getItem(name);//获取指定键名数据
var dataSession2=sessionStorage.sessionData;//sessionStorage是js对象,也可以使用key的方式来获取值
console.log(dataSession,dataSession2,'获取指定键名数据');
sessionStorage.removeItem(name); //删除指定键名数据
console.log(dataAll,'获取全部数据1');
sessionStorage.clear();//清空缓存数据:localStorage.clear();
console.log(dataAll,'获取全部数据2');
}
</script>
</body>
</html>