【Linux网络】加餐：彻底搞懂 Cookie 与 Session：HTTP 无状态协议如何 “记住你”
目录
你一定经历过：关掉浏览器再开 B 站，依然是登录状态；刷视频时，网站自动知道你是不是 VIP；购物车关掉再打开还在……
这些神奇的 “记住我” 功能，背后全是 HTTP 会话保持 在支撑。
但是我们之前学习HTTP的时候，学到过：
HTTP协议是客户端与服务器之间通信的基础。客户端通过HTTP协议向服务器发送请求，服务器收到请求后处理并返回响应。HTTP协议是一个无连接、无状态的协议，即每次请求都需要建立新的连接，且服务器不会保存客户端的状态信息。
可 HTTP 明明是无状态、无连接的协议，它根本记不住你是谁啊？
这篇文章就用最通俗、最完整的逻辑，把 Cookie、Session、会话保持、HTTPS 抓包一次性讲透。
一开篇灵魂拷问：HTTP 为啥 “记不住你”？
在聊 Cookie 之前，先得弄明白 HTTP 的特性，因为这可是所有“会话问题”的根源。
- HTTP 是无连接的
HTTP 底层依赖 TCP 建立连接。
TCP 本身是有连接的，但 HTTP 并不保持连接。
每次发送请求，就像跟服务器“打一次招呼”，聊完就走，下一次再来得重新打招呼。 - HTTP 是无状态的
HTTP 不会记任何东西——它不会知道你之前访问过哪些页面，也不管你是不是登录了，更不会关心你是不是 VIP。
每次浏览器请求资源，都得重新把请求信息从头构造一遍。
重点来了：
HTTP ≠ 浏览器
- HTTP：只负责收发数据，不负责记忆
- 浏览器：帮你“记东西”，比如登录状态、购物车内容……
所以问题来了：
HTTP 本身记不住我，网站到底怎么认出我？
答案就是：Cookie + Session —— 它们帮你实现“会话保持”，让服务器知道“你是谁”。
把 Cookie 想象成你的“身份证”，每次发送请求时都带上它，服务器就知道“这个人是谁”；
而 Session 就像服务器里的“档案室”，存着你的信息和状态，让网站能连续记住你做了什么。
这样一来，HTTP 虽然无状态，但通过 Cookie + Session，就能实现“会话保持”，你在网站上的体验也就连贯起来了。
二 引入HTTP cookie
1 前提引入
那么b站是怎么记住我的？
根据我们对缓存和HTTP无状态的了解，所以这部分肯定不是只有HTTP完成，还有其他部分
我们回答第一个问题：网站怎么知道我是不是VIP？
因为后端可以对每一个用户的每一次请求进行权限认证
也就是说，每次你访问网站时，服务器都会检查你的身份信息（比如通过 Cookie + Session），判断你是否有 VIP 权限，从而决定允许访问哪些资源。
一个网站/后端服务，为什么要记住用户？
为了防止用户频繁进行验证，增加用户体验！这个功能，叫做会话保持功能！
那么这个会话保持功能是怎么做到的？
要理解这个话题，就要先搞懂原理。我们提供两种版本：
当后端完成用户认证后，需要告诉浏览器：“这是你身份的信息”。
为此，HTTP 提供了一个专门的报头：Set-Cookie。
后端在 HTTP Response 中设置 Set-Cookie，把用户信息放在 value 里，Set-Cookie就是key。
浏览器收到响应后，会解析 Set-Cookie，把信息保存起来，相当于服务器在浏览器端写了一份“身份证”。
之后，当浏览器再次访问同一网站（比如 www.billbill.com）时：浏览器会自动把 Cookie 信息附加到 HTTP Request 中发送给服务器。服务器收到请求后，就可以读取 Cookie，从而对用户进行身份验证和权限检查。
这种机制就是 Cookie 解决方案 —— 它让 HTTP 虽然无状态，但服务器仍能识别用户，保证每次请求都能安全、连续地进行访问控制。
2 解释cookie
含义：
HTTP Cookie（也称为Web Cookie、浏览器Cookie或简称Cookie）是服务器发送到用户浏览器并保存在浏览器上的一小块数据，它会在浏览器后续向同一服务器再次发起请求时被携带并发送到服务器上。通常，它用于告知服务端两个请求是否来自同一浏览器，可用来保持用户的登录状态、记录用户偏好等。
浏览器接收到Set-Cookie响应后，会自动存储Cookie数据，存放位置为浏览器专属目录文件或进程内存中。 这类Cookie存储文件无法直接查看，仅能在浏览器内进行查看操作。
如果你删除了浏览器中的 cookie 信息，服务器就无法识别你的身份，也就无法进行身份认证。Cookie 在浏览器中有两种常见的保存形式：
1. 内存级 Cookie：这种 Cookie 只保存在浏览器的内存中，会随着浏览器的关闭而消失，因此使用较少，适合短期会话数据。
2. 文件级 Cookie：这种 Cookie 会保存在浏览器的本地文件里，是更常见的保存方式。但它也不是永久保存的——每个 Cookie 文件中都包含一个 截止时间（deadline），一旦超过这个时间，浏览器会自动删除 Cookie。下次访问网站时，你就需要重新登录。
这种机制不仅存在于网站浏览器中，手机上的应用程序（APP）也是类似的：它们也会通过保存 Cookie 或类似的会话信息来识别用户身份，并在超过有效期后要求重新登录。
3 实验验证
我们来做实验验证一下：
（1）操作实验
设置里面是包含cookie信息的
Windows自带的edge浏览器，是能让我们看到cookie信息的 
在这个浏览器打开b站
如果删除掉这个cookie信息，那么客户端就没办法识别我们的身份，就会显示未登录
（2）代码实验
基本格式：
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：格林威治标准时区标识
#include <cpprest/http_listener.h>
#include <cpprest/http_msg.h>
#include <iostream>
using namespace web;
using namespace http;
using namespace http::experimental::listener;
int main() {
http_listener listener(U("http://localhost:8080/"));
listener.support(methods::GET, [](http_request request) {
// 读取 Cookie
if (request.headers().has(U("Cookie"))) {
auto cookie_header = request.headers()[U("Cookie")];
if (cookie_header.find(U("username=")) != std::wstring::npos) {
request.reply(status_codes::OK, U("欢迎回来！"));
return;
}
}
// 如果没有 cookie，设置一个新的 cookie
http_response response(status_codes::OK);
response.set_body(U("你好，新用户！已设置 cookie。"));
response.headers().add(U("Set-Cookie"), U("username=zyq; Max-Age=86400")); // 1 天有效
request.reply(response);
});
try {
listener.open().wait();
std::wcout << L"服务器启动在 http://localhost:8080/ ..." << std::endl;
std::string line;
std::getline(std::cin, line); // 按回车退出
listener.close().wait();
} catch (std::exception const& e) {
std::cerr << e.what() << std::endl;
}
return 0;
}但是如果只使用cookie会造成木马问题：
明文裸奔：纯 Cookie 存账号密码等敏感信息，木马一旦入侵你的设备，直接就能读取本地 Cookie 文件，轻松窃取你的账号权限。
篡改伪造：木马可以直接修改 Cookie 里的身份信息，伪造你的登录凭证，冒充你的身份操作账号，全程不需要知道你的密码。
盗号无门槛：就算不入侵设备，木马也能通过抓包拦截你的明文 Cookie，直接劫持你的会话，实现盗号、盗刷等恶意行为。
所以，纯 Cookie 把所有身份凭证裸奔存本地，木马能直接 “捡走” 你的账号，盗号几乎零门槛
这种纯cookie做法早就不是主流的做法，于是引入了session
三 引入HTTP session
在早期的 web 开发中，单纯依赖 Cookie 来存储用户信息已经不再是主流做法，因为这种方式存在安全风险和管理不便的问题。因此，引入了 Session 的概念。
1 Session 的工作原理
- 为每个用户分配 Session
当用户首次访问网站并成功登录后，服务器会为该用户创建一个session。这个session通常以文件、数据库或内存的形式保存在服务器端。session中主要保存用户的登录状态、权限信息以及其他必要的会话数据。 - 服务器端返回 Session ID 服务器通过 HTTP 响应的
Set-Cookie将session_id返回给客户端，例如：
浏览器接收到后，会自动保存这个 cookie。Cookie: sessionid=XXX - 浏览器自动携带 Session ID 用户在之后访问网站的任何页面时，浏览器都会在请求头中携带
Cookie: sessionid=XXX。服务器通过验证这个session_id来识别用户身份，而无需在客户端存储敏感信息。 - 服务器端验证 Session 服务器根据
session_id查找对应的 session 文件或数据记录。如果 session 存在且有效，用户即可继续访问，否则需要重新登录。
2 几个细节
什么叫做session？
session的本质是：把用户的私密登录信息，从浏览器端转移保存到服务器端
sessionid的特点：具有唯一性！它是浏览器与服务器之间的唯一会话凭证，就像你去酒店的房卡，一人一卡，卡和房间一一对应，别人的卡开不了你的门，你的卡也进不去别人的房间；
服务器要维护大量的session！要管理起来--->先描述，再组织（结构体或class）
当前主流的公司，不把session保存在文件里，而是保存在：
| 存储方案 | 核心优势 | 适用场景 |
|---|---|---|
| Redis | 纯内存级读写、高性能、支持过期自动清理、分布式共享 | 绝大多数互联网网站、高并发场景首选 |
| 其他 KV 数据库 | 高性能、易扩展、支持集群部署 | 大型分布式系统、跨服务器会话共享 |
| 关系型数据库（MySQL 等） | 数据持久化、高可靠 | 对会话数据持久化要求极高的金融、政务场景 |
会话管理是通过cookie+session共同完成的！
Cookie 是 “前端载体”：只负责在浏览器里存一个 SessionId（一串加密编号），不存任何用户敏感信息；
Session 是 “后端档案”：把用户的账号信息、权限、登录状态等核心数据，全部存在服务器端；
完整工作闭环：浏览器每次请求，都会自动带上 Cookie 里的 SessionId，服务器通过这个唯一编号，快速查到对应的 Session 档案，从而识别用户身份、维持登录状态
增加session不能完全避免盗号的情况，但是会提高盗号的门槛
3 HTTP的抓包工具
抓包原理：劫持了浏览器对目标网址的请求
浏览器内部维护两个环境变量：1.访问的目标网址 2. 目标资源所在的主机
代理软件的作用：
代理软件（如 Fiddler、HTK）在浏览器和目标网站之间充当中间人。 浏览器发送 HTTP 请求时，先到代理软件，代理软件再向目标网站发送请求。 返回的数据先到代理软件，再由代理转发给浏览器，这样就可以抓取本地报文。
3. 抓包流程示意
用户浏览器发出请求 → 代理软件接收并转发 → 目标网站响应 → 代理软件接收响应 → 浏览器显示内容。
代理软件可以记录请求头、请求体、响应头和响应体，方便分析
HTTP 明文传输问题
• 两台主机间通信时，如果没有使用加密技术（如 HTTPS），HTTP 数据是明文传输的。
• 攻击者或中间人可以直接截取、篡改或重放数据，存在安全风险。
两个主机网络通信的时候，如果没有用任何的加密技术，就从HTTP发送到另外⼀个HTTP；但是明文传送是不安全的，SSL内部包含加密算法和解密算法；HTTP把内容交给SSL，加密之后，把报文交给 对方的SSL，解密之后再交给HTTP。即使在传送的过程被抓包，应用层数据是被加密的，数据是安全的！HTTP+SSL=HTTPS
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目，面向数字基础设施四大核心场景（服务器、云计算、边缘计算、嵌入式），全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐
19
0- 0
已为社区贡献1条内容
所有评论(0)