使用场景和优缺点对比
cookie+session
优点：
1.一般的web应用服务器都内置了对cookie+session的处理，不需要后端及前端开发人员理解交互逻辑，只需要简单地调用一个api即可完成认证，方便使用。
2.服务端可以控制cookie+session机制的有效回话时间。
缺点：
1.传统的cookie+session一般都将认证信息存储在内存当中，当服务器重启时就会丢失信息，导致所有用户都需要重新登陆。
2.由于信息保存在内存中，当一个服务器开启集群时，如果集群使用nginx等负载均衡服务器，会导致用户在A服务器登录，认证信息保存在A服务器上，但是请求接口路由到了B服务器上，但是B服务器没有用户的登录信息，导致用户会话失效又需要重新登陆，造成不好的体验，此种方式虽然可以通过ip hash来解决，但是达到负载均衡应有的效果大打折扣。【分布式cookie】
3.浏览器端一旦禁用cookie，将会造成用户会话永久失效，因为发起的请求中没有cookie，服务端将无法识别用法。
cookie+session更适合用于单体web服务，在tomcat+jsp或者其它这种前后端没有分离的项目中用的比较多。
代码：
controller：接口层，负责接收前端传过来的参数
service：业务逻辑的处理
dao：负责和数据交互，保存数据、返回数据都是D层做的
model：载体
filter：拦截器
util：工具
config：web服务的配置
P2
cookie
cookie就是存储在浏览器上的数据
只要电脑被黑，在cookie里的重要信息就会被泄露，于是就出现了session
session
服务器在发送cookie之前是会对这个含有sessionID的cookie进行签名
secret属性的值是给session ID cookie签名的值
name属性就是设置cookie里的name，默认是connect.sid
随着用户越来越庞大，session存储越来越大，也影响到了负载均衡，各种原因之下，出现了JWT json web token
JWT(json web token)
服务器不保存JWT，只需要保存JWT签名的密文
header部分声明需要什么算法来生成签名
payload部分是一些特定的数据，比如有效期之类的
session是保存在服务器端的，token是保存在浏览器的cookie或者storage中
P3
JWT
与普通token一样都是访问资源的令牌，都可以记录用户信息，都是只有验证成功后才可以获取信息。
不同的是普通token服务端验证token信息要进行数据的查询操作，JWT验证token信息就不用，在服务端使用密钥校验就可以，不用数据库的查询。
