前言

最近写的项目是和用户权限与认证有关，所以学习了很多有关 Cookie、Session 以及 Token 的相关知识，在这里做一个梳理。本文包括基础概念、区别与联系。

Session

基础概念

“会话控制”。Session 对象存储特定用户会话所需的属性及配置信息于服务器中。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失。其实现方式有很多种，JDK有自己的实现，大家也可以根据不同的业务场景设计不同数据结构的session。

抽象理解

可以抽象理解为，session就是在服务器的内存中放了一个盒子，可以在这个盒子中存放浏览器需要在页面跳转中持续保存的信息。

问题

服务器是如何辨析不同请求属于哪些的session呢？

在服务器中，不同的 session 具有不同的 sessionid。在服务器发送响应报文的同时，将浏览器请求的 sessionid 放在 cookie 或 url 中进行回传。之后，浏览器每次请求时都要带着 sessionid，服务器通过 sessionid 来进行请求和 session 的配对。 所以说，说浏览器或主机拥有自己的 session，这个说法是不准确的，因为只要拿到了 sessionid，就可以在服务器访问相应的 session。

Cookie

基础概念

Cookie，有时也用其复数形式 Cookies。类型为“小型文本文件”，是某些网站为了辨别用户身份，进行Session跟踪而储存在用户本地终端上的数据（通常经过加密），由用户客户端计算机暂时或永久保存的信息。

抽象理解

和 session 差不多，可以抽象理解为，cookie就是在客户端本地放了一个小盒子，来存放服务器相应的信息。

问题

cookie 一般都存放什么信息？

因为 cookie 是存放在本地的小型文本文件，非常容易被篡改。所以一般放在 cookie 中的信息都是被加密过的 “id” 型信息，或者非敏感型的信息。

Token

基础概念

token的意思是“令牌”，是用户身份的验证方式，最简单的token组成：uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。

抽象理解

与前两者不同，token 可以理解为放在盒子里的信息。就像是现在如果我们要进入一栋大楼，根据身份的不同，访客所能访问的楼层也就不同。所以在进入大楼前，每一个访客都需要办理身份认证，这个身份认证就可以理解为 token。

问题

我们什么时候会需要 token ？

一般在做后台管理系统时候，token 的运用比较多。因为后台管理系统涉及到很多角色的划分，不同的角色所能访问资源的范围也不同。因此客户端每次访问服务器时，服务器都会验证 token 的有效性，以此来检验用户的登陆状态。

区别与联系

Cookie 与 Session

它们的区别其实很明显，cookie是存放在客户端本地的 “盒子”，session是存放在服务器的 “盒子”，本质都是用来记录用户的相关信息，来保证会话的一个连续性。在上面的叙述中也不难看到，cookie 与 session 是可以一起使用的，在客户端用 cookie 来记录 sessionid（如果浏览器支持的话），在服务器端用 session 来存储用户的信息或登陆状态。

Session 与 Token

如果 session 与 token 分别使用的话，token 相较与 session 可以用效率换取更多的空间，session 则是由于不需要解码，所以是用空间换取更多的效率。

使用 Token 进行用户认证时，服务器是不需要一直保存用户会话状态的。因为每一个客户端请求都会在协议头或其他地方带上 token，服务器拿到 token 后解码获取相关信息。这个流程是怎样的，感兴趣的同学可以翻一下我之前的文章。

使用 Session 时，显而易见速度是块于 token 的，但也可能会因为保持的客户端会话过多而导致内存不足。

扩展

实际上，目前越来越流行的做法是，session 与 token 组合使用，并且从使用之前 JDK 自有的 session，转换为 redis 这样的 nosql 缓存。如此一来，在业务上使用的数据结构可以更贴合场景，在技术上扩展性和性能也得到了提升。

参考文章

https://blog.csdn.net/qq_1290259791/article/details/81193914