session+cookie--＞token 演变

session+cookie–>token 演变

HTTP协议是无状态的，无状态意味着，服务器无法给不同的客户端响应不同的信息。这样一些交互业务就无法支撑了

cookie:

• Cookie保存在客户端中，分为内存Cookie和硬盘Cookie，内存Cookie由浏览器维护，保存在内存中，浏览器关闭后消失，硬盘Cookie保存在硬盘中，有一个过期时间，存在时间是长期的
• 同时HTTP Cookie是服务器发送到用户浏览器并保存在本地的一小块数据，会在浏览器在下一次请求被携带并发送到服务器上。

Cookie的传递会经历这4步

 1.Client发送HTTP请求给Server
 2.Server响应，并附带Set-Cookie的头部信息
 3.Client保存Cookie，之后请求Server会附带Cookie的头部信息
 4.Server从Cookie知道Client是谁了，返回相应的响应

• Server拿到Cookie后，通过什么信息才能判断是哪个Client呢？服务器的SessionID。

session :机制将用户所有的活动信息，上下文信息，登录信息等存储在服务端生成一个唯一标识ID发送给客户端，后续交互没有重复的交互信息，取而代之的是唯一标识ID.

• 客户端第一次请求，服务器会为客户端创建一个session，算出一个id标识session对象，返回给客户端，并由客户端保存；浏览器下次请求别的资源，浏览器会将sessionID放置请求头，服务器接受请求会解析sessionID,服务器接收sessionID确定请求方的身份信息和上下文信息。

• 弊端：

  • Session信息存到服务器，必然占用内存。用户多了以后，开销必然增大。为了提高效率，需要做分布式，做负载均衡。因为认证的信息保存在内存中，用户访问哪台服务器，下次还得访问相同这台服务器才能拿到授权信息，这就限制了负载均衡的能力。而且SeesionID存在Cookie，还是有暴露的风险，比如CSRF（Cross-Site Request Forgery，跨站请求伪造）。

• 解决方法：token

token: 服务器接收客户端信息(用户名、密码)后生成一次token和响应数据一同发送给客户端，客户端保存这个token。下次请求数据时带上token。服务器校验token。通过后再到数据库查找数据，返回给客户端

• Token不需要再存储用户信息，节约了内存。其次，由于不存储信息，客户端访问不同的服务器也能进行鉴权，增强了扩展能力。然后，Token可以采用不同的加密方式进行签名，提高了安全性。
• Token传递的过程跟Cookie类似，只是传递对象变成了Token。用户使用用户名、密码请求服务器后，服务器就生成Token，在响应中返给客户端，客户端再次请求时附带上Token，服务器就用这个Token进行认证鉴权。

Token虽然很好的解决了Session的问题，但仍然不够完美。服务器在认证Token的时候，仍然需要去数据库查询认证信息做校验。为了不查库，直接认证，JWT出现了。

JWT

• JWT的英文全称是JSON Web Token。JWT把所有信息都存在自己身上了，包括用户名密码、加密信息等，且以JSON对象存储的。

总结

cookie+session 与 token

cookie 和 session 一般一起使用：

• 客户端发起第一次请求==》服务器验证通过，生成一个session==》将session的sessionID 在cookie中携带，发送给客户端==》客户端保存cookie，
• 客户端发起第二请求，携带cookie==》服务器验证cookie中的seeionID,验证验证通过继续执行服务端操作。

token

• 用户输入用户名+密码 发送第一个请求到服务器==》服务器验证用户身份==》通过 生成token，执行服务器操作…返回数据是token到客户端==》客户端保存token。
• 客户端发起第二次请求，携带token 将Token作为请求头放入Headers中发送到服务器==》服务器端接收请求头中的Token，将用户参数按照既定规则再进行一次签名，两次签名若一致则认为成功，反之数据存在篡改请求失败。

本章内容，部分借鉴了其他博主 和 个人的归纳 有诸多遗漏，请各位大牛评点，万分感谢