概要
cookie
1. 为什么会出现cookie?
http是无状态的协议，导致请求不知道是哪个用户操作的。cookie的出现就是为了解决http请求无状态和服务端要知道请求来源之间的矛盾。
cookie会根据服务端发送的响应报文中的set-cookie字段信息，通知客户端保存cookie。下次客户端发送请求时就会携带cookie，服务端收到请求，根据cookie和服务器的记录进行比对，找到之前的状态。
2. cookie存在的问题有哪些？
-
cookie会作为http的请求报文进行传递，所以要注意cookie字段的大小，一般小于4kb。如果cookie存储的字段过大，浪费流量，服务端也会耗费性能解析cookie。
-
cookie保存在客户端，存在篡改或劫持的风险。故cookie不能存储重要信息，一般只保存凭证，服务端会根据cookie从数据库或session中查找具体信息。
关于cookie更详细的介绍可以看维基百科 ➡️ HTTP cookie
session
1. session是什么
session本质是一段保存在服务端内存中的代码片段，session的实现一般是基于cookie的。cookie记录凭证，session记录具体数据。
2. session存在问题
- session会占用内存，开销大。传统的session保存在内存里，每当用户登录时，在session做一次记录。随着认证用户的增多，服务端的开销会明显增大。
- session横向扩展差。页面的请求不一定是同一台服务器，如果请求打到不同服务器，那么服务器之间需要共享session。此时需要做session的持久化，如果持久化失败就出现认证失败。
jwt
jwt全称json web token，是目前最流行的跨域身份验证解决方案。
1. 解决的问题
传统的session不支持分布式架构，无法支持横向扩展，只能通过数据库来保存会话数据实现共享。如果持久层失败会出现认证失败。回到问题的本质，是因为服务端需要记录客户端对应的信息，来鉴别客户端状态。
而使用jwt，服务端不需要记录客户端对应的信息。服务端通过对token上携带的信息进行处理能够确认这个token是否是有效。服务器变为无状态，使其更容易扩展。
2. token的组成
jwt生成的token由3部分组成：头、内容、签名，通过符号.连接。
1. Header 头部
- 声明类型，这里是
JWT - 声明加密的算法，这里是
HS256
Header的示例：
{
'typ': 'JWT',
'alg': 'HS256'
}
2. Payload 内容：存放有效信息，例如过期时间，面向用户等
Payload的示例：
{
"exp": "1234567890",
"name": "John Doe"
}
3. Signature 签名
Signature 由下面两步得到
-
将base64加密后的Header和base64加密后的Payload使用.连接组成的字符串
-
将字符串进行Header中声明的加密方式进行加盐
secret组合加密HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
3. 鉴权原理
① 客户端发送/login请求到服务端A，服务端A校验登录通过后生成token。
② 服务端A将token返回给客户端。
③ 客户端发送/list请求到服务端B，同时在请求头里携带了token。服务端将token拆解成header+payload+signature三部分，再次将header.payload进行加密，得到新的signature。如果新的signature和旧的signature相等则表示当前客户端是登录过的状态。
④ 服务端B校验通过，返回数据给客户端。
4. 常用的jwt库有
总结
读完这篇文章，希望你能对cookie、session和jwt有一定的了解。
传统的cookie+session的鉴权形式有一定的局限性，表现在：
1. session占用服务器内存
2. session的横向扩展性不好，需要数据持久化。数据持久化如果失败影响鉴权。
使用jwt能让服务器变成无状态的，即服务器不需保存当前请求的会话信息。实现原理是：
- 在初次请求时，服务端生成一个token返回给客户端；
- 客户端再次请求时携带token，服务端将token拆解成header+payload+signature三部分，将
header.payload进行加密，得到新的signature。如果新的signature和旧的signature相等则表示通过，当前客户端是登录过的状态。
