4.Cookie,Session,Token,JWT(Json Web Token)本质
从无状态到有状态会话机制的过程发展史，共经历4个阶段：
（1）之前，Web 基本上就是文档的浏览而已， 既然是浏览，作为服务器， 不需要记录谁在某一段时间里都浏览了什么文档，
每次请求都是一个新的HTTP协议， 就是请求加响应，每个请求对我来说都是全新的；
（2）随着交互式Web应用的兴起（在线购物网站，需要登录的网站等等），就面临一个问题，那就是要管理会话，
必须记住哪些人登录系统， 哪些人往自己的购物车中放商品，想出的办法就是给大家发一个会话标识(session id),
说白了就是一个随机的字串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来，
这样我就能区分开谁是谁了；
（3）这时就产生了Cookie，Session；
（4）使用Cookie,虽然信息保存在客户端但是安全性不高，并且有大小限制；
（5）使用Session，信息保存在服务端，但任然依耐客户端存储sessionId，并且访问量过大，对服务器有压力；
（6）由于前两种的缺点，出现了Token，是一种无状态的，不将用户信息存在服务器或Session中
4.1.Cookie：
（1）是一个非常具体的东西，仅仅是浏览器实现的一种数据存储功能
（2）服务器生成，发送给浏览器，浏览器把cookie以k-v形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该cookie发送给服务器
（3）存在客户端上的，所以浏览器加入了一些限制确保cookie不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的cookie数量是有限的
4.2.Session：
（1）服务器使用session把用户的信息临时保存在了服务器上，用户离开网站后session会被销毁
（2）服务器就要给每个客户端分配不同的“身份标识”–sessionId
（3）客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了
（4）对于浏览器客户端，大家都默认采用 cookie 的方式
4.3.Token:
（1）身份验证是无状态的
（2）验证成功后，服务端向客户端返回一个签名的token
（3）客户端储存token,并且每次用于每次发送请求
（4）服务端验证token并返回数据（使用拦截器或者过滤器验证）
（5）token应该在HTTP的头部发送从而保证了Http请求无状态
4.4.JWT（Json Web Token）
（1）就是一个加密的字符串，作为验证信息在计算机之间传
（2）是实现Token令牌的一种技术（标准的用法是用JSON Web Tokens生成令牌）
（3）无状态的JWT:包含会话数据的JWT令牌，将信息直接编码到令牌中
（4）有状态的JWT:仅包含会话的引用或ID的JWT令牌,会话数据存储在服务器端
（5）会话令牌/ cookie：标准（可选签名）会话ID，会话数据存储在服务器端
Token和JWT有个致命缺陷：
1. JWT使用起来虽然简单方便，但它存在一个设计缺陷，即服务端无法主动注销token，所以jwt在安全性上不及session；
2.JWT这个缺陷决定了它更适合用在一次性token验证场景中，即token只使用一次就立即废弃掉，比如第三方登录授权。