cookie

定义

cookie是服务器发送到用户浏览器并保存在本地的一小块数据，浏览器在之后访问同一服务器时会把它一并发出^[1]。它也叫 Web cookie 或浏览器 cookie，属于 HTTP 协议范畴内的状态管理机制，现行技术规范为 RFC 6265。

从形式上看，一个 cookie 由名称和值组成的键值对开头，后面可以附带若干个属性，用于限定它的生效域名、路径、有效期和发送条件^[2]。名称与值以文本形式存放，不含可执行代码；除名称和值之外的属性只供浏览器判断何时发送，通常不会随请求回传给服务器^[3]。

按照存放时间和位置的不同，cookie 可分为两类：没有设置过期时间或有效期的称为会话 cookie，浏览器关闭后一般被清除，多存于内存；设置了 Expires 或 Max-Age 的称为持久性 cookie，可写入硬盘并在期限内长期保留^[4]。

原理

cookie 的运作依赖请求与响应两个方向的头部字段。服务器在响应中加入 Set-Cookie 头，写入名称、值与各项属性；浏览器解析后按域名和路径归档保存。此后凡是满足匹配条件的请求，浏览器都会自动在 Cookie 请求头中填入对应的键值对，无需页面脚本介入^[5]。一个响应中可以出现多个 Set-Cookie 头，以同时下发多个 cookie^[6]。

整个过程可以概括为下图的循环：

sequenceDiagram

participant B as 浏览器

participant S as 服务器

B->>S: 首次请求(无 cookie)

S->>B: 响应 + Set-Cookie: 名称=值; 属性

Note over B: 按域名、路径存储

B->>S: 后续请求 + Cookie: 名称=值

S->>B: 依据 cookie 识别状态并响应

决定 cookie 是否随请求发出的属性主要有以下几项。Domain 指定生效的主机，省略时默认为当前文档所在主机且不含子域名，显式设置后子域名也可共享；Path 要求请求路径落在指定范围之内^[7]。Expires 给出失效的具体时刻，Max-Age 给出以秒计的有效期，两者同时存在时以 Max-Age 为准，取 0 或负数则立即失效^[2]。

安全相关属性包括三项。Secure 使 cookie 只在 HTTPS 请求中发送；HttpOnly 禁止 JavaScript 通过 document.cookie 读取，以缓解跨站脚本攻击(XSS)；SameSite 控制跨站请求是否携带 cookie，取值有 Strict、Lax、None 三种，可用于防御跨站请求伪造(CSRF)，其中 None 必须与 Secure 同时使用^[1]。未声明 SameSite 时，现行浏览器默认按 Lax 处理^[5]。

域名、路径、有效期与 Secure 等属性只在浏览器侧起作用，真正随请求回传的通常仅有名称与值这一对数据^[3]。

发展历程

cookie 的诞生与早期网页的交互需求直接相关。HTTP 本身不保存状态，服务器无法分辨连续请求是否出自同一客户端，购物车一类跨页面操作因此难以实现。1994 年，供职于网景(Netscape)的卢·蒙图利(Lou Montulli)借鉴操作系统中的“magic cookie”概念设计了这一机制，同年随 Netscape 浏览器发布，并公开了规范供其他浏览器实现。

设计时刻意回避了给每个浏览器分配统一编号的做法，而把 cookie 限定在单一域名之内，使不同站点之间无法彼此读取。但网页内嵌的第三方资源同样可以携带和读取 cookie，20 世纪 90 年代中后期广告网络借此在多个网站之间识别同一浏览器，跨站跟踪问题随之出现^[8]。

标准化进程随后展开。1997 年 2 月发布的 RFC 2109 对机制作出正式描述，并新增 Max-Age 等属性^[8]。2011 年发布的 RFC 6265 取代早期规范，按浏览器实际实现的方式记录 cookie 与 Set-Cookie 两个头部字段，成为现行的基础标准。此后 SameSite 属性进入规范草案，成为对跨站请求加以约束的主要手段^[2]。

本地存储的需求后来由新方案分担。HTML5 引入的 localStorage 与 sessionStorage 提供更大的容量，且数据不会随每次请求自动上传，cookie 的存储职能因而逐步收窄至会话标识等少量信息^[9]。

应用

最常见的用途是会话状态管理。用户登录后，服务器下发携带会话标识的 cookie，此后每次请求都由浏览器自动带回，服务器据此判断请求归属的账户，页面不必反复要求输入凭据^[10]。购物车内容、游戏进度等需要跨页面保持的信息也常借此保存。

其次是保存个性化设置，例如界面主题、语言偏好等用户自定义选项。此外，cookie 也被用于访问行为的统计与分析，即记录同一浏览器在多处的浏览轨迹。

在客户端一侧，脚本可以通过 document.cookie 读写 cookie，但这一接口只能一次取得全部非 HttpOnly 的条目，操作并不便利，实践中多由服务端下发^[11]。由于脚本接口简陋，开发者常借助封装库来简化增删改查^[12]。

局限

容量是最基本的限制。单个 cookie 的名称与值合计通常不超过 4KB，超出部分会被截断，因此不适合存放较大数据。浏览器还对单个域名下的 cookie 数量设有上限，一般不超过数十条，总数超过限制时浏览器会按各自策略删除旧条目，不同产品表现并不一致^[4]。

性能开销来自自动发送机制。同一域名下的所有请求都会附带 cookie，包括图片、样式表、脚本等静态资源请求，这些请求往往并不需要其中的信息，累积起来会加大请求头部体积^[12]。这一开销无法由页面自行取消。

安全方面的约束同样明显。cookie 在 HTTP 传输中可被截获，若未使用 HTTPS，其中的内容可能被读取或篡改^[11]。脚本注入可读取未标记 HttpOnly 的 cookie，跨站请求则可借浏览器自动携带的特性冒用身份，这正是 HttpOnly 与 SameSite 属性的由来^[4]。

此外，会话 cookie 的清除并不完全可靠。部分浏览器具备会话恢复功能，关闭后重新打开时会把会话 cookie 一并恢复，使其保存时间超出预期^[1]。过期时刻以客户端系统时间为准计算，客户端时间被改动也会影响判定^[4]。

参见

• Web Storage —— 包含 localStorage 与 sessionStorage 的浏览器本地存储接口，容量大于 cookie 且不随请求发送。

• 会话标识 —— 常被写入 cookie 的随机字符串，用于在服务端关联同一用户的多次请求。

• 跨站请求伪造 —— 利用浏览器自动携带 cookie 的特性冒充用户发起请求的攻击方式。

• 跨站脚本攻击 —— 向页面注入脚本以读取数据的手段，HttpOnly 属性即针对此类风险。

• 超文本传输协议 —— cookie 赖以传输的协议，其本身不保存状态。