前后端分离以及token的使用
- 为什么使用前后端分离：
首先说一下jsp的工作原理：
jsp实际上也是是一个继承自Servlet接口的java类，实际上它就是一个Servlet，JSP的页面渲染是在后端完成的，经过tomcat的处理后，把jsp转为html后，再统一发送给前端（浏览器）显示出来
那现在手机移动端app这么普及，那我怎么写一份后端代码，即又可以显示在手机app上面，又可以在pc端跑呢？
手机app不是浏览器，他不可以显示 html 跟 jsp 哦 , 而且手机跟浏览器不一样，是不是需要把数据交给前端，让前端来渲染数据才可以解决问题
前后端通过json格式交互数据
主流前端框架MVVM
vm层（视图模型层）通过接口从后台m层（model层）请求数据，vm层继而和v（view层）实现数据的双向绑定。
-
token（令牌）
token与Session的区别
SESSION 是服务器通过 Key-Value 对来保存数据的一种机制，比如 APP 的登录状态可以用 SESSION 来保存。 TOKEN 翻译过来叫令牌，令牌是什么意思？可以拿现实中的令牌对比，现实中的令牌起到通行证的作用，而这在服务端也是一样的。我们在登录后，服务端使用 SESSION 保存我们的登录状态，并把 SESSION 的 Key 返回给客户端，那么这个 Key 就成为我们的令牌（TOKEN），我们以后再访问数据，就直接把这个 TOKEN 随着请求一起发送给服务端，这样服务端通过这个 TOKEN 在 SESSION 中查找数据，如果有就说明 TOKEN 有效（就像你去旅游，关口认可你的通行证），并取出你的登录数据，利用你的用户信息（保存在登录数据内）查出你想要的内容。为什么使用token不用Session
Session的原理：
当用户第一次通过浏览器使用用户名和密码访问服务器时，服务器会验证用户数据，验证成功后在服务器端写入session数据，向客户端浏览器返回sessionid，浏览器将sessionid保存在cookie中，当用户再次访问服务器时，会携带sessionid，服务器会拿着sessionid从服务器获取session数据，然后进行用户信息查询，查询到，就会将查询到的用户信息返回，从而实现状态保持
Session的弊端：
1、服务器压力增大
通常session是存储在内存中的，每个用户通过认证之后都会将session数据保存在服务器的内存中，而当用户量增大时，服务器的压力增大。
2、CSRF跨站伪造请求攻击
session是基于cookie进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
3、扩展性不强
如果将来搭建了多个服务器，虽然每个服务器都执行的是同样的业务逻辑，但是session数据是保存在内存中的（不是共享的），用户第一次访问的是服务器1，当用户再次请求时可能访问的是另外一台服务器2，服务器2获取不到session信息，就判定用户没有登陆过。
token实现原理
Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位。如果这个 Token 在服务端持久化（比如存入数据库），那它就是一个永久的身份令牌。
token 有很多种实现方式，这里以jwt为例子：
JWT ： 是一种基于JSON，用于在网络上声明某种主张的令牌（token），jwt通常有三部分组成：头部信息(header) 消息体， 和签名
头部信息：指定了该JWT使用的签名算法
消息体：包含JWT中储存的信息
签名：通过密钥跟算法生成签名
token与Session的不同点：
token与session的不同主要在
1，认证成功后，会对当前用户数据进行加密，生成一个加密字符串token，返还给客户端（服务器端并不进行保存）
2，浏览器会将接收到的token值存储在Local Storage中，（通过js代码写入Local Storage，通过js获取，并不会像cookie一样自动携带）
3，再次访问时服务器端对token值的处理：服务器对浏览器传来的token值进行解密，解密完成后进行用户数据的查询，如果查询成功，则通过认证，实现状态保持，所以，即时有了多台服务器，服务器也只是做了token的解密和用户数据的查询，它不需要在服务端去保留用户的认证信息或者会话信息，这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录了，这就为应用的扩展提供了便利，解决了session扩展性的弊端。
一，登录：
二，业务请求：
三，token过期，刷新token