Cookie，Session，Token

什么是 Cookie 和 Session 和Token?

什么是 Cookie

HTTP Cookie（也叫 Web Cookie或浏览器 Cookie）是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。Cookie 使基于无状态的 HTTP 协议记录稳定的状态信息成为了可能。

Cookie 主要用于以下三个方面：

• 会话状态管理（如用户登录状态、购物车、游戏分数或其它需要记录的信息）

• 个性化设置（如用户自定义设置、主题等）

• 浏览器行为跟踪（如跟踪分析用户行为等）

什么是 Session

Session 代表着服务器和客户端一次会话的过程。Session 对象存储特定用户会话所需的属性及配置信息。这样，当用户在应用程序的 Web 页之间跳转时，存储在 Session 对象中的变量将不会丢失，而是在整个用户会话中一直存在下去。当客户端关闭会话，或者 Session 超时失效时会话结束。

什么是 Token：

Token（通常指的是JWT，即JSON Web Tokens）是一种无状态的身份验证机制。它是一种紧凑且自包含的方式，用于在各方之间安全地传输信息。Token通常在用户登录后由服务器生成，并发送给客户端。客户端随后在每个请求中将Token作为Bearer令牌发送回服务器，以验证用户的身份。

Token包含了用户的身份信息和权限，因此它们不需要像Session那样在服务器上存储状态信息。Token可以存储在客户端的Cookie或LocalStorage中，也可以附加在请求的头部。Token可以存储在客户端，但身份验证信息存储在服务器。

Cookie 和 Session 是如何配合的呢？

用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。

当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

Cookie，Session和Token的区别？

• 作用范围：

  • Cookie：由浏览器管理，存储在用户本地，与特定的域关联，可以设置为仅与创建它的服务器通信。
  • Session：存储在服务器端，通过Session ID与客户端建立关联，用于跟踪用户的状态。
  • Token：通常在客户端存储（如LocalStorage或Cookie），在每次请求时发送到服务器，用于身份验证和授权。

• 存取方式：

  • Cookie：只能存储ASCII字符，适合存储非敏感信息。
  • Session：可以存储任意类型的数据，包括复杂的对象，适合存储用户状态信息。
  • Token：可以存储结构化数据，如JSON，包含用户的身份和权限信息。

• 有效期：

  • Cookie：可以设置为会话期间有效或长时间有效，取决于其过期时间的设置。
  • Session：通常与用户会话绑定，会话结束或超时后失效。
  • Token：具有明确的生命期，过期后需要重新获取。

• 隐私策略和安全性：

  • Cookie：存储在客户端，易受XSS和CSRF攻击，不应存储敏感信息。
  • Session：存储在服务器端，相对安全，但Session ID的安全性依赖于其传输和存储的安全性。
  • Token：包含敏感信息，需要安全存储和传输，通常通过HTTPS发送。

• 存储大小：

  • Cookie：单个Cookie大小受限，通常不超过4KB，浏览器对总Cookie数量也有限制。
  • Session：存储容量通常远大于Cookie，但受限于服务器的存储能力和Session管理方式。
  • Token：大小适中，足以存储必要的身份验证信息，但不会过大。

• 使用场景：

  • Cookie：适合用于跟踪用户的偏好设置、会话管理等。
  • Session：适合需要服务器端持久化用户状态的场景。
  • Token：适合无状态的API身份验证，如移动应用、单页面应用（SPA）和微服务架构。

• 安全性措施：

  • Cookie：应使用安全的Flag（如Secure、HttpOnly）来减少安全风险。
  • Session：应使用HTTPS来加密Session ID，并设置合理的超时时间。
  • Token：应使用难以猜测和复制的随机值，并通过HTTPS进行传输。

如何考虑分布式 Session 问题？

在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在 A 服务器登录了，第二次请求跑到服务 B 就会出现登录失效问题。

分布式 Session 一般会有以下几种解决方案：

• 客户端存储：直接将信息存储在cookie中，cookie是存储在客户端上的一小段数据，客户端通过http协议和服务器进行cookie交互，通常用来存储一些不敏感信息

• Nginx ip_hash 策略：服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。

• Session 复制：任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。

• 共享 Session：服务端无状态话，将用户的 Session 等信息使用缓存中间件（如Redis）来统一管理，保障分发到每一个服务器的响应结果都一致。

建议采用共享 Session的方案。