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

我们在平时的编程学习中，经常会接触到“ Session,Token”这两个概念；

但是很多小白傻傻分不清楚“他们之间的区别、联系、适用场景 ，甚至是在查阅了很多资料之后仍然是云山雾罩。

通过本文知识，让我们花5分钟时间彻底搞懂它，相信聪明的你，看完一定会有收获！

为什么要引入会话管理？

首先，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：

是指服务器资源路径（而不是指客户端存放的路径！！！）

注：发送请求时，如果访问子路径，会自动携带父路径的Cookie，而访问父路径，并不会自动携带子路径的Cookie

2）HttpOnly

在cookie上设置HttpOnly标识，浏览器就会知道该cookie只能由服务器获取，而客户端本身js脚本的访问都会被禁止，从而提升系统安全性。

3）Secure

在cookie上设置Secure标识，那么就只有在使用 https 协议的时候自动携带 Cookie。从而提升系统安全性。

3、cookie 的限制

cookie是由浏览器管理的，很多浏览器为了自身性能会添加一些限制：

1）一般情况下，单个站点，最多允许保存20个cookie；

2）一般情况下，单个cookie，最多允许保存4K数据；