Cookie和Session、token粗解

先说下Cookie的产生
由服务器产生—典型例子：sessionID
具体过程如下：
客户端的某次请求—>发送给服务器；
服务器产生一个Cookie，附价在HTTP响应头中，传递给客户端浏览器—>浏览器保存Cookie
客户端之后的所有请求，都会把Cookies附加在HTTP请求头中，传递给服务器—>服务器校验有用的Cookie信息
有客户端产生—典型例子：记住用户名
由客户端产生的Cookie与服务器产生的Cookie性质一样，也可以保存在本地，也会被传递到服务器
下面说下Session的简介
Session一般翻译为会话，进行某些获得持续的一段时间，从打开某网站到关闭浏览器，这是一个会话
Session一定是服务端创建的
服务器创建的Session标识是全局唯一的，一串字符
服务器创建的Session标识一般存储在服务器[内存]中
Session标识被发往浏览器时间，会设置过期时间为1970年1月1日前的1秒，表示的是一个过去式
服务器创建的Session标识通过HTTP响应头中的set-Cookie发送给客户端
浏览器拿到Session标识后，会临时存储，因为它是一个会话Cookie,所以浏览器关闭，它就消失

Session销毁
Session 有超时设置，如果到了超时时间，系统会自动把Session注销
Session 有注销机制，调用invalidate方法，可以注销Session
通常关闭应用（Tomcat），所有Session都会被注销，关闭服务器
注：关闭浏览器不会注销Session 的。
Session + Cookie 实现登录

(一)、Java 项目通常解决方案
当浏览器发送请求时，服务器会自动判断浏览器是否有带SessionID。
如果没有带SessionID，立马生成一个全新的SessionID给它
如果有带SessionID，会校验服务器内存是否存在，如果不存在，则立马生成一个全新的给它
如果有带SessionID，会校验服务器内存是否存在，如果存在，则不处理
之后的每次请求，都会刷新服务端SessionID的有效期

---------到这里为止，不管用户是否已经登录，客户端都有可以用的SessionID-------------

当输入正确的用户名、密码，点登录按钮，如果登录成功。
程序员会把SessionID 存入到另外一个【内存变量中2】容器中
之后的每次请求，权限拦截器都会拦截到你的SessionID，并和内存中的【内存变量中2】进行查找，如果发现查找不到，则会帮你重定向到登录界面。
当客户端主动注销，服务器会调用invalidate方法注销服务器上的Session,并重定向到登录界面，又会产生新的SessionID

(二)、其他项目解决方案
当输入正确的用户名、密码，点登录按钮，如果登录成功。
服务器会生成一个SessionID 返回给客户端，客户端浏览器存到Cookie
当用户主动注销，【服务器端】会同时删除【服务端SessionID】和【客户端cookie】

解决的问题：
session保存在内存中，当用户量大的时候会对服务器增加很大的压力
当有多台服务器做负载均衡时，能减轻服务器的压力，但session需要在多台服务器间来回复制
当session共享到一台服务器上时，能避免session的复制，但如果这台服务器发生了问题，所有人都需要重新登录

Token介绍：
生成原理：
Token 由三部分组成，第一部分：头部（Header），第二部分：荷载（Payload ）第三部分：签名(Signature)
第一部分，包含的数据为：token类型、加密方式，数据用base64加密
第二部分，包含登录的用户信息，如用户名、用户id等，但是不能包含敏感信息，数据用base64加密
第三部分，为签名，它的值=【Header + Payload 】用：密钥进行HMAC-SHA256 加密。

举例：
第一部分：数据为：{“alg”:“HS256”} base64加密后为：eyJhbGciOiJIUzI1NiJ9
第二部分：数据为：{“jti”:“fancl”,“sub”:“fancl”,“iat”:1570675025} base64加密后为：
eyJqdGkiOiJmYW5jbCIsInN1YiI6ImZhbmNsIiwiaWF0IjoxNTcwNjc1MDI1fQ
第三部分：【eyJhbGciOiJIUzI1NiJ9+eyJqdGkiOiJmYW5jbCIsInN1YiI6ImZhbmNsIiwiaWF0IjoxNTcwNjc1MDI1fQ】
用密钥：JYJ5Qv2WF4lA6jPl5GKuAG 进行加密，得出来的结果为签名：oUJMDTP4UcM7sDBin42kxOLfn53j37Hx5gqhtcXCilw

最终返回到客户端的Token为：
eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJmYW5jbCIsInN1YiI6ImZhbmNsIiwiaWF0IjoxNTcwNjc1MDI1fQ.oUJMDTP4UcM7sDBin42kxOLfn53j37Hx5gqhtcXCilw

校验原理：
客户端之后的请求，请求头都会带Token 到服务器
服务器从Token取出第一部分和第二部分，用【密钥】进行HMAC-SHA256 加密，结果和取出的第三部分比较。如果相同，表示客户端传递的Token 是没有被篡改的。
由于第二部分数据，包含用户信息，所以服务器知道请求的是哪个用户。

简易理解
【数据】采用【密钥】用【加密算法】生成【签名】
返回给客户端的Token=【数据】.【签名】
校验时，从客户端过来的Token中取出【数据】采用服务器的【密钥】用【加密算法】生成【新签名】
【新签名】 与 从Token中取出的【签名】，比较
比较一致，表示内容没有被篡改
base64在线加密解密网址：http://tool.oschina.net/encrypt?type=3

Token实现登录
通过用户名+密码 调用API接口
如果调用成功，服务端签发一个Token,并返回给服务端
客户端浏览器收到Token后，把它存起来，比如放在 Cookie 里或者 Local Storage 里
客户端每次向服务端请求资源的时候需要带着服务端签发的 Token
服务端收到请求，把Token中的数据取出来，和密钥再进行一次签名，这个签名和Token中的签名比较