Cookie, Session, JWT
HTTP协议是无状态协议，服务器端接收到客户端的请求时并不知道客户端的历史请求记录。有的场景需要维护状态，这时就需要标记。
1. Cookie
Cookie是H5之前前端存储的主要方案（H5新增了localStorage和sessionStorage）。 Cookie可以实现每次发送http请求时都携带数据发送给服务器，
- 浏览器第一次访问服务器时发送http请求
- 服务器接收请求后Set-Cookie将返回信息的名和值填充完整，返回给浏览器
- 浏览器保存返回的Cookie，这样以后再访问服务器时，就可以携带这个Cookie Cookie里可以通过Domain/Path限制空间范围，Expires/Max-Age限制时间范围，Secure/HttpOnly限制使用方式。 HTTP响应头一个Set-Cookie头用于向浏览器写入一条cookie，一次HTTP响应中可以设置多个Set-Cookie
2. Session
但是如果在Cookie中返回的是用户名、密码等信息，会存在信息泄漏的风险，于是开始使用Session。
- 客户端第一次向服务器发送请求，服务器为其开辟内存空间，存放一个Session对象，生成sessionID和会话结束时间，通过Set-Cookie返回给客户端
- 客户端收到响应，将sessionID写入Cookie信息，会话结束时间设置为Cookie的有效期
- 这样以后客户端再向同一个网站发送请求时，请求头都会带上这个Cookie信息，包含sessionID
- 服务器端读取请求头时读取到了Cookie信息，获取sessionID，也就知道了这个客户端的操作记录
- 在Cookie的有效期结束后，用户登录就需要再次输入用户名密码等信息了
2.1 优点
这里浏览器保存的不是用户名和密码，而是sessionID，即便sessionID泄漏，也无法获得用户名和密码；另外，浏览器在返回含有sessionID的Cookie前会进行签名，如果修改了sessionID就会导致无法识别。
2.1.1 CSRF跨站请求伪造
但是如果用户A访问可信任网站B，B返回给A一个Cookie后，A在没有清除这个Cookie的情况下访问恶意网站C，C就可以盗取含有sessionID的Cookie向网站B发送消息，网站B无法识别是A发送的还是C发送的，就会按照C发送的请求执行，导致用户A遭到损失，这就称为CSRF攻击（跨站请求伪造）。
2.2 缺点
sessionID是保存在服务器中的，如果因负载均衡，访问转发到了另一台服务器，就无法获取到这个sessionID。但如果使用不同服务器之间共享sessionID即通过session数据的持久化，写入数据库中，虽然架构清晰，但工程量大，且会存在崩溃的情况。
3. JWT
- 客户端第一次向服务器发送请求，服务器会生成一个JWT，保存JWT签名的密文，而把JWT发送给客户端
- 客户端通过Cookie或Storage把JWT保存下来（存在Cookie中无法跨域，要将其写入http请求头信息authorization字段里）
- 这样以后客户端再向同一个网站发送请求时，都会将这个JWT一起发送给服务器端
- 服务器端对发送过来的JWT重新进行运算验证
3.1 JWT的组成
- JWT是由header.payload.signature组合而成的
- header：声明需要用什么算法生成签名
- payload：特定数据如有效期
- header和payload经过Base64编码后经过header声明过的算法运算得到签名信息signature，得到一个完整的JWT发送给客户端。三个部分相互关联，有一定的安全性。
3.2 优点
- 服务器无需保存任何session数据，变成无状态，比较容易实现设备上的扩展。
3.3 缺点
- JWT 的最大缺点是，由于服务器不保存 session 状态，因此无法在使用过程中废止某个 token，或者更改 token 的权限。也就是说，一旦 JWT 签发了，在到期之前就会始终有效，除非服务器部署额外的逻辑。
3.4 特点
- JWT默认不加密，不能写入秘密数据，除非在生成原始Token后用密钥再加密一次。
- 为了减少盗用，JWT 不应该使用 HTTP 协议明码传输，要使用 HTTPS 协议传输。
4. 区别
- Session由服务器生成，保存在服务器端；jwt由服务器生成，保存在客户端，服务器端不保存
- 相当于jwt用运算的算力换取了session的存储
