一文搞懂Cookie+Session，Redis+Token，JWT三者的区别

一文搞懂Cookie+Session，Redis+Token，JWT三者的区别

本文图片部分来自网络

一、基于Cookie+Seesion传统的认证机制

1.认证流程

http是无状态协议，比如客户端发送了提交一个用户名和密码的请求进行用户认证，那么当页面关闭后，下一次用户还得再发送一次请求来进行用户认证。

因为http协议是不知道是哪个用户发送的请求，所以只能在服务器上存储一份用户的信息（Session），这份登录信息会在服务器响应的时候发送一个（Sessionid）保存到Cookie中，下次客户端发送请求的时候把这个Sessionid放到Cookie中带给服务器，就可以让服务器识别出我们的请求来自于哪个用户了，这就是传统的基于Cookie+Session的认证机制

2.暴露问题

2.1服务器开销增大

因为每一个访问请求都会创建一个Session对象，如果当用户数量过多的时候服务器就会放过多的Session，导致服务器开销增大

2.2负载均衡问题

当用户认证成功后，Session对象还保存在服务器内存中，这意味着用户下次的请求必须还是在这一台服务器上，这样才能拿到授权的资源。比如说某个客户端有可能第一次认证的时候session存在了服务器1，但是第二次session被分配到了服务器2，就会找不到session导致后续功能失效。

当然这个问题的解决方法有很多：

1.session复制，每次复制session到每一个服务器中。数据冗余。

2.使用NoSQL数据库，第一次请求服务器的时候把session存放在NoSQL数据库中，以后其他服务器访问的时候，先去NoSQL数据库中寻找是否有session。完全在内存中，速度快，数据结构简单，减少了CPU的压力（但是有个问题NoSQL数据库也是放在服务器上的，如果NoSQL数据库挂掉了，那么所有的用户都需要重新认证，这样并不是很完美）

2.3CSRF（Cross Site Request Forgery）跨站域请求伪造攻击

因为Sessionid是放在Cookie中的，如果Cookie被截获，用户就很容易遭到CSRF攻击

比如：

如果你访问了一个别有用心或病毒网站，这个网站可以在网页源代码中插入js代码，使用js代码给其他服务器发送请求（比如银行的转账请求）。那么因为在发送请求的时候，浏览器会自动的把cookie发送