第一阶段：Web架构基础

1. HTTP（超文本传输协议）

定义：Web 通信的基石，一种无状态、应用层协议，基于请求-响应模型。

特点：
- 无状态：每个请求独立，服务器不保留之前的请求信息（这催生了 Cookie/Session/JWT）。
- 方法：GET（获取）、POST（创建）、PUT（更新）、DELETE（删除）、PATCH（部分更新）等。
- 状态码：1xx（信息）、2xx（成功，如 200）、3xx（重定向）、4xx（客户端错误，如 404）、5xx（服务器错误）。
- 报文结构：起始行（方法+URL+版本） + 头部（Headers） + 可选的消息体（Body）。

示例：

GET /api/user/123 HTTP/1.1
Host: example.com
Authorization: Bearer xxxxx

重要性：理解 HTTP 是理解所有 Web 技术的前提。

2. Cookie

定义：服务器通过 Set-Cookie 响应头让浏览器保存的一小段文本（键值对），浏览器在后续请求中通过 Cookie 请求头自动携带。

特点：
- 域/路径限定：只发送给特定域名和路径。
- 有效期：会话级（浏览器关闭即删除）或持久化（设置 Max-Age / Expires）。
- 安全标志：HttpOnly（防 XSS 读取）、Secure（仅 HTTPS）、SameSite（防 CSRF）。
- 容量小：一般每个 Cookie 不超过 4KB，单个域名下数量有限。

用途：
- 会话管理（保存 Session ID）
- 用户偏好（主题、语言）
- 跟踪分析（但受隐私法规限制）

示例：

Set-Cookie: session_id=abc123; Path=/; HttpOnly; Secure; SameSite=Lax

3. Session

定义：服务器端存储的用户状态数据。通常由 Session ID 标识，Session ID 通过 Cookie 或 URL 重写传递给客户端。

工作流程：
1. 用户首次访问 → 服务器创建 Session（生成唯一 ID），在内存/Redis/数据库中存储用户数据。
2. 服务器通过 Set-Cookie 将 Session ID 发给浏览器。
3. 后续请求浏览器自动携带 Cookie → 服务器根据 Session ID 找到对应的状态数据。

对比 Cookie 直接存储：
- 优点：敏感数据（如用户 ID、权限）保存在服务器，更安全；存储无大小限制。
- 缺点：服务器需要存储（内存/外部存储），分布式环境下需要共享 Session（如 Redis）。

典型应用：登录状态、购物车、验证码。

4. JWT（JSON Web Token）

定义：一种无状态、紧凑的 token 格式，由三段 Base64Url 编码的字符串组成，用点分隔：
header.payload.signature

结构：
- Header：算法（如 HS256、RS256）和类型（JWT）。
- Payload：声明（claims），包含用户信息、过期时间（exp）等。
- Signature：对前两部分用密钥签名，防篡改。

特点：
- 自包含：服务器无需存储 token，只需验证签名和过期时间。
- 跨域友好：可放在 Authorization: Bearer <token> 头中，不依赖 Cookie。
- 适合分布式/微服务：无需共享存储即可认证。
- 缺点：token 一旦签发无法主动吊销（除非设计黑名单）；Payload 不宜放敏感信息（可被解码）。

与 Session 对比：

5. REST API（表述性状态传递 API）

定义：一种基于 HTTP 的架构风格，而不是协议。RESTful API 遵循资源导向、使用 HTTP 方法表达操作。

核心约束：
- 资源：URL 表示资源（名词，如 /users/123），而不是动词（/getUser）。
- HTTP 方法：
- GET：获取资源
- POST：创建资源
- PUT：完整更新资源
- PATCH：部分更新
- DELETE：删除资源
- 无状态：每个请求必须包含所有必要信息（如认证 token）。
- 统一接口：使用标准 HTTP 状态码和媒体类型（如 JSON）。

好处：简洁、可缓存、前后端分离、易于扩展。

反例（非 REST）：

POST /deleteUser?id=123

REST 风格：

DELETE /users/123

常见实践：返回 JSON，版本管理（/v1/users），分页（?page=2&size=20）。

6. MVC（模型-视图-控制器）

定义：一种设计模式，用于将应用程序的输入、处理和输出分离。也是大多数 Web 框架（Django、Flask 可选、Spring MVC）的架构基础。

三个核心组件：

数据流：
1. 用户请求 → 路由 → Controller
2. Controller 调用 Model 获取/修改数据
3. Controller 将数据传递给 View
4. View 渲染成响应（HTML/JSON）返回给用户

变体：
- MTV（Django 的“模型-模板-视图”）：视图相当于 Controller，模板相当于 View。
- 前后端分离：后端仅提供 REST API（Controller + Model），前端独立负责 View（如 React/Vue）。

概念关联图（如何一起工作）

用户浏览器
   │
   │ HTTP 请求（带 Cookie / Authorization: JWT）
   ▼
Web 服务器 (Nginx/Apache)
   │
   │ 路由到后端应用（MVC 框架）
   ▼
Controller（解析请求，验证 JWT 或从 Cookie 取 Session ID）
   │
   ├─→ 如果需要登录状态 → 查 Session 存储 / 校验 JWT
   │
   ├─→ 调用 Model（读写数据库）
   │
   └─→ 选择 View（渲染 HTML 或返回 JSON 作为 REST API）
   │
   ▼
HTTP 响应（带 Set-Cookie 或更新 JWT）
   │
   ▼
浏览器（保存 Cookie / 存储 JWT 到 localStorage）

组合示例：
- 传统 Web 应用：Cookie + Session + MVC（视图渲染 HTML）。
- 前后端分离 + 移动端：JWT + REST API + 后端 MVC（模型+控制器，视图返回 JSON）。
- 混合：登录时创建 Session，返回 Session ID 给 Cookie；API 层仍可用 JWT 做授权。

小结