前言
1.基础知识
- 什么是认证：就是登录，认出用户是谁，判断当前用户的身份是否合法
- 为什么需要认证：对系统资源进行访问控制
2.为什么需要会话
HTTP请求是无状态的，用户向服务端发起多个请求，服务端并不会知道这多次请求都是来自同一用户，这个就是无状态
因为HTTP1.1是无状态的，多个请求之间独立，一个系统并不知道你以前是否登录过，但是如果你登陆了，后面又不知道你是否登录了，这很明显不合理，为了保持登录状态，所以需要会话
会话的就是保存用户的登录状态，由于不可能长期保持登录会话状态，所以会话是有时间限制的一般，如果超时了会导致会话失效，用户需要重新登陆来维持新的会话
3.解决方案
4.Cookie+Session
核心概念
Cookie
- 基本概念：存在浏览器端的一块空间，k-v格式
- 缺点：
- 安全风险：有被篡改的风险，可能被窃取或重放，不能存储命啊你西南西
- 容量和长度限制：4KB
- 可用限制：用户可能禁用
Session
- 基本概念：后端一块存储空间，一般也是k-v格式，k是SessionId，v是用户信息
- 优点：
- 安全性高：存储在服务端
- 容量大：可以保存对象
- 缺点：
- 占用服务器资源
- 扩展性差（无非适配集群情况）
- 依然需要依赖Cookie有跨域限制
工作流程
借助于浏览器Cookie和Tomcat的Session完成，Cookie中保存jsessionid，每次请求的时候带上jsessionid，Tomcat根据jsessionid创建一个Sessin域，一般系统会向这个Session域中保存用户信息，这样前端每次请求后端就可以从Session域中拿到用户信息了从而保证了会话，这种会话也被称为有状态会话
5.为什么需要分布式会话
如果服务器集群部署以后，因为Session存放在服务器上，这样会导致每个Tomcat里面都有自己的Session，会导致Session不一致的问题（传统的基于Cookie与Session的会话方案失效）
6.粘性Session
Nginx负载均衡策略ip_hash实现，Haproxy负载均衡配置balance source实现，这种方案会让让用户永远连接集群中的某一个节点，这样的话只要维护单体系统下的会话即可
7.Session复制
介绍
比如Tomcat配置Session复制，在server.xml中进行配置
一般小公司可以这么做，集群的服务器大小10台以内
缺点
缺点增加网络开销，session复制有延时问题，每台tomcat都需要保存全局session，占用内存严重，迁移升级不友好
8.集中存储
介绍
Session数据集中存储方案则是将集群中的所有Session集中存储起来，Web服务器本身则并不存储Session数据，不同的Web服务器从同样的地方来获取Session，如下图所示：
相对于Session Replication方案，此方案的Session数据将不保存在本机，并且Web服务器之间也没有了Session数据的复制
问题
- 读写Session数据引入了网络操作，这相对于本机的数据读取来说，问题就在于存在时延和不稳定性，但是通信发生在内网，则问题不大
- 如果集中存储Session的机器或集群出现问题，则会影响应用
插件方式
- Web容器插件将会话信息存储到指定地方比如Redis
- 比如tomcat有插件tomcat-redis-session-manager，jetty有插件jetty-session-redis
- Server.xml配置，同时里面还要配置redis的连接信息
- 插件在新版本中可能不兼容，依赖于web容器，早期项目有使用，目前不多
SpringSession
Spring家族的提供的会话集中存储框架，可以把Session信息存储到某个地方（Redis，MongoDB，ES等）
9.Redis+Token
为什么需要
移动互联网时代很多没有Cookie
工作流程
移动端、前后端分离项目会这么处理，这也是推荐的方案
前端发出登录请求，登录成功后返回一个Token，后端把Token保存到某个地方比如Redis，后续客户端的每次请求资源都必须携带token，可以放在请求头中，服务端接收到请求首先校验是否携带token，以及token是否和Redis中的匹配，若不存在或不匹配直接拦截返回错误信息（如未认证）
