Cookie、Session、Token的区别

1 cookie

HTTP服务器是无状态的，这简化了服务器的设计。然而一个Web站点通常希望能够识别用户，可能是因为服务器希望限制用户的访问，或者因为它希望把内容与用户身份联系起来。为此，HTTP使用了cookie。

下图是cookie的工作流程：

从图中可以看出，cookie技术有4个组件：

1. 在HTTP响应报文中的一个cookie首部行
2. 在HTTP请求报文中的一个cookie首部行
3. 在用户端系统保留有一个cookie文件，并由用户的浏览器进行关系
4. 位于Web站点的一个后端数据库

上图中cookie工作方式是：

• 假设Susan已经访问过ebay并生成了对应的cookie，现在她首次与Amazon.com联系。
• 当请求报文到达该Amazon Web服务器时，该Web站点将产生一个唯一识别码，并以此作为索引在它的后端数据库中产生一个表项。接下来Amazon Web服务器用一个包含Set-cookie：1678首部的HTTP响应报文对Susan的浏览器进行响应，其中Set-cookie首部含有识别码1678。
• 当Susan的浏览器收到了该HTTP响应报文时，它会看到该Set-cookie首部。该浏览器在它管理的特定cookie文件中添加一行，该行包含服务器的主机名和Set-cookie首部的识别码。值得注意的是该cookie文件已经有了用于eBay的表项，因为Susan过去访问过该站点。
• 当Susan继续浏览Amazon网站时，每请求一个Web页面，其浏览器就会从该cookie文件中获取她对这个网站的识别码，并放到HTTP请求报文中包括识别码的cookie首部行中。发往Amazon服务器的每个HTTP请求报文都包括以下首部行：Cookie: 1678 在这种方式下，Amazon服务器可以跟踪Susan在Amazon站点的活动。尽管Amazon Web站点不知道Susan的名字，但它确切地知道用户1678按照什么顺序、在什么时间、访问了哪些页面。这样Amazon就可以使用cookie来提供它的购物车服务，即Amazon能够维护Susan希望购买的物品列表，这样在Susan结束会话时可以一起为它们付费。
• 如果Susan再次访问Amazon站点，比如一个星期后，她的浏览器会在其请求报文中继续放入首部行cookie：1678. Amazon将根据Susan过去在Amazon访问的网页向她推荐产品。如果Susan也在Amazon注册过，即提供了她的全名、电子邮件地址等，则Amazon能在其数据库中包括这些信息，将她的全名与识别码相关联。

以下是通常会保存在 Cookie 中的数据：

• 身份信息：例如用户 ID、用户名等，用于区分不同的用户。
• 会话状态：例如用户是否已登录、购物车中的商品等。
• 个人偏好：例如网站的主题颜色、字体大小等。
• 跟踪信息：例如用户的浏览行为、广告点击情况等。

创建一个 Cookie 并将它放在客户端的过程通常由服务器完成，当服务器返回 HTTP 响应时，可以在响应头 Set-Cookie 中包含一个或多个 Cookie。这些 Cookie 会被浏览器存储起来，并在以后的请求中自动附加到请求头 Cookie 中，发送给服务器。

按在客户端中的存储位置，可分为内存 Cookie 和硬盘 Cookie，内存 Cookie 由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的，硬盘 Cookie 保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘 Cookie 不会被删除，其存在时间是长期的。

服务端创建Cookie时，Cookie 的过期时间、域、路径、有效期、适用站点都可以根据需要来指定。

一个简单的 Cookie 可能像这样：

Set-Cookie: <cookie名>=<cookie值>

HTTP/1.0 200 OK
Content-type: text/html
Set-Cookie: yummy_cookie=choco
Set-Cookie: tasty_cookie=strawberry

客户端对该服务器发起的每一次新请求，浏览器都会将之前保存的 Cookie 信息通过 Cookie 请求头部再发送给服务器。

GET /sample_page.html HTTP/1.1
Host: www.example.org
Cookie: yummy_cookie=choco; tasty_cookie=strawberry

1.1 存在的问题

Cookie 常用来标记用户或授权会话，被浏览器发出之后可能被劫持，被用于非法行为，可能导致授权用户的会话受到攻击，因此存在安全问题。

待补充

2 Session

2.1 Session 机制的概念

如果说 Cookie 是客户端行为，那么 Session 就是服务端行为。

Cookie 机制在最初和服务端完成交互后，保持状态所需的信息都将存储在客户端，后续直接读取发送给服务端进行交互。

Session 代表服务器与浏览器的一次会话过程，并且完全由服务端掌控，实现分配 ID、会话信息存储、会话检索等功能。

Session 机制将用户的所有活动信息、上下文信息、登录信息等都存储在服务端，只是生成一个唯一标识 ID 发送给客户端，后续的交互将没有重复的用户信息传输，取而代之的是唯一标识 ID，暂且称之为 Session-ID 吧。

2.2 简单的交互流程

• 当客户端第一次请求 session 对象时候，服务器会为客户端创建一个 session，并将通过特殊算法算出一个 session 的 ID，用来标识该 session 对象。
• 当浏览器下次请求别的资源的时候，浏览器会将 sessionID 放置到请求头中，服务器接收到请求后解析得到 sessionID，服务器找到该 id 的 session 来确定请求方的身份和一些上下文信息。

3.3 Session 的实现方式

首先明确一点，Session 和 Cookie 没有直接的关系，可以认为 Cookie 只是实现 Session 机制的一种方法途径而已，没有 Cookie 还可以用别的方法。

session 的实现主要两种方式：cookie 与 url 重写，而 cookie 是首选方式，因为各种现代浏览器都默认开通 cookie 功能，但是每种浏览器也都有允许 cookie 失效的设置，因此对于 Session 机制来说还需要一个备胎。

将会话标识号以参数形式附加在超链接的 URL 地址后面的技术称为 URL 重写。

原始的URL：
http://taobao.com/getitem?name=baymax&action=buy
重写后的URL:
http://taobao.com/getitem?sessionid=1wui87htentg&?name=baymax&action=buy

3.4 存在的问题

由于 Session 信息是存储在服务端的，因此如果用户量很大的场景，Session 信息占用的空间就不容忽视。

对于大型网站必然是集群化 & 分布式的服务器配置，如果 Session 信息是存储在本地的，那么由于负载均衡的作用，原来请求机器 A 并且存储了 Session 信息，下一次请求可能到了机器 B，此时机器 B 上并没有 Session 信息。

这种情况下要么在 B 机器重复创建造成浪费，要么引入高可用的 Session 集群方案，引入 Session 代理实现信息共享，要么实现定制化哈希到集群 A，这样做其实就有些复杂了。

4 Token 方案

Token 是令牌的意思，由服务端生成并发放给客户端，是一种具有时效性的验证身份的手段。

Token 避免了 Session 机制带来的海量信息存储问题，也避免了 Cookie 机制的一些安全性问题，在现代移动互联网场景、跨域访问等场景有广泛的用途。

4.1 简单的交互流程

• 客户端将用户的账号和密码提交给服务器
• 服务器对其进行校验，通过则生成一个 token 值返回给客户端，作为后续的请求交互身份令牌
• 客户端拿到服务端返回的 token 值后，可将其保存在本地，以后每次请求服务器时都携带该 token，提交给服务器进行身份校验
• 服务器接收到请求后，解析关键信息，再根据相同的加密算法、密钥、用户参数生成 sign 与客户端的 sign 进行对比，一致则通过，否则拒绝服务
• 验证通过之后，服务端就可以根据该 Token 中的 uid 获取对应的用户信息，进行业务请求的响应

4.2 Token 的设计思想

以 JSON Web Token（JWT）为例，Token 主要由 3 部分组成：

• Header 头部信息：记录了使用的加密算法信息
• Payload 净荷信息：记录了用户信息和过期时间等
• Signature 签名信息：根据 header 中的加密算法和 payload 中的用户信息以及密钥 key 来生成，是服务端验证客户端的重要依据

header 和 payload 的信息不做加密，只做一般的 base64 编码，服务端收到 token 后剥离出 header 和 payload 获取算法、用户、过期时间等信息，然后根据自己的加密密钥来生成 sign，并与客户端传来的 sign 进行一致性对比，来确定客户端的身份合法性。

这样就实现了用 CPU 加解密的时间换取存储空间，同时服务端密钥的重要性就显而易见，一旦泄露整个机制就崩塌了，这个时候就需要考虑 HTTPS 了。

4.3 Token 方案的特点

• Token 可以跨站共享，实现单点登录
• Token 机制无需太多存储空间，Token 包含了用户的信息，只需在客户端存储状态信息即可，对于服务端的扩展性很好
• Token 机制的安全性依赖于服务端加密算法和密钥的安全性
• Token 机制也不是万金油