HTTP中的cookie

目录

前言

[引入 HTTP Cookie](#引入 HTTP Cookie)

定义

工作原理

分类

安全性

用途

[认识 cookie](#认识 cookie)

基本格式

[完整的 Set-Cookie 示例](#完整的 Set-Cookie 示例)

关于时间解释

注意事项

[Cookie 的生命周期](#Cookie 的生命周期)

安全性考虑[了解即可]

[实验测试 cookie](#实验测试 cookie)

[测试 cookie 写入到浏览器](#测试 cookie 写入到浏览器)

[单独使用 Cookie，有什么问题？](#单独使用 Cookie，有什么问题？)

[1. 安全风险突出](#1. 安全风险突出)

[2. 性能与存储限制](#2. 性能与存储限制)

[3. 功能局限性明显](#3. 功能局限性明显)

---

前言

我们来思考一种关于登录的场景演示 - B 站登录和未登录

• 问题： B 站是如何认识我这个登录用户的？
• 问题： HTTP 是无状态， 无连接的， 怎么能够记住我？

我们带着这两个问题来开启下文

引入 HTTP Cookie

定义

HTTP Cookie（也称为 Web Cookie、 浏览器 Cookie 或简称 Cookie） 是服务器发送到用户浏览器并保存在浏览器上的一小块数据， 它会在浏览器之后向同一服务器再次发起请求时被携带并发送到服务器上。 通常， 它用于告知服务端两个请求是否来自同一浏览器， 如保持用户的登录状态、 记录用户偏好等。

工作原理

• 当用户第一次访问网站时，服务器会在响应的 HTTP 头中设置 Set-Cookie

  字段，用于发送 Cookie 到用户的浏览器。

• 浏览器在接收到 Cookie 后，会将其保存在本地（通常是按照域名进行存储）。

• 在之后的请求中，浏览器会自动在 HTTP 请求头中携带 Cookie 字段，将之前保存的 Cookie 信息发送给服务器。

分类

• 会话 Cookie（Session Cookie）：在浏览器关闭时失效。
• 持久 Cookie（Persistent Cookie）：带有明确的过期日期或持续时间， 可以跨多个浏览器会话存在。
• 如果 cookie 是一个持久性的 cookie，那么它其实就是浏览器相关的，特定目录下的一个文件。但直接查看这些文件可能会看到乱码或无法读取的内容， 因为 cookie 文件通常以二进制或 sqlite 格式存储。一般我们查看，直接在浏览器对应的选项中直接查看即可。

类似于下面这种方式：

安全性

• 由于 Cookie 是存储在客户端的，因此存在被篡改或窃取的风险。

用途

• 用户认证和会话管理(最重要)
• 跟踪用户行为
• 缓存用户偏好等
• 比如在 chrome 浏览器下，可以直接访问：chrome://settings/cookies

认识 cookie

• HTTP 存在一个报头选项：Set-Cookie, 可以用来进行给浏览器设置 Cookie

  值。

• 在 HTTP 响应头中添加，客户端（如浏览器）获取并自行设置并保存

  Cookie。

基本格式

Set-Cookie: <name>=<value>

其中 <name> 是 Cookie 的名称，<value> 是 Cookie 的值。

完整的 Set-Cookie 示例

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

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

关于时间解释

• Tue: 星期二（星期几的缩写）
• ,: 逗号分隔符
• 01: 日期（两位数表示）
• Jan: 一月（月份的缩写）
• 2030: 年份（四位数）
• 12:34:56: 时间（小时、分钟、秒）
• GMT: 格林威治标准时间（时区缩写）

GMT vs UTC --- 以下内容，均来自文心一言，了解即可

GMT（格林威治标准时间）和 UTC（协调世界时）是两个不同的时间标准，但它们在大多数情况下非常接近，常常被混淆。以下是两者的简单解释和区别：

1. GMT（格林威治标准时间）：

￮ GMT 是格林威治标准时间的缩写，它是以英国伦敦的格林威治区为基准的世界时间标准。

￮ GMT 不受夏令时或其他因素的影响，通常用于航海、航空、科学、天文等领域。

￮ GMT 的计算方式是基于地球的自转和公转。

2. UTC（协调世界时）：

￮ UTC 全称为"协调世界时"，是国际电信联盟(ITU)制定和维护的标准时间。

￮ UTC 的计算方式是基于原子钟，而不是地球的自转，因此它比 GMT 更准确。据称，世界上最精确的原子钟 50 亿年才会误差 1 秒。

￮ UTC 是现在用的时间标准，多数全球性的网络和软件系统将其作为标准时间。

GMT 和 UTC 的英文全称以及相关信息如下：

1. GMT（格林尼治标准时间）

￮ 英文全称：Greenwich Mean Time

￮ GMT 是指位于英国伦敦郊区的皇家格林尼治天文台的标准时间，因为本 初子午线被定义为通过那里的经线。理论上来说，格林尼治标准时间的正午是 指当太阳横穿格林尼治子午线时的时间。

￮ 但值得注意的是，地球的自转是有些不规则的，且正在缓慢减速。因此，格林尼治时间已经不再被作为标准时间使用。

2. UTC（协调世界时）

￮ 英文全称：Coordinated Universal Time

￮ UTC 是最主要的世界时间标准，其以原子时秒长为基础，在时刻上尽量接近于格林尼治标准时间。

￮ UTC 被广泛使用在计算机网络、航空航天等领域，因为它提供了非常准 确和可靠的时间参考。 总结来说，GMT 和 UTC 都曾是或现在是国际上重要的时间标准，但由于地球自转 的不规则性和原子钟的精确性，UTC 已经成为了全球性的标准时间，而 GMT 则更 多被用作历史和地理上的参考。

区别：

计算方式：GMT 基于地球的自转和公转，而 UTC 基于原子钟。

准确度：由于 UTC 基于原子钟，它比基于地球自转的 GMT 更加精确。

在实际使用中，GMT 和 UTC 之间的差别通常很小，大多数情况下可以互换使用。但在需要高精度时间计量的场合，如科学研究、网络通信等，UTC 是更为准确的选择。

关于其他可选属性的解释

￮ expires=：设置 Cookie 的过期日期/时间。如果未指定此属性，则 Cookie 默认为会话 Cookie，即当浏览器关闭时过期。

￮ path=：限制 Cookie 发送到服务器的哪些路径。默认为设置它的路径。

￮ domain=：指定哪些主机可以接受该 Cookie。默认为设置它的主机。

￮ secure：仅当使用 HTTPS 协议时才发送 Cookie。这有助于防止Cookie 在不安全的 HTTP 连接中被截获。

￮ HttpOnly：标记 Cookie 为 HttpOnly，意味着该 Cookie 不能被客户端脚本（如 JavaScript）访问。这有助于防止跨站脚本攻击（XSS）。

以下是对 Set-Cookie 头部字段的简洁介绍

注意事项

￮ 每个 Cookie 属性都以分号（;）和空格（ ）分隔。

￮ 名称和值之间使用等号（=）分隔。

￮ 如果 Cookie 的名称或值包含特殊字符（如空格、分号、逗号等），则需要进行 URL 编码。

Cookie 的生命周期

￮ 如果设置了 expires 属性，则 Cookie 将在指定的日期/时间后过期。

￮ 如果没有设置 expires 属性，则 Cookie 默认为会话 Cookie，即当浏览器关闭时过期。

安全性考虑[了解即可]

￮ 使用 secure 标志可以确保 Cookie 仅在 HTTPS 连接上发送，从而提高安 全性。

￮ 使用 HttpOnly 标志可以防止客户端脚本（如 JavaScript）访问 Cookie， 从而防止 XSS 攻击。

￮ 通过合理设置 Set-Cookie 的格式和属性，可以确保 Cookie 的安全性、有效 性和可访问性，从而满足 Web 应用程序的需求。

实验测试 cookie

我们这里就拿我们之前写的http服务器来测试

测试 cookie 写入到浏览器

由我们的http应答也能看出cookie是能被我们设置进浏览器的。

单独使用 Cookie，有什么问题？

1. 安全风险突出

• 容易被窃取和篡改：Cookie 存储在客户端，可通过 XSS 跨站脚本攻击读取。攻击者能借此冒充用户身份，进行非法操作。
• CSRF 跨站请求伪造风险：Cookie 会随请求自动发送到服务器。恶意网站可诱导用户点击链接，利用用户已登录的 Cookie 发起未授权请求。
• 明文存储隐患 ：若未开启 HttpOnly 和 Secure 属性，Cookie 内容以明文形式存在，敏感信息如用户 token 会直接暴露。

2. 性能与存储限制

• 存储容量小：单个 Cookie 大小限制在 4KB 左右，无法存储大量数据。
• 增加请求开销：每次 HTTP 请求都会携带 Cookie 数据。即使请求静态资源如图片、CSS，也会额外传输 Cookie，增大带宽消耗并降低请求速度。
• 数量限制：浏览器对单个域名下的 Cookie 数量有限制，超出后旧 Cookie 会被覆盖。

3. 功能局限性明显

• 跨域不支持：Cookie 受同源策略限制，无法在不同域名之间共享数据。这对分布式系统或前后端分离架构不友好。
• 易被用户清除：用户可手动清除浏览器 Cookie，导致存储的会话状态、用户偏好等数据丢失。
• 不适合存储复杂数据：Cookie 仅支持字符串格式，无法直接存储对象、数组等复杂数据结构，需要额外序列化和反序列化操作。