Cookie 机制

9月 14, 2025

我们来详细解析一下服务器和浏览器是如何协同管理 Cookie 的。Cookie 是维持 HTTP 无状态协议状态的关键技术，其管理机制涉及服务器创建、浏览器存储与发送、以及双方的安全约束。

整个管理过程可以概括为以下流程图：

flowchart TD
    A[用户访问浏览器] --> B[浏览器向服务器发起请求<br>请求头中通常无Cookie或携带相关Cookie]
    B -- 请求 --> C[服务器接收请求]
    
    C --> D{服务器需要设置Cookie?}
    D -- 是 --> E[服务器构建Response<br>加入Set-Cookie响应头]
    D -- 否 --> F[服务器生成正常响应]
    
    E --> F
    F -- 响应返回 --> G[浏览器接收响应]
    G --> H{响应中包含Set-Cookie头?}
    H -- 是 --> I[浏览器解析Set-Cookie指令<br>将键值对存储至对应域名下的Cookie库]
    H -- 否 --> J[处理页面其他资源]
    
    I --> J
    J --> K[后续向同域名发起请求]
    K --> L[浏览器根据规则自动匹配并添加Cookie请求头]
    L --> B

下面，我们分服务器和浏览器两个角色来详细阐述。

一、服务器的管理机制：设置 Cookie#

服务器是 Cookie 的创建者和规则制定者。它通过 HTTP 响应的 Set-Cookie 头部来指示浏览器创建、修改或删除一个 Cookie。

1. 发送 Set-Cookie 响应头#

当服务器希望浏览器保存一些状态信息时，它会在 HTTP 响应中添加一个或多个 Set-Cookie 头。

一个简单的例子：

HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abc123xyz456; Expires=Wed, 21 Oct 2025 07:28:00 GMT; Secure; HttpOnly
Set-Cookie: user_preference=dark_mode; Max-Age=3600; Domain=.example.com; Path=/

...（网页内容）

这个响应告诉浏览器要设置两个 Cookie。

2. 设置 Cookie 的属性（制定规则）#

服务器不仅设置 Cookie 的值，还通过属性来精确控制浏览器该如何处理这个 Cookie。关键属性如下：

• Expires 和 Max-Age：

  • Expires：指定一个绝对的过期时间（GMT 格式）。之后浏览器会自动删除该 Cookie。
  • Max-Age：指定一个相对的存活时间（单位：秒）。例如 Max-Age=3600 表示一小时后过期。优先级高于 Expires。
  • 如果都不设置，则该 Cookie 成为会话 Cookie（Session Cookie），生命周期仅限于当前浏览器会话（即浏览器关闭即失效）。

• Domain：

  • 指定哪些主机可以接收这个 Cookie。
  • 如果设置为 .example.com（注意开头的点），那么 Cookie 对 example.com 及其所有子域名（如 www.example.com, api.example.com）都有效。
  • 如果未设置，则默认为当前文档的主机（不包含子域名），安全性更高。

• Path：

  • 指定 URL 路径前缀，只有路径匹配时才会发送 Cookie。
  • 例如 Path=/shop，则 Cookie 对 /shop, /shop/cart, /shop/checkout 等路径有效，但对 /blog 无效。
  • 如果未设置，默认为当前请求的路径。

• Secure：

  • 这是一个布尔标志，没有值。
  • 如果设置，则 Cookie只能通过 HTTPS 加密连接发送给服务器。这防止了 Cookie 在明文传输中被窃听。

• HttpOnly：

  • 也是一个布尔标志。
  • 如果设置，Cookie 将无法通过客户端的 JavaScript document.cookie API 访问。这是至关重要的安全措施，可以有效防止跨站脚本（XSS）攻击窃取用户的敏感 Cookie（如会话 ID）。

• SameSite：

  • 控制 Cookie 在跨站请求时是否被发送。这是防御跨站请求伪造（CSRF）攻击的重要机制。
  • Strict：最严格，完全禁止在跨站请求中发送 Cookie。例如，从其他网站链接到你的网站，不会发送此类 Cookie。
  • Lax：现代浏览器的默认值。在大多数跨站导航（如点击链接）时会发送 Cookie，但在跨站图片加载、AJAX 请求等情况下不发送。提供了安全性和用户体验的平衡。
  • None：允许跨站发送 Cookie。必须同时设置 Secure 属性（即必须使用 HTTPS）。常用于需要跨站身份的场景（如第三方登录、嵌入式支付等）。

二、浏览器的管理机制：存储与发送#

浏览器是 Cookie 的仓库管理员和忠诚的信使，它严格按照服务器制定的规则行事。

1. 存储 Cookie#

• 当浏览器收到包含 Set-Cookie 头的 HTTP 响应时，它会解析其中的指令。
• 它会检查 Domain, Path, Secure 等属性，判断当前上下文环境是否允许存储这个 Cookie。
• 它将 Cookie 的名称、值、域、路径、过期时间、安全标志等作为一个整体数据项，存储在一个特殊的、按域名和路径组织的“Cookie 仓库”中。

2. 发送 Cookie（自动且智能）#

• 当浏览器向服务器发送 HTTP 请求时，它会自动执行以下操作：
  1. 匹配：检查请求的 URL（协议、域名、路径），与“Cookie 仓库”中的所有 Cookie 进行匹配。
  2. 过滤：筛选出所有满足条件的 Cookie（域名匹配、路径匹配、Secure Cookie 只能通过 HTTPS 发送）。
  3. 组装：将筛选出的所有 Cookie 的名称和值，用分号和空格拼接成一个字符串。
  4. 发送：将这个字符串放在 HTTP 请求的 Cookie 头部中。

一个请求的例子：

GET /dashboard HTTP/1.1
Host: www.example.com
Cookie: session_id=abc123xyz456; user_preference=dark_mode
...（其他头部）

• 注意：浏览器整个过程是自动的，用户无感知，Web 开发者通常也无需手动干预。

3. 管理 Cookie 的生命周期#

• 创建/更新：收到新的 Set-Cookie 头，且名称、域、路径与现有 Cookie 完全相同时，会覆盖更新原有的 Cookie。
• 过期删除：浏览器会定期检查所有 Cookie 的 Expires 和 Max-Age 属性，自动删除已过期的 Cookie。
• 会话结束删除：对于没有设置过期时间的会话 Cookie，浏览器关闭时会将它们全部删除。
• 手动删除：用户可以通过浏览器设置手动清除 Cookie。

三、安全性与隐私考量#

1. 大小限制：每个 Cookie 通常大小限制为 4KB。每个域名下的 Cookie 数量也有限制（通常 50个左右，因浏览器而异）。
2. 第三方 Cookie：
   • 如果 Cookie 的域与浏览器地址栏中显示的域不匹配，则称为第三方 Cookie。
   • 传统上用于广告追踪、嵌入式服务（如社交媒体插件）。
   • 由于隐私问题，现代浏览器（如 Safari 和 Firefox）已默认禁止第三方 Cookie，Chrome 也正在逐步淘汰中。
3. Cookie 与 XSS/CSRF：
   • HttpOnly 是防御 XSS 窃取 Cookie 的关键。
   • SameSite 是防御 CSRF 攻击的有效手段。

总结#

这种机制使得无状态的 HTTP 协议能够支持有状态的会话（如用户登录）、个性化设置、购物车等复杂功能，构成了现代 Web 应用的基础。同时，通过上述属性对 Cookie 进行严格配置，是保障 Web 应用安全的重要一环。