HTTP请求中的Cookie：概念、特点和应用场景详解

HTTP请求中的Cookie：概念、特点和应用场景详解

引用

CSDN

1.

https://blog.csdn.net/2402_84916296/article/details/146146751

Cookie是Web开发中的基础概念，它在维持用户登录状态、记录用户偏好等方面发挥着重要作用。本文通过生动的比喻和详细的步骤解析，帮助读者深入理解Cookie的工作原理及其在登录和用户认证中的应用。

网络原理—HTTP请求“报头”(header)

Cookie 是什么

HTTP报头中的Cookie，用大白话来说，就像你
去餐厅吃饭时拿到的一张会员卡：

初次访问 (清除该网站的所有 Cookie 后重新访问该网站，效果相同)：

• 当你第一次访问一个网站（比如某购物网站），
  服务器
  想记住你（比如你的登录状态、购物车）。
• 但服务器
  没法直接在你电脑上存东西
  ，于是它说：“
  浏览器
  ，帮我记个
  小纸条
  吧！”这个“小纸条”就是Cookie。

服务员发卡（Set-Cookie）：

• 服务器通过HTTP响应的
  Set-Cookie
  头，把信息塞给
  浏览器
  。比如：
  Set-Cookie: user_id=12345; Expires=周五; Secure
• 这相当于
  餐厅
  给你一张
  会员卡
  ，卡上写：“用户ID是12345，有效期到周五，且只能在本店安全通道使用”。

自动出示会员卡（Cookie请求头）：

• 之后每次你再访问这个网站，
  浏览器会自动在HTTP请求头里带上这个 Cookie
  ，像进餐厅时主动亮出会员卡。
• 服务器一看：“哦，是用户12345，直接显示他的购物车！”

Cookie能存啥：

• 小数据：
• 比如用户名、语言设置、浏览记录。
• 关键ID：
• 比如登录后的会话ID（像会员卡号，服务器靠它查你的详细信息）。

Cookie的安全细节：

• 过期时间：
• 可以是“关浏览器就失效”（会话Cookie），或设定具体日期（比如记住登录30天）。
• Secure：
• 只通过HTTPS加密连接传输（防窃听）。
• HttpOnly：
• 禁止JavaScript读取（防XSS攻击偷Cookie）。
• 作用范围：
• 指定域名（比如只给
  .example.com
  ）和路径（比如
  /shop
  目录下才发送）。

举个实际例子：

• 你登录微博，服务器返回
  Set-Cookie: session_id=abc123; HttpOnly; Secure
  。
• 之后你刷主页、发微博，
  浏览器每次请求都悄悄带上
  Cookie: session_id=abc123
  。
• 服务器通过
  abc123
  查到你是张三，直接展示你的关注和私信。

注意事项：

• Cookie存在你电脑里，别让坏人偷走（比如通过
  恶意链接盗取会话Cookie，就能冒充你
  ）。
• 网站要合理设置
  Secure
  和
  HttpOnly
  ，用户也要警惕不明网站。

总结：

Cookie 就是网站让你的浏览器帮忙记的小纸条
，下次访问该网站时自动带上，让服务器认出你。

• 它像会员卡、临时身份证，是
  维持登录状态、记录偏好的关键工具
  ，但也要注意安全保管！

Cookie 的特点

Cookie 轻量化与兼容性

• 文本格式：
• Cookie以
  键值对形式
  存储
  纯文本
  ，确保跨平台兼容性。
• 容量限制：
• 单个Cookie大小通常不超过
  4KB
  ，单个域名下Cookie数量受限（如50条），避免过度占用资源。

Cookie 作用域控制

通过
Domain
和
Path
属性限制Cookie的生效范围：

• Domain：
• 指定 Cookie 可发送的域名；
• 每个
  不同的域名
  下都可以有不同的 Cookie，不同网站之间的 Cookie 并不冲突；
• Path：
• 限定仅特定路径下的请求携带Cookie（如
  /user
  路径）。

Cookie 客户端存储与自动传输

• Cookie的核心设计是通过
  客户端（浏览器）
  存储
  少量数据
  （如用户标识符）；
  Cookie 中
  存储了一个字符串
  ；
• 这个数据可能是
  客户端(网页)
  自行通过
  JS
  写入的；
• 也可能来自于
  服务器
  （服务器在
  HTTP响应
  的header中，通过
  Set-Cookie
  字段给浏览器返回数据）；

我们先打开一个浏览器搜索页面，并且清空 Cookie ：
清空 fiddler 中的左侧 HTTP 请求/响应结果，再刷新页面，查看 fiddler 新抓包的请求和响应结果：

我们可以看到，在
响应结果
中显示的
Set-Cookie
的
key=value
，和浏览器中的
Cookie
相对应，说明
服务器
通过
Set-Cookie响应头
设置Cookie：

浏览器在后续请求中
自动回传
，形成“
请求-响应-携带
”的闭环：

在后续请求中，Cookie 会
自动附加到HTTP头部
（
Cookie
头）。

cookie 的灵活性 (生命周期管理)

• 会话Cookie：默认在浏览器关闭后失效。
• 持久Cookie：可以灵活通过
  Expires
  或
  Max-Age
  设置过期时间，实现长期状态保留（如“记住登录”）。

清除 Cookie 的方法

或者

Cookie 的应用场景：登录和用户认证 (以码云为例)

(1)在码云页面上，清除 Cookie

为了方便观察，先清除掉之前登陆的 Cookie ；

在码云页面上，点击 URL 左侧的图标，选择 Cookie

清除 Cookie 后，再次刷新页面，Cookie 会重新从
服务器
加载回来：

(2) 登陆操作

登陆请求

登陆响应

可以看到，响应中包含了3个
Set-Cookie
属性.

其中我们重点关注第三个，里面包含了一个
gitee-session-n
这样的属性，属性值是一串很长的加密之后的信息；

这个信息就是
用户当前登陆的身份标识
，也称为"
令牌(token)
"

(3) 访问其他页面

登陆成功之后，此时可以看到后续访问码云的其他页面 (比如个人主页)，
请求
中就都会带着刚才获取到的
Cookie 信息

• 请求你中的 Cookie 字段也包含了一个
  gitee-session-n
  属性，里面的值和刚才服务器返回的值相同；
• 后续只要访问 gitee 这个网站，就会一直带着这个令牌，直到
  令牌过期/下次重新登陆

(4) 理解登陆过程

这个过程和
去医院看病
很相似：

1. 到了医院先挂号：挂号时候需要提供身份证，同时得到了一张"就诊卡"，这个
   就诊卡(sessionId)
   就相当于患者的
   "令牌"
   ；

2. 后续去各个科室进行检查，诊断，开药等操作，都不必再出示身份证了，只要凭就诊卡即可识别出当前患者的身份.

3. 看完病了之后，不想要就诊卡了，就可以注销这个卡；

4. 此时患者的
   身份
   和
   就诊卡
   的关联就销毁了；(类似于网站的注销操作)

5. 又来看病，可以办一张新的就诊卡，此时就得到了一个新的"令牌"