Cookie、Session、Token概念和应用场景

HTTP协议是一种无状态协议。然而当用户访问服务器资源时，都需要判断你是谁，你有没有操作权限。这就需要一种会话状态维护机制。这时就设计了一套cookie、session、token用于状态维护。

Cookie

场景：会话状态由客户端维护

例如你的身份信息（例如：账号和密码）存在客户端，每次请求时一并发送至服务器；根据你的身份返回响应信息。

步骤：

1，客户端发起访问请求；
2，服务端生成cookie，并发送给客户端；
3，浏览器保存返回的cookie数据；
4，下面每次请求，浏览器都会将 cookie数据连同请求一并发向服务器。

Cookie缺点

cookie大小不能超过4K，且受到浏览器本身对cookie个数限制，大约不超过50个。
如果将大量用户数据存在cookie中，尤其是账号、银行卡号、密码等，存在被截取和篡改安全隐患。为了解决这些问题，提出session机制。

Session

场景：会话状态由服务端控制

session是一种服务端机制，请求时由服务端存储会话状态，解决了cookie中大小限制和敏感数据的安全性问题。session可以存储在内存或者数据库中。

步骤：

1.登录，用户提交用户名和密码发送HTTP请求。
2.服务端验证用户发来的用户名密码。如果正确，则生成一个session。返回一个sessionid设置到响应cookie中，例如jsessionid=222212122111;
3.用户收到HTTP响应后，响应头cookie中的sessionid存储到浏览器中。在此后的请求中发送该Cookie给服务器；
4.服务端收到此后的HTTP请求后，首先验证sessionid，如果通过，根据该id从服务器中取出对应的用户对象， 执行请求的业务逻辑。

Session缺点

因为有session的数据存储在服务端，当大用户并发的情况下，开销会很大；同时如果在分布式架构下，就存储session共享的问题，需要做好共享和控制设计开发工作。为了考虑跨应用访问，就有了Token令牌机制。

Token

token认证方式与session类似。为了防止客户端伪造session id。token采用时间戳+签名的方式一起作为token发送到服务端，服务端验证签名数据，通过则可以访问，验证失败，则拒绝请求。

场景：跨平台应用（单点登录）

例如某平台集成QQ登录，登录时只需要跳转至QQ平台，登录QQ账号后，将QQ对应该平台该用户的token值返回（有的也可以返回一些其他用户数据，例如名称，QQ号等），平台根据QQ返回的token和数据生成对应的账户。

步骤：

1.用户登录请求验证，成功后返回token给客户端；
2.客户端收到token数据后保存在客户端；
3.客户端每次访问请求时，一并携带token到服务器端；
4.服务端校验成功，返回请求数据。

总结

cookie：保存在客户端浏览器种，有大小限制，大小不能超过4K，且受到浏览器本身对cookie个数限制，大约不超过50个，有时效和状态限制。
session：保存在服务端中，可以存储在内存或者数据，分布式、跨系统不好实现。
Token：Token保存在客户端任何地方，适用于分布式部署。