我们在平时的编程学习中,经常会接触到“ Session,Token”这两个概念;
但是很多小白傻傻分不清楚“他们之间的区别、联系、适用场景 ,甚至是在查阅了很多资料之后仍然是云山雾罩。
通过本文知识,让我们花5分钟时间彻底搞懂它,相信聪明的你,看完一定会有收获!
首先,HTTP协议是一个“无状态”的协议,所以服务器并不能自动区分出前后两次请求是否来自同一个客户端(或用户)。
但是,很多业务场景,必须要区分出来访者的身份。
因此,服务器端必须要建立一套会话管理机制,来解决“http协议无状态的问题”。
定义:
是指在服务器端存储(并区分)当前访问客户端(非用户哦)会话的一种机制。
流程:
1)当客户端第一次请求服务器时,服务器端会生成一个sessionid(一般是文件形式存储)作为该客户端的唯一标识,并通过在响应头中(ResponseHeaders)下发Set-Cookie,通知浏览器需要保存该标识。
2)当客户端第N次(N>=2)请求服务器时,会在请求头中(RequestHeaders)自动携带这个Cookie:sessionid=xx
3)当服务器再次接收客户端请求时,会先去请求头中检查是否存在Cookie:sessionid=xx,如果没有Cookie或者 Cookie过期,就提示用户”必须登录后才能访问“,从而实现(并区分)有状态的会话管理。
通过以上知识,我们能够清楚的知道以下4个经典面试题的答案:
1)如果浏览器cookie被禁用,那么session机制也会同时失效;
2)如果相同的用户账号,利用不同浏览器登录系统,那么Session并不相同
3)如果关闭浏览器,Session会话并不会立即关闭(因为只有当session在服务器端过期时,服务器才会去删除session文件本身)
4)如果web服务器做了多台负载均衡机制,那么当某个请求被路由到另一台业务均衡服务器时,Session也会丢失。
众所周知,单个服务器的负载上限是一个固定值。
传统Session机制只适合单机版应用,一旦项目用户数量达到一定规模,服务器集群改造方案就会变得刻不容缓。
集群环境下的会话管理,目前业界有两种主流解决方案:
方案1:提供session共享机制
原理:不再用文件存储session,而是用第三方中间件(比如redis)来管理session
优点:项目改造成本较小(因为代码风格跟传统是一脉相承)
缺点:依赖于集中式中间件,一旦中间件本身性能出问题,就会立刻导致系统瓶颈。
方案2:token令牌方案
原理:
1)token 由服务器本身根据算法生成后下发给客户端,服务器端无需额外存储。
2)客户端请求服务器时,在请求头中追加携带该token
3)服务器端对token进行验签,从而决定本次访问是拒绝还是放行。
优点:不依赖任何集中式中间件(完全依赖服务器算力解决)
缺点:token一旦下发,有效期就已经确定,不能像Session一样可以在服务器端随时中止会话。
1、Cookie 的两个作用( 适用场景):
1)记录用户身份
用户A第一次访问a网站,a网站会返回给用户A一个sessionid,这样A每次访问a网站就会带上这个会话
2)记录用户历史
假设a是一个购物网站,用户B把B1,B2商品加入购物车,过了几天后,B再次打开网站,发现商品仍然会在购物车中(因为浏览器不会轻易删除cookie)
2、cookie 的属性
Cookie 有很多配置属性,比较关键的有3个:
1)Path:
是指服务器资源路径(而不是指客户端存放的路径!!!)
2)HttpOnly
在cookie上设置HttpOnly标识,浏览器就会知道该cookie只能由服务器获取,而客户端本身js脚本的访问都会被禁止,从而提升系统安全性。
3)Secure
在cookie上设置Secure标识,那么就只有在使用 https 协议的时候自动携带 Cookie。从而提升系统安全性。
3、cookie 的限制
cookie是由浏览器管理的,很多浏览器为了自身性能会添加一些限制:
1)一般情况下,单个站点,最多允许保存20个cookie;
2)一般情况下,单个cookie,最多允许保存4K数据;
【全文完】