cookie、session、token理解

Cookie是保存在浏览器上的一些数据，一般通过HTTP响应头set cookie来设置，当然也可以通过JS脚本来直接设置，Cookie是按照网站来进行组织和保存的，每一个网站都可以在浏览器中保存一些Cookie，保存好了之后，浏览器向这个网站发出的请求都会携带这些Cookie，server就可以分析这些Cookie。

session是一个抽象概念，指server端生成的能够将用户请求与后台存储的用户状态信息一一对应的会话机制。每一个session都会生成一个唯一的sessionId，并通过cookie传递到client端。之后的请求只要在 cookie 里带上 sessionId=xxx 这一个键值对即可在server 找到它对应的用户状态信息。（通过cookies实现session）

session 和 token 本质上是没有区别的，都是对用户身份的认证机制，只是他们实现的校验机制不一样而已（一个保存在 server，通过在 redis 等中间件获取来校验，一个保存在 client，通过签名校验的方式来校验），多数场景上使用 session 会更合理，但如果在单点登录，一次性命令上使用 token 会更合适，最好在不同的业务场景中合理选型，才能达到事半功倍的效果。

当server服务器有多个的时候，请求会通过负载均衡来分配到不同的机器上，这时需要各个机器之间能够共享session。目前大型公司都会采用将session存储在redis或memcached等中间件中，当请求发来时，再去中间件取一下session。

如果没有现成的redis集群部署，就可以使用token来校验用户身份。用户在登录时server会生成token并返回到客户端，由于token中本身就携带者ucid之类的信息，因此客户端发送的请求就可以携带token来标识用户。token 主要由三部分组成 1. header：指定了签名算法 2. payload：可以指定用户 id，过期时间等非敏感数据 3. Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。当 server 收到浏览器传过来的 token 时，它会首先取出 token 中的 header + payload，根据密钥生成签名，然后再与 token 中的签名比对，如果成功则说明签名是合法的，即 token 是合法的。