【Linux网络加餐】《HTTP 会话保持：Cookie 与 Session 原理及实验验证》---详解

发布时间：2026/10/25 2:02:11
【Linux网络加餐】《HTTP 会话保持：Cookie 与 Session 原理及实验验证》---详解

一.HTTP 会话保持

1.Cookie

HTTP 的特征如下：

  1. 简单快捷
  2. 无连接
  3. 无状态

HTTP 本身是无状态协议：协议层面不会保存客户端的历史访问信息，每一次 HTTP 请求都是独立的，服务器收到单次请求时，默认不知道这个请求来自哪个用户、之前有没有登录、浏览过哪些页面，请求和请求之间互相隔离、没有上下文关联。

但我们日常上网却有 “记住登录” 的体验，典型场景就是登录 CSDN 之后，关掉网页、甚至重启电脑，下次重新打开 CSDN 依旧保持登录状态，不用重复输入账号密码。这个能力并不是 HTTP 原生自带的，而是依靠Cookie来弥补无状态的缺陷。

Cookie 是服务器下发给浏览器、保存在本地的一小段文本数据。流程简单来说：

  1. 你第一次登录 CSDN，校验账号密码成功后，服务器通过响应头Set-Cookie，把携带身份标识的 Cookie 发给浏览器；
  2. 浏览器收到后，按域名保存这份 Cookie（可以设置过期时间，有的是会话 Cookie，关闭浏览器就失效；有的是持久 Cookie，会存到硬盘，重启电脑还在）；
  3. 之后你每次访问 CSDN 对应的域名，浏览器都会自动在请求头里带上属于这个网站的 Cookie，一起发给服务器；
  4. 服务器读取 Cookie 里面的身份凭证，识别出你就是之前登录过的用户，直接放行，不用再次登录。

我们看到的这些 cookie 数据实际都是对应的服务器方写的，如果你将对应的某些cookie 删除，那么此时可能就需要你重新进行登录认证了，因为你删除的可能正好就是你登录时所设置的 cookie 信息。

得出结论：会话保持不是 HTTP 协议天然具备的特点，而是浏览器为了满足用户的使用需求，做了相应的工作。

那它到底是怎么实现的呢？

用户首次提交账号密码完成登录校验后，并不是浏览器直接保存用户名和密码。服务器验证信息无误后，会下发 Cookie 给浏览器保存。之后用户再次访问该网站、发起 HTTP 请求时，浏览器会自动把属于这个站点的 Cookie 放到请求头里，一同发送给服务器。服务器通过 Cookie 里的身份标识识别用户，所以在有效期内，不需要重复输入账号密码登录。

用来维持这种状态的技术就是 Cookie。Cookie 分为两类：会话 Cookie（内存 Cookie）和持久 Cookie（文件 Cookie）。

(1)引入 HTTP Cookie

a.定义

HTTP Cookie（也叫 Web Cookie、浏览器 Cookie，常直接简称 Cookie），是服务器下发到用户浏览器、并保存在浏览器本地的一小段数据。后续浏览器向同一个服务器发起请求时，会自动携带这份 Cookie 发送给服务端。 它的核心作用：让服务端识别多次请求是否来自同一个浏览器，典型场景就是维持用户登录状态、保存用户个性化偏好等。

b.工作原理

  1. 用户首次访问网站，服务器在 HTTP 响应头中添加Set-Cookie字段，把 Cookie 下发给浏览器；
  2. 浏览器收到 Cookie，按照域名分类保存在本地；
  3. 后续访问同源网站发起请求时，浏览器自动在 HTTP 请求头带上对应的 Cookie，发给服务器。

c.用途

  1. 用户认证与会话管理（最重要用途）
  2. 用户行为跟踪统计
  3. 缓存用户页面偏好、主题设置等

Chrome 浏览器快速查看 Cookie 地址：chrome://settings/cookies

e.HTTP 头部：Set-Cookie

Set-Cookie是响应头，由服务器返回给浏览器，浏览器识别后保存 Cookie。 基础语法：

Set-Cookie: <name>=<value>
  • name：Cookie 名称
  • value：Cookie 存储的值

完整示例：

Set-Cookie: username=peter; expires=Thu, 18 Dec 2024 12:00:00 UTC; path=/; domain=.example.com; secure; HttpOnly

f.时间格式规范

时间格式必须遵守RFC 1123标准，具体格式样例： Tue, 01 Jan 2030 12:34:56 GMT或者
UTC(推荐) 。关于时间解释

  • Tue: 星期⼆（星期⼏的缩写）
  • ,: 逗号分隔符
  • 01: ⽇期（两位数表⽰）
  • Jan: ⼀⽉（⽉份的缩写）
  • 2030: 年份（四位数）
  • 12:34:56: 时间（⼩时、分钟、秒）
  • GMT: 格林威治标准时间（时区缩写）

GMT 和 UTC 小科普（了解）

GMT（格林威治标准时间）：基于地球自转，现在已经不再作为官方标准时间；

UTC（协调世界时）：基于原子钟计时，精度极高，是网络、计算机系统通用的标准时间。 绝大多数场景下二者数值几乎一致，可以互换；高精度场景优先使用 UTC。

g.Set-Cookie 可选属性说明

表格

属性说明
expires=<date>设置 Cookie 过期时刻；不配置则默认是会话 Cookie，关浏览器失效
path=<路径>限制 Cookie 发送的路径范围，默认是当前设置 Cookie 的路径；path=/代表全站生效
domain=<域名>指定可以接收该 Cookie 的域名；带前缀.代表包含所有子域名
secure只有 HTTPS 请求才会携带这个 Cookie，防止在 HTTP 明文传输时被劫持
HttpOnly禁止前端 JS 脚本读取该 Cookie，用来防御 XSS 跨站脚本攻击

h.书写注意事项

  • 多个属性之间用;（分号 + 空格）隔开；
  • Cookie 的名称和值使用=连接；
  • 如果 name /value 包含空格、分号、逗号这类特殊字符，必须做 URL 编码。

i.Cookie 生命周期

  1. 配置expires：到达指定时间后 Cookie 自动过期失效；
  2. 未配置expires：属于会话 Cookie，浏览器进程关闭就销毁。

（2）内存级 Cookie 和文件级 Cookie

Cookie 是浏览器用来存储站点相关数据的载体，分为内存级 Cookie（会话 Cookie）和文件级 Cookie（持久 Cookie）。

  • 内存级 Cookie：保存在浏览器内存里，不会写入磁盘。一旦关闭浏览器进程，这份 Cookie 就会直接销毁。下次再打开网站访问，就需要重新登录。
  • 文件级 Cookie：以文件形式保存在本地磁盘中，带有指定过期时间。就算关闭浏览器、重启电脑，只要 Cookie 还没到期，访问网站时依旧有效，可以保持登录状态。

（3）Cookie 安全问题

如果本地存储的 Cookie 被攻击者窃取，不法分子就可以携带这份 Cookie，冒充我们的身份访问对应网站，这就是Cookie 劫持（Cookie 被盗取）。

为降低风险，我们可以把用户的核心登录信息存放在服务端，也就是Session。服务端会为每一个登录用户生成独立的 Session 数据，并分配唯一标识Session ID。服务器只把这个 Session ID 返回给浏览器，浏览器再把 Session ID 存进 Cookie 中。后续每次请求，浏览器自动带上 Cookie 里的 Session ID；服务器拿到 Session ID，去服务端查找对应的 Session 数据，完成身份鉴权。

这种方式下，用户真实信息不会放在 Cookie 里，避免敏感信息随 Cookie 泄露。安全防护还可以依靠服务端策略：比如检测到异地登录时，服务端主动让这个 Session ID 失效。失效之后，就算攻击者拿到 Session ID 也无法使用，网站会要求重新验证账号密码、短信或者人脸，以此确认操作者是本人，提升安全性。

(4) 实验测试cookie

Cookie 负责在客户端存储、传递 Session ID；Session 负责在服务端存放真实的用户会话数据，二者配合，就实现了 HTTP 无状态环境下的登录保持能力。

2.Session

(1)引入 HTTP Session

承接上文 Cookie，为后续登录验证流程做铺垫

定义

HTTP Session 是服务端用于跟踪用户、保存用户交互状态的机制。HTTP 本身是无状态协议，每一次请求相互独立，服务端无法自动识别请求归属哪个用户，所以依靠 Session 在服务端侧记录用户会话信息。

工作原理

  1. 用户首次登录访问站点，服务端为该用户生成全局唯一的Session ID；
  2. 服务端把 Session ID 通过Set-Cookie响应头下发给浏览器，由浏览器保存在本地 Cookie 中；
  3. 用户后续发起请求时，浏览器自动携带 Cookie 里的 Session ID；
  4. 服务端拿到 Session ID，查询对应的会话数据，完成用户身份识别；
  5. Session 的实际数据，一般存放在服务端内存、Redis 缓存或者数据库中。

安全性

Session ID 会在客户端和服务端之间传输，因此同样存在被窃取劫持的风险。 和直接把用户信息放进 Cookie 相比有明显优势：就算 Cookie 被盗，攻击者拿到的仅仅是 Session ID，用户的敏感信息本身保存在服务端，不会直接泄露。 同时服务端拥有更强的管控能力：例如检测到异地登录时，可以主动销毁对应 Session ID，使旧会话直接失效。 配套防护手段：使用 HTTPS 加密传输，同时给存放 SessionID 的 Cookie 设置HttpOnly、Secure属性，降低被窃取的概率。

超时与失效

  • 可以配置 Session 超时时间：长时间无操作，Session 自动过期失效；
  • 支持服务端主动销毁 Session：典型场景就是用户点击登出操作。

用途

  1. 用户身份认证与会话管理（核心用途）
  2. 临时业务数据存储，例如购物车、临时表单数据
  3. 分布式场景会话共享：把 Session 数据放到公共缓存 / 数据库，多台服务器可以共用同一份会话信息

(2）实验测试cookie

1.访问/login, 模拟登录

2.两个浏览器访问任意的站点资源

3.总结：

HTTP Cookie和Session都是⽤于在Web应⽤中跟踪⽤⼾状态的机制。Cookie是存储在客户端的，而Session是存储在服务器端的。它们各有优缺点，通常在实际应⽤中会结合使⽤，以达到最佳的用户体验和安全性。