cookie、session、token产生的背景？
在互联网早期，所有的互联网请求都是原生无状态的http协议，无法满足用户想要通过个人身份访问网站，获取个性化资源的愿望。也正是因为如此，催生了cookie等请求标识，用于在请求时，携带用户信息，获取该用户对应的资源。
具体的交互流程如下图所示：
cookie是什么？
一般情况下，当用户向服务器发起登录请求后，服务器在登录成功的响应头中添加一个set-cookie的字段。当客户端接收到这个字段后，在该字段满足大小不超过4kb，domain（域），path（路径），expire-time（过期时间）都是符合的情况下，浏览器将会自动添加cookie。在后续的请求中，所有请求的头部都会自动带上cookie信息，以便服务器用于认证该用户。
cookie在最初完成交互后，将状态保存在客户端中，在后续的请求中，都会自动带上cookie信息，以便用户身份认证。
成功保存的条件：
- 大小不超过4kb
- domain和path匹配当前url
- expire-time没有过期
cookie作为用户的身份认证，不法之徒便会利用cookie伪造自己的身份，进行网络攻击
csrf攻击：
此攻击是利用服务器对浏览器的信任（或者说是利用对cookie的信任），当cookie被钓鱼网站劫持后，利用用户信息向服务器发起正常的请求（可能涉及将用户信息转发给第三方或者向第三方转账等行为）。
session是什么？
客户端第一次请求session对象时，服务器通过特殊算法计算出一个session的ID，用来标识该session对象。等下次请求别的资源时，请求头可以带上该sessionID，确定请求方的身份。
将session传递到浏览器端有两种方式：cookie和url重写（即把session作为参数填入url内）
session存储在服务器，如果用户量很大的场景下，必然需要进行集群化&分布式的服务器配置。
由上图可知，每一个sessionId都会存储在服务器，每多一个用户，服务器的存储就会变得庞大。
token是什么？
为了解决服务器存储大量session的问题，于是，token出现了。此时的服务器只需要保留一套加密算法，将加密前后的结果交由客户端进行存储。
token：客户端将用户的账号密码提交给服务器，服务器通过加密算法计算出一个token发放给客户端。客户端此时只保存了加密算法，无需保存token。等待下次客户端发起请求并携带token时，可以通过重新生成签名，从而比对签名是否一致，判定用户是否在此服务器上校验过身份。
解决了防篡改问题，而不是解决防伪造问题！ token的组成：
- header：加密算法信息
- payload：uid+exipre
- signature：签名
