Cookie、Session和Token

Client首次访问Server输入账户信息认证成功后，Server会产生相关session及session-id。然后：

1）Server通过http的set-cookie头部告知Client后续请求通过该session-id识别身份和状态

2）Client通过http的cookie头部传递session-id到Server

3）Server收到请求后提取到session-id后查询session存储位置以确定身份

高：

1）高并发业务系统意味着Server需要读写大量的session，给Server增加了很大的压力

2）生产系统一般都是集群部署且前置负载均衡，如果一个用户的多次访问被调度到不同服务器节点则session功能失效

3）为了解决问题2，需要实现session复制的功能，难度较大且浪费Server存储资源

4）为了解决问题3，现在一般都将session存储在Redis，不论负载均衡调度到哪个节点都需要到Redis服务器查询一遍再返回，一定程度上增加了http访问的耗时

5）因为Redis的高速查询都是在内存中进行，为了避免session这么重要的数据出现单点故障，一般也都需要Redis服务器集群部署，技术难度大成本高

 服务端：

1）生成Token存在数据库

2）生成Token存在Redis

客户端：

JWT机制

A）如果存储在服务端：

工作方式跟Session一致

B）如果存储在客户端：

Client首次访问Server输入账户信息认证成功后，Server会产生token。然后：

1）Server通过http的头部告知Client后续请求通过该token识别身份和状态

2）Client通过http的头部传递token到Server

3）Server收到请求后提取到token后使用密钥解密token以确定身份

A）如果存储在服务端，难度跟session一致，高（详见session的分析）：

B）如果存储在客户端，则一般是使用JWT生成且只需要Server使用密钥解密即可，难度：低

//（Tips：JWT这种方式最大的不足就是一旦给Client发布了token就对其完全失去了控制，不适用的典型场景就是：难以主动封禁个别恶意用户）