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

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

文章插图
【5分钟彻底搞懂Session,Cookie,Token】
# 为什么要引入会话管理？首先，HTTP协议是一个“无状态”的协议，所以服务器并不能自动区分出前后两次请求是否来自同一个客户端（或用户）。
但是，很多业务场景，必须要区分出来访者的身份。
因此，服务器端必须要建立一套会话管理机制，来解决“http协议无状态的问题” 。
# Session定义：
是指在服务器端存储（并区分）当前访问客户端（非用户哦）会话的一种机制。
流程：
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一样可以在服务器端随时中止会话。

# 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数据；

【全文完】