Cookie和Session
HTTP协议是一种 无状态协议 ，即每次服务端接受到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；Session和Cookie的主要目的就是为了弥补HTTP的无状态特性。
Session是什么
客户端请求服务端，服务端会为了这次请求开辟一块内存空间，这个对象便是Session对象，存储结构为 ConcurrentHashMap 。Session弥补了HTTP无状态的特性，服务器可以利用Session存储客户端在同一个回话期间的一些操作。
Session如何判断是否是同一会话
服务器第一次接收到请求时，开辟了一块Session空间，同时生成了一个SessionID，并通过响应头的 Set-Cookie：JSESSIONID=XXXXXXX 命令，向客户端发送要求设置的Cookie的响应；客户端收到响应后，在本机客户端设置一个 JSESSIONID=XXXXXXX 的Cookie信息，该Cookie的过期时间为浏览器会话结束。
接下来客户端每次向同一个网站发送请求时，请求头都会带上该Cookie信息（包括SeSsionID），然后，服务器通过读取请求头中的Cookie信息，获取名称为JSESSIONID的值，得到此次请求的SessionID
Session的缺点
Seesion的缺点主要是在分布式场景的Session不一致，比如A服务器存储了Session，做了负载均衡后，假如一段时间内A的访问量激增，会转发到B进行访问，但是B服务器并没有存储A的Session，会导致Session的不一致或者失效。
Cookie是什么
HTTP协议中的Cookie包括 Web Cookie 和 浏览器Cookie ， 它时服务器发送到Web浏览器的一小块数据。服务器发送到浏览器的Cookie，浏览器会进行存储，并与下一个请求一起发送到服务器。通常，它用于判断两个请求是否来自同一个浏览器，例如用户保持登陆状态。
HTTP Cookie机制是HTTP协议无状态的一种补充和改良
Cookie的使用场景
主要有三个
- 回话管理
登陆、购物车、游戏得分或者服务器应该记住的其他内容 - 个性化
用户偏好、主题或者其他设置 - 追踪
记录和分析用户行为
Cookie曾经用于一般的客户端存储。虽然这是合法的，因为它是在客户端上存储数据的唯一方法，但是如今建议使用现代存储的API。Cookie随每个请求一起发送，因此可能会降低性能。
创建Cookie
当接收到客户端发出的HTTP请求时，服务器可以发送带有响应的 Set-Cookie 标头，Cookie通常由浏览器存储，然后将Cookie和HTTP标头一起向服务器发送请求。
Set-Cookie和Cookie标头
Set-Cookie HTTP响应标头将Cookie从服务器发送到用户代理。
此标头告诉客户端存储Cookie；
随着对服务器的每个新请求，浏览器将使用Cookie头将所有以前存储的Cookie发送回服务器。
有两种类型的Cookie，一种是Session Cookie，一种时Persistent Cookie。
如果Cookie不包含到期时期，则将其视为回话Cookie。回话Cookie存储在内存中，永远不会写入磁盘，当浏览器关闭时，此后Cookie将永久丢失。
如果Cookie包含 有效期 ，则将其视为持久性Cookie。在到期指定的日期，Cookie将从磁盘中删除
会话Cookie
会话Cookie有个特征，客户端关闭Cookie会删除，因为它没有指定 Expires 和 Max-Age 指令。
但是Web浏览器可能会使用会话还原，这会使大多数会话Cookie保持永久状态，就像从未关闭过浏览器一样。
永久性Cookie
永久性Cookie不会在客户端关闭时过期，而是在 特定日期（Expires） 或 特定时间长度（Max-Age） 外过期。
例如
Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT;
Cookie的作用域
Domain 和 Path 标识定义了Cookie的作用域，即Cookie应该发送给哪些URL。
Domain 标识标识指定了哪些主机可以接受Cookie。如果不指定，默认为当前主机（不包含子域名）。如果指定了 Domain ，则一般包含子域名。
例如，如果设置了 Domain=penglei.com ，则Cookie也包含在子域名中。如login.penglei.com 。
例如设置 Path=/docs ， 则一下地址都会匹配
- /docs
- /docs/Web/
- /docs/Web/HTTP
JSON Web Token和Session Cookie
JSON Web Token简称JWT ，它和Session都可以为网站提供用户的身份认证，但是它们根本不是一个概念。
什么是JSON Web Token
JSON Web Token 的简称就是JWT ，通常可以称为 JSON 令牌 。 它是由** RFC 7519** 中定义用于 安全的 将信息作为JSON 对象 进行传输对一种形式。JWT中存储的信息说经过 数字签名 的。因此可以呗信任和理解。也可以使用专用密钥对JWT进行签名。
JWT的使用场景
- 认证
这是使用JWT最常见的一种情况，一旦用户登陆，后面每个请求都会包含JWT，从而允许用户访问该令牌所运行对路由、服务和资源。单点登陆 是如今广泛使用JWT的一项功能，因为它对开销很小。 - 信息交换
JWT说能够安全传输信息的一种方式。通过公钥/密钥对JWT进行签名认证。此外，由于签名说使用 head 和 payload 计算的，因此还可以验证内容是否遭到篡改。
JWT的格式
JWT只要由三个部分组成，每个部分用 . 进行分割，各个部分分别是
- Header
- Payload
- Signature
因此一个非常简单对JWT的组成会是这个样子
header.Payload.Signature
Header
Header是JWT的标头，它通常由两部分组成：令牌的类型（JWT） 和使用的 签名算法 ，例如HMAC SHA256或RSA
例如
{
"alg": "HS256",
"typ": "JWT"
}
指定类型的签名算法后，JSON块会被 Base64Url 编码形成JWT的第一部分。
Payload
Token的第二部分是 Payload ，Payload包含一个声明。声明是有关实体和其他数据的声明，共有三种类型的声明
- registered 包含一组建议使用的预定义声明，主要包括
- iss 签发人
- exp 过期时间
- sub 主题
- aud 受众
- nbf 生效时间
- iat 签发时间
- jti 编号
- public 公共的声明，可以添加任何的信息，一般添加用户的相关信息或其他业务需要的必要信息，但不建议添加敏感信息，因为该部分在客户端可解密。
- private 自定义声明，旨在在同意使用它们的各方之间共享信息，既不是注册声明也不是公共声明。
signature
JWT的第三个部分是一个签证信息，这个签证信息由三部分组成。
- Header（Base64后的）
- Payload（Base64后的）
- Secret
签名用于验证消息再次过程中没有更改，并且对于使用私钥进行签名的令牌，它还可以验证JWT的发送者的真实身份。
JWT
现在将上面三个由点分隔的Base64-URL字符串部分组成在一起，这个字符串可以在HTML和HTTP环境中轻松传递这些字符串。
JWT和Session Cookie的相同之处
它们既可以对用户进行身份验证，也可以用来用户单机进入不同页面时以及登陆网站或应用程序后进行身份验证。
当时如果没有这两者，那可能需要在每个页面切换时都要进行登陆了。因为HTTP是一个无状态的协议。这也就意味着当你访问某个网页，然后单击同一站点上的另一个页面时，服务器的 内存中 将不会记住之前的操作。
因此，如果登陆并访问了有权访问的另一个页面。由于HTTP不会记录刚刚登录的信息，需要再次登陆。
JWT和Session Cookie就是用来处理在不同页面之间的切换，保存用户登陆信息的机制
也就是说，这两种技术都是用来保存用户的登陆状态的，能够让用户在浏览任意受密码保护的网站。通过在每次产生新的请求时对用户数据进行身份验证来解决此问题。
所以JWT和Session Cookie的相同之处就是它们能够支持用户在发送不同请求之间，记录并验证用户的登陆状态的一种机制。
JWT和Seesion Cookie的不同
主要由以下几点不同
- 密码签名
JWT具有加密签名，而Session Cookie没有 - JSON是无状态的
JWT是无状态的，因为声明被存储在客户端，而不是在服务端内存中。身份验证可以在本地进行，而不是在请求必须通过服务器数据库或者类似的位置中进行。这意味着可以对用户进行多次身份严重，而无需与站点或应用程序的数据库进行通信，也无需在此过程中消耗大量资源。 - 可扩展性
Session Cookie是存储在服务器内存中，这意味着如果网站或者应用很大的情况会耗费大量的资源。由于JWT是无状态的，在许多情况下，它们可以节省服务器资源。因此JWT要比Session Cookie具有更强的 可扩展性 - JWT支持跨域验证
Session Cookie只能用在 单个节点的域 或者它的 子域 中有效。如果他们尝试通过第三个节点访问，就会被禁止。使用JWT可以解决这个问题，使用JWT能够通过 多个节点 进行用户认证，也就是 跨域认证
评论区