目录
[2.Cookie 与 Session](#2.Cookie 与 Session)
[Cookie 与 Session 的协作流程](#Cookie 与 Session 的协作流程)
1.无状态性
**定义：**HTTP 协议默认不记录用户状态，每次请求独立，服务器无法直接识别请求来源的用户身份
**本质：**协议设计上，服务器不存储客户端的上下文信息，所有请求需携带完整数据（如认证信息）
影响：
**优点：**简化服务器设计
**缺点：**需通过额外机制（如 Cookies、Session、Token）管理状态
# 首次请求（无状态）
GET /login HTTP/1.1
Host: example.com
# 服务器返回登录页面（仍无状态）
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123 # 通过Cookie传递状态
# 后续请求携带Cookie（模拟有状态）
GET /dashboard HTTP/1.1
Host: example.com
Cookie: session_id=abc1232.Cookie 与 Session
2.1.Cookie
- 定义
Cookie 是 服务器发送到用户浏览器并存储在客户端的小型文本文件 ，用于在多次请求间传递数据（如会话标识、用户偏好等）。
核心作用：解决 HTTP 无状态性问题，使服务器能识别用户身份
浏览器->>服务器: 首次请求（无Cookie）
服务器-->>浏览器: 响应头 Set-Cookie: session_id=abc123
浏览器->>服务器: 后续请求（携带 Cookie: session_id=abc123）
服务器-->>浏览器: 根据 session_id 返回对应资源- 特性
**存储位置：**客户端（浏览器内存或文件系统）
**内容：**键值对（如 name=value），可设置多个属性：
- Expires/Max-Age：过期时间（未设置则为会话级 Cookie，关闭浏览器失效）
- Domain/Path：限定 Cookie 的生效范围
- Secure：仅通过 HTTPS 传输
- HttpOnly：禁止 JavaScript 访问（防 XSS 攻击）
- SameSite：限制跨站请求携带 Cookie（防 CSRF 攻击）
- 优缺点
减少服务器存储压力（数据在客户端），支持跨页面状态保持（如购物车、主题偏好）
但明文存储可能被窃取（需加密/HttpOnly），单个 Cookie 通常不超过 4KB，域名下数量有限，每次请求携带 Cookie，增加网络开销
2.2.Session
- 定义
Session 是 服务器为每个用户会话创建的存储空间 ，用于保存敏感数据（如登录状态、权限信息）
核心作用：与 Cookie 配合，实现安全的状态管理
- 流程
- 用户首次访问时，服务器生成唯一 session_id
- 通过 Set-Cookie 将 session_id 发送给浏览器
- 浏览器后续请求携带 session_id，服务器根据 ID 查询对应 Session 数据
- 服务器响应后，可能更新 Session（如延长登录时效）
- 特性
**存储位置：**服务端（文件、数据库或内存数据库如 Redis）
**内容：**任意结构化数据（如 JSON、序列化对象），通常包含：
- 用户 ID、登录时间、权限列表等
- 过期时间（与 Cookie 的 Expires 同步）
管理方式：
- 文件存储：简单但性能差（适合小型应用）
- Redis：高性能、支持集群（推荐生产环境使用）
- 数据库：持久化但查询慢（适合需要审计的场景）
- 优缺点
敏感数据不暴露给客户端，存储大小仅受服务器资源限制，可存储对象、列表等结构化数据
但需管理大量 Session，可能成为性能瓶颈（需用 Redis 优化），多服务器需共享 Session（可通过 Redis 集中存储解决）
2.3.二者协作关系
| 对比维度 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端 | 服务端 |
| 数据内容 | 通常仅存储 session_id |
存储用户实际数据（如登录状态） |
| 安全性 | 明文有风险（需加密/HttpOnly） | 数据在服务端，更安全 |
| 性能影响 | 增加请求头大小 | 依赖服务端查询（需优化存储） |
| 典型应用场景 | 用户偏好、跟踪分析 | 登录认证、购物车、权限控制 |
3.会话保持
会话 是指用户与系统（如网站、应用）之间的一系列连续交互过程，通常从用户登录或首次访问开始，到用户主动退出或超时结束
会话的核心目的是在无状态的 HTTP 协议中模拟"连续性"，让系统能够识别用户身份并跟踪其行为
问题：无状态性导致无法维持用户登录状态（如购物车、登录会话）解决方案：通过 Cookie + Session 机制模拟有状态交互：
- Cookie：客户端存储标识符（如 session_id），后续请求自动携带
- Session：服务器存储用户实际数据（如登录信息），通过 session_id 关联
Cookie 与 Session 的协作流程
浏览器->>服务器: 首次请求（无Cookie）
服务器-->>浏览器: 响应头 Set-Cookie: session_id=abc123
浏览器->>服务器: 后续请求（携带 Cookie: session_id=abc123）
服务器->>服务器: 根据 session_id 查询用户数据（如Redis）
服务器-->>浏览器: 返回对应资源或状态无状态性下的安全与存储设计
| 维度 | Cookie | Session |
|---|---|---|
| 存储位置 | 客户端（内存或文件） | 服务器端（文件或内存数据库如Redis） |
| 内容 | 通常仅存储 session_id（少量数据） |
存储用户敏感信息（如登录状态、权限） |
| 安全性 | 明文存储有泄露风险（需加密/HttpOnly） | 数据在服务端，更安全 |
| 性能影响 | 客户端存储开销小 | 服务器需管理Session，可能成瓶颈 |
无状态是底线，Cookie 传 ID，Session 存数据，Redis 管会话，安全靠隔离
┌─────────┐ ┌──────────────┐ ┌─────────────────┐
│ 浏览器 │ ───> │ 应用服务器 │ ───> │ Redis │
│ │ │ (无状态) │ │ (会话数据中心) │
│ Cookie │ │ │ │ │
│ SID=123 │ │ 1. 接收请求 │ │ SID → 用户数据 │
└─────────┘ │ 2. 提取SID │ │ 123 → {name:张三}│
│ 3. 查询Redis │ ───> │ 456 → {name:李四}│
│ 4. 返回响应 │ │ │
└──────────────┘ └─────────────────┘