Token/Cookie/Session使用场景区别

        在Web开发领域，相信大家对于Cookie和Session都很熟悉，Cookie和Session都是会话保持技术的解决方案。随着技术的发展，Token机制出现在我们面前，不过很多开发者对于Token和Cookie、Session的区别及使用场景分辨不清。

Cookie和Session的用途
         要知道我们访问网站都是通过HTTP协议或HTTPS协议来完成的，HTTP协议它本身是无状态的协议（即：服务器无法分辨哪些请求是来源于同个客户）。而业务层面会涉及到客户端与服务器端的交互（同网站下多个页面间能共享数据），此时服务器端必须要保持会话状态，这样才能进行用户身份的鉴别。
        由于HTTP无状态的特性，如果要实话客户端和服务器端的会话保持，那就需要其它机制来实现，于是Cookie和Session应运而生。

通常情况下，Session和Cookie是搭配在一起使用的。

Token是什么
        上面说到的Session和Cookie机制来保持会话，会存在一个问题：客户端浏览器只要保存自己的SessionID即可，而服务器却要保存所有用户的Session信息，这对于服务器来说开销较大，而且不利用服务器的扩展（比如服务器集群时，Session如何同步存储就是个问题）！
        于是有人思考，如果把Session信息让客户端来保管而且无法伪造不就可以解决这个问题了？进而有了Token机制。
Token俗称为“令牌”，它的构成是：

uid：用户唯一身份标识

timestamp：当前时间戳

sign：签名字符串，防止第三方伪造数据；签名密钥是存储在服务器端的，其它人无法知道

其它附加参数。

Token机制下的认证流程
Token机制其实和Cookie机制极其相似，主要有以下流程：
1、用户登录进行身份认证，认证成功后服务器端生成Token返回给客户端；
2、客户端接收到Token后保存在客户端（可保存在Cookie、LocalStorage、SessionStorage中）；
3、客户端再次请求服务器端时，将Token作为请求头放入Headers中；
4、服务器端接收请求头中的Token，将用户参数按照既定规则再进行一次签名，两次签名若一致则认为成功，反之数据存在篡改请求失败。

（生成签名示例图）

（验证签名示例图）

Token与Cookie+Session的区别
        Cookie其实也充当的是令牌作用，但它是“有状态”的；而Token令牌是无状态的，更利于分布式部署。