1.它们的由来
当你进入一个网页，进行登录注册，很长一段时间都不用输入用户名和密码，你有考虑过是怎么实现的吗。如果你了解 HTTP 就知道，你再次访问服务器时,服务器会将每个传入的请求都视为一个独立的事务，服务器其实是不知道是又是你来访问的，因为 HTTP 协议本质上是无状态的 。对之前的交互没有任何记忆。
所以为了解决这个根本问题，业界发展出了三种核心机制，为无状态的 Web 赋予“记忆”：Cookie、Session 和 Token。
2.Web 会话管理的基础 Cookie
Cookie 是服务器发送到用户浏览器并保存在本地的一小块数据 。它就像一张“身份证”，浏览器在后续每次向同一服务器发送请求时都会带上它，从而让服务器能够识别出是同一个用户 。
当用户首次访问一个网站时，服务器可以在 HTTP 响应中通过 Set-Cookie 头向浏览器发送一小块数据。浏览器接收并存储这个 Cookie。在之后对该服务器的每次请求中，浏览器都会自动通过 Cookie 头将这个 Cookie 回传给服务器 。这个简单的往返机制使得服务器能够识别用户并维持状态，主要用于会话管理、个性化设置和用户行为跟踪 。
3.一种有状态的身份验证模型 Session
Session 是一种在服务器端存储用户信息的机制 。当用户登录后，服务器会创建一个唯一的“会话 ID”（Session ID），并将这个 ID 通过 Cookie 发送给浏览器。之后，浏览器只需发送这个 ID，服务器就能通过它找到完整的用户会话信息 。Session 就像是服务器为每个用户开设的一个临时档案柜，而 Session ID 就是档案柜的钥匙。
4.一种无状态的认证模型 Token
是一种无状态的身份验证方案。用户登录后，服务器会生成一个经过加密签名的“令牌”（Token），其中包含了验证所需的所有信息（如用户 ID、权限、过期时间） 。这个令牌被发送给客户端存储，并在后续请求中提交给服务器。服务器只需验证令牌的签名是否有效，即可信任其中的信息，无需在自己的数据库中查找任何内容 。
5.相同点
- 根本目的：三者都是为了在无状态的 HTTP 协议上管理用户状态和身份，以实现连续的交互体验 。
- 初始流程：它们的认证流程通常都始于用户提交凭据（如用户名和密码）进行验证 。
- 客户端存储：都需要在客户端（浏览器）存储一些标识信息。无论是直接存储数据的 Cookie，存储 Session ID 的 Cookie，还是存储 Token，客户端都扮演着信息载体的角色 。
- 传输安全依赖：为了防止在传输过程中被窃听或篡改，三者都严重依赖于 HTTPS 加密通信。如果不使用 HTTPS，任何一种机制的安全性都会大打折扣 。
6.不同点
| Cookie | Session | Token | |
|---|---|---|---|
| 状态管理 | 客户端存储，可用于有状态或无状态场景 | 有状态：状态存储在服务器端 | 无状态：状态自包含于 Token 中，由客户端存储 |
| 数据存储位置 | 客户端（浏览器） | 服务器端（数据库、内存等） | 客户端（内存、localStorage、Cookie 等） |
| 可伸缩性 | —— | 差：难以在分布式系统中扩展 | 优秀：天然适用于微服务和分布式系统 |
| 性能 | —— | 较低：每次请求都需要服务器端数据库查询，增加延迟 | 较高：验证在内存中完成，速度快，但 Token 本身可能较大 |
| 安全性（撤销） | —— | 简单：在服务器端删除会话记录即可立即撤销 | 困难：在过期前难以撤销，需引入状态（如黑名单） |
| 安全性（攻击面） | 易受 CSRF 和 XSS 攻击，需通过SameSite 和 HttpOnly 等属性防御 |
依赖的 Cookie 易受 CSRF 攻击；也存在会话劫持和会话固定风险 | 若存储在localStorage，易受 XSS 攻击；若通过 Authorization 头发送，则对 CSRF 免疫 |
| 跨域（CORS） | 受同源策略限制，处理 CORS 较复杂 | 与 Cookie 相同 | 简单：通过 HTTP 头传输，不受同源策略限制，与 CORS 协作良好 |