对token(令牌)的理解

1 、若是单纯的浏览文档，不需要记录是谁发送了请求，在某一段时间里浏览了什么，每一次都是一个新的请求。
随着交互式WEB应用的兴起，像购物网站、需要登录的网站等，这就需要区分每个用户，因为HTTP协议是无状态的，无状态的意思就是服务器不保存与客户端交互的任何状态，也就是说，上一次请求对这次没有任何影响，每一次请求都是新的。一开始是使用session和cookie机制，见文档“https://blog.csdn.net/weixin_42037528/article/details/115584069”

这样一来每个人都只需要保存自己的session id，而服务器要保存所有用户的session id，占用服务器空间，而且严重限制了服务器的扩展能力。比如用两个机器做了一个集群，小Q通过机器A登陆了系统，那么sesssion id 会保存在机器A上，假设小Q下次请求被转到机器B该怎么办，机器B没有小Q的session id 。
方法1：session sticky，即请求粘连，让小Q的请求一直粘连在机器A上，但是万一机器A挂掉了，请求还是需要转到机器B上去。
方法2：session复制，把session id在2个机器之间搬来搬去，快累死了
方法3：Memcached想出来吧session集中存储到某个地方，所有的机器都来这个地方访问，这样一来，要是负责存储session的机器挂掉了，所有人都得重新登录一遍。
2、token（令牌） ：验证机制
小Q第一次登录到系统中，服务器发一个token（令牌）给她，里面包含和user id，下一次小Q在次通过HTTP请求访问该服务器的时候，把这个token通过HTTP header带过来
不过这和sessionid 没有任何区别啊。任何人都可以伪造，所以得想办法让别人伪造不了。
那就对数据做一个签名，比如使用HMAC-SHA256算法，加上一个只有我知道的密钥，对数据做一个签名，把这个签名和数据作为token，由于别人不知道密钥，就无法伪造token了。

这个token我不保存，当小Q吧这个token发给我的时候，我在用同样的HMAC—SHA256算法和同样的密钥，对数据在做一次签名，和token中的签名作比较，如果相同，服务器就知道小Q已经登陆过了，并且可以直接获取小Q的user id ，数据被人篡改过，我就告诉发送者：对不起，没有认证。

token中的数据是明文保存的（虽然会用base64坐下编码，但那不是加密），还是可以被人看到，所以不能保存向密码这样的敏感信息。
当然，若果token被人偷走了，那我也没有办法，我也会认为小偷是合法用户，这其实和sessionid被别人偷走是一样的。
这样一来，我就不保存session id了，我只是生成token，然后验证token，我用我的CPU计算时间获取了我的session存储空间。