5分钟彻底搞懂Session,Cookie,Token

2022-10-11 21:03:10 169 0
魁首哥

【写在最前】
我们在平时的编程学习中,经常会接触到“ Session ,Token”这两个概念;
但是很多小白傻傻分不清楚“他们之间的区别、联系、适用场景 ,甚至是在查阅了很多资料之后仍然是云山雾罩。
通过本文知识,让我们花5分钟时间彻底搞懂它,相信聪明的你,看完一定会有收获!

# 为什么要引入会话管理?

首先,HTTP协议是一个 “无状态” 的协议,所以服务器并不能自动区分出前后两次请求是否来自同一个客户端(或用户)。
但是,很多业务场景,必须要区分出来访者的身份。
因此,服务器端必须要建立一套会话管理机制,来 解决“http协议无状态的问题”

# Session

定义:

是指在服务器端存储(并区分)当前访问客户端(非用户哦)会话的一种机制。
流程:
1)当客户端第一次请求服务器时,服务器端会生成一个sessionid(一般是文件形式存储)作为该客户端的唯一标识,并通过在响应头中(ResponseHeaders)下发 Set- cookie ,通知浏览器需要保存该标识。
2)当客户端第N次(N>=2)请求服务器时,会在请求头中( Request Headers)自动携带这个Cookie:sessionid=xx
3)当服务器再次接收客户端请求时,会先去请求头中检查是否存在 Cookie : session id=xx,如果没有Cookie或者 Cookie过期,就提示用户 ”必须登录后才能访问“ ,从而实现(并区分)有状态的会话管理。

通过以上知识,我们能够清楚的知道以下4个经典面试题的答案:

# 集群会话管理

众所周知,单个服务器的负载上限是一个固定值。

传统Session机制只适合单机版应用, 一旦项目用户数量达到一定规模,服务器集群改造方案就会变得刻不容缓

集群环境下的会话管理, 目前业界有两种主流解决方案:

方案1:提供session共享机制
原理: 不再用文件存储session,而是用第三方中间件(比如 redis )来管理session
优点: 项目改造成本较小(因为代码风格跟传统是一脉相承)
缺点: 依赖于集中式中间件,一旦中间件本身性能出问题,就会立刻导致系统瓶颈。

方案2:token令牌方案
原理:
1)token 由服务器本身根据算法生成后下发给客户端,服务器端无需额外存储。

2)客户端请求服务器时,在请求头中追加携带该token

3)服务器端对token进行验签,从而决定本次访问是拒绝还是放行。

优点: 不依赖任何集中式中间件(完全依赖服务器算力解决)
缺点: token一旦下发,有效期就已经确定,不能像Session一样可以在服务器端随时中止会话。

# cookie

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数据;

【全文完】
—————————————-
十年技术沉淀,只做原创文章;
及时关注作者,成就大牛之路!

收藏
分享
海报
0 条评论
169
上一篇:菜做咸了怎么办(吃咸了怎么促进盐排出) 下一篇:PHP的password_hash函数封装及应用(MD5、SHA1的升级版本)

本站已关闭游客评论,请登录或者注册后再评论吧~

忘记密码?

图形验证码