背景：HTTP 请求是无状态的，但随着交互式应用兴起（需要登录的网站）需要管理会话，区分不同用户，这时候session 诞生了，但是session 需要在服务器端存储，让服务器压力山大。所以就想了一招服务器只生成token、验证token，用时间换空间
- cookies：由服务器生成，在客户端以key-value形式保存用户信息
- session：在服务端生成，在服务器端以key-value形式保存用户信息
- token：访问令牌--> 一个服务端生成的独一无二的字符串
| / | Cookies | Session | Token |
|---|---|---|---|
| 组成 | Name（名字，相当于key） + Value（值，即当前用户信息） + Domian（域名） + Path（路径） + Expires/Max-Age（过期时间） + Size（大小） | 保存在服务器内存中，维持一个hash表保存用户相关信息（也是key-value形式） | 登录时由服务端生成，一般组成形式：uuid(用户唯一身份标志)+time（时间戳）+sign(签名=uuid+time+salt根据hash算法生成的字符串）+[常用的固定参数（可选）] |
| 使用 | 服务器在响应头中设置，客户端保存，并在发送请求时请求头中带上cookie | 一个用户对应一个session，每个session都有它独一无二的sessionid，sessionid随响应头set-cookie保存到客户端的cookies中。客户端发送请求时带上cookies，服务端从cookies中拿到sessioid，然后根据sessionid从内存中找到对应用户的session获取相关用户信息 | 服务端生成后随http响应保存在客户端的cookies或local storage中，随客户端请求发送至服务端，用于单点登录的身份验证，防止跨站点请求伪造等 |
| 有效期 | 如果有设置过期时间，那么只要时间还没过期，即使关闭浏览器cookies也还会存在，反之，会在浏览器关闭时消失 | session默认30分钟超时，即如果在30分钟内session没有被访问过，那么就失效了。 | 根据token中的时间戳跟当前时间对比计算，看过期与否，有效期默认7天，用户退出时直接销毁token(???) |
| 优点 | 可以保存客户相关信息和状态，这对于无状态的http请求来说是很重要的(但也不是不可或缺，cookie是通过http请求报文head部分中的，而在http请求报文中，数据除了可以通过head传递，也可以通过url或请求体传递) | 能够解决cookies的安全隐患 | 支持跨域访问，防止信息外泄，可以在多个服务间共享。且不像session存储于服务器内存中，不影响服务器的性能 |
| 缺点 | 因为由客户端保存，可以被人修改，而且在传递过程中容易被人拦截(一些重要信息需要通过加密传输，而用session则可以把用户相关信息和状态保存在服务器，所以能避免信息外泄的问题)，具有安全隐患；且在某些浏览器上能保存的cookies数量和大小有限制；还有就是不支持跨域访问(Token可解决这个问题) | 因为保存在服务器内存中，当同时访问的用户很多时内存占用争夺，性能会受到影响 | 需要额外的时间开销(cpu需要每次去校验传过来的token是否有效(保存在服务器内存中性能是不是会更好，还是说有多种实现方案，自己衡量？？)) |
