一、HTTP 核心解析
HTTP（HyperText Transfer Protocol，超文本传输协议）是客户端与服务器之间传输数据的应用层协议，是 Web 通信的基础。
1. HTTP 的核心特点
| 特点 |
说明 |
优势 / 问题 |
| 无状态 |
服务器不记录客户端的请求上下文，请求之间无关联 |
优势：轻量、高效；问题：需 Cookie/Session 等机制实现状态保持 |
| 无连接 |
HTTP/1.1 前每次请求新建 TCP 连接；1.1 引入持久连接（Keep-Alive） |
优势：简化设计；问题：早期频繁建连消耗资源，1.1 已优化 |
| 明文传输 |
所有请求 / 响应数据均为纯文本，无加密处理 |
优势：易调试；问题：存在窃听、篡改风险，核心安全短板 |
| 灵活扩展 |
支持自定义请求头 / 响应头、请求方法（GET/POST/PUT 等） |
优势：适配 RESTful API、文件上传等多场景 |
| 基于请求 - 响应模型 |
客户端发起请求 → 服务器返回响应，单向交互 |
优势：逻辑简单；问题：无法主动推送，需 WebSocket 补充 |
| 缓存友好 |
支持多缓存策略，通过头字段控制缓存行为 |
优势：减少请求次数、降低服务器负载、提升访问速度；问题：配置不当易导致数据不一致 |
2. HTTP 缓存核心机制
HTTP 缓存是客户端（浏览器）或中间代理服务器临时存储服务器返回的资源，后续请求相同资源时优先读取本地缓存的机制。
（1）缓存分类（按存储位置与优先级）
| 缓存类型 |
存储位置 |
优先级 |
核心特点 |
| 强缓存 |
浏览器本地磁盘 / 内存 |
最高 |
直接读取本地缓存，不向服务器发送请求 |
| 协商缓存 |
浏览器本地磁盘 / 内存 |
次高 |
向服务器发送请求，由服务器判断缓存是否有效 |
| 代理缓存 |
CDN、Nginx 等中间代理服务器 |
中等 |
为多个客户端提供缓存服务，降低源站压力 |
| 数据库缓存 |
服务器端数据库 |
低 |
属于服务器内部优化，非 HTTP 层面缓存 |
（2）强缓存（核心控制头字段）
强缓存是浏览器优先使用的本地缓存策略，服务器通过Cache-Control（主流）或Expires头字段，给资源设定有效期。有效期内，浏览器请求相同资源时，直接从本地读取，无需和服务器通信，既省流量又提速度。但弊端是，若服务器资源更新，浏览器因未请求，会继续使用旧缓存，适用于长期不变的静态资源（如图片、CSS）。
| 头字段 |
类型 |
格式 / 指令 |
作用说明 |
Expires |
响应头（HTTP/1.0） |
绝对时间（GMT 格式）例：Expires: Wed, 21 Oct 2026 07:28:00 GMT |
浏览器对比本地时间与该时间，未过期则用缓存；依赖本地时间，易受时间篡改影响 |
Cache-Control |
响应头（HTTP/1.1，推荐） |
多指令组合例：Cache-Control: public, max-age=3600 |
用相对时间控制缓存，指令优先级高于 Expires |
- max-age=N |
Cache-Control 子指令 |
N 为秒数 |
缓存有效期为响应返回后 N 秒 |
- public |
Cache-Control 子指令 |
- |
允许浏览器、代理服务器等所有节点缓存 |
- private |
Cache-Control 子指令 |
- |
仅允许浏览器缓存，禁止代理服务器缓存（如用户个人数据） |
- no-cache |
Cache-Control 子指令 |
- |
不使用强缓存，直接进入协商缓存流程 |
- no-store |
Cache-Control 子指令 |
- |
禁止任何缓存，每次请求都从服务器获取新资源（如敏感数据） |
（3）协商缓存（核心控制头字段）
协商缓存是强缓存过期后的备选方案，浏览器会携带资源标识（ETag或Last-Modified）请求服务器。服务器对比标识，若资源未更新，返回304状态码，浏览器继续用本地缓存；若已更新，返回新资源和新标识。它兼顾性能与资源时效性，ETag基于内容哈希，比基于修改时间的Last-Modified精度更高，适合频繁更新的动态资源（如 HTML）。
| 头字段组 |
头字段类型 |
作用说明 |
交互流程 |
Last-Modified If-Modified-Since |
Last-Modified：响应头If-Modified-Since：请求头 |
基于文件最后修改时间判断缓存有效性，时间精度为秒级 |
1. 服务器返回资源时，通过 Last-Modified 携带最后修改时间2. 强缓存过期后，浏览器通过 If-Modified-Since 携带该时间请求服务器3. 服务器对比：未修改则返回 304 Not Modified；已修改则返回 200 OK + 新资源 |
ETag If-None-Match |
ETag：响应头If-None-Match：请求头 |
基于文件内容哈希值判断缓存有效性，内容变则哈希值变，精度更高 |
1. 服务器返回资源时，通过 ETag 携带资源唯一哈希值2. 强缓存过期后，浏览器通过 If-None-Match 携带该哈希值请求服务器3. 服务器对比：哈希一致则返回 304 Not Modified；不一致则返回 200 OK + 新资源 |
（4）缓存完整执行流程
- 浏览器请求资源 → 检查本地是否有缓存
- 无缓存 → 发送请求到服务器 → 返回
200 OK + 资源 + 缓存头 → 存储缓存
- 有缓存 → 检查强缓存是否过期
- 未过期 → 直接使用本地缓存（状态码：
200 from cache）
- 已过期 → 发送协商缓存请求到服务器
- 服务器判断缓存有效 → 返回
304 Not Modified → 使用本地缓存
- 服务器判断缓存无效 → 返回
200 OK + 新资源 + 新缓存头 → 更新缓存
（5）缓存实战配置建议
| 资源类型 |
缓存配置方案 |
配置目的 |
| 静态资源（CSS/JS/ 图片） |
Cache-Control: public, max-age=604800（7 天）+ 文件指纹（如 app.v2.js） |
长期缓存降低请求次数，文件更新时修改指纹触发新请求 |
| 动态页面（HTML） |
Cache-Control: no-cache |
强制走协商缓存，保证页面实时性 |
| 敏感数据（用户订单 / 支付信息） |
Cache-Control: no-store |
禁止任何缓存，每次请求都获取最新数据 |
3. HTTP 角色认证实现机制
HTTP 无状态，需通过请求头 / 响应头传递认证信息，实现服务器对用户身份的识别。
| 认证机制 |
核心逻辑 |
头字段示例 |
特点 |
| Cookie + Session |
服务器生成唯一 Session ID，通过响应头发给客户端；客户端后续请求通过请求头携带该 ID |
响应头：Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly; Max-Age=3600请求头：Cookie: JSESSIONID=abc123 |
Session 存储在服务器，易受 CSRF 攻击；需配置 HttpOnly 防止 XSS 窃取 Cookie |
| Token 认证（JWT 为主） |
服务器验证身份后生成加密 Token，返回给客户端；客户端请求时通过请求头携带 Token |
请求头：Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... |
Token 存储在客户端，服务器无需存储，适合分布式系统；Token 泄露会导致身份冒用，需配合 HTTPS |
| Basic 认证 |
客户端将用户名和密码用 Base64 编码后，通过请求头传递 |
请求头：Authorization: Basic dXNlcjE6cGFzc3dvcmQ= |
明文编码无加密，仅适用于测试 / 内网场景 |
| OAuth2.0 |
第三方授权机制，通过授权码获取 Token，实现跨平台登录（如微信 / QQ 登录） |
请求头：Authorization: Bearer [第三方授权 Token] |
无需用户提供账号密码，安全性高；流程较复杂 |
4. HTTP 请求头 / 响应头核心分类
| 头字段分类 |
核心头字段 |
作用 |
| 身份认证 |
Authorization、Cookie、Set-Cookie |
传递认证信息，实现用户身份识别 |
| 缓存控制 |
Cache-Control、Expires、ETag、Last-Modified、If-None-Match、If-Modified-Since |
控制缓存策略，优化资源加载性能 |
| 内容协商 |
Content-Type、Accept |
Content-Type 声明响应体格式；Accept 声明客户端支持的格式 |
| 跨域控制 |
Access-Control-Allow-Origin |
解决跨域请求问题，如 * 允许所有域名访问 |
| 连接控制 |
Connection |
控制持久连接，如 Connection: Keep-Alive |
| 安全防护 |
X-Content-Type-Options、X-XSS-Protection |
基础安全防护，无法解决明文传输问题 |
5. HTTP 核心缺陷（引出 HTTPS）
HTTP 明文传输的特性导致三大致命问题：
- 窃听风险：中间人可抓取数据包，获取账号密码、支付信息等敏感数据；
- 篡改风险：中间人可修改请求 / 响应内容（如篡改订单金额、植入恶意代码）；
- 冒充风险：中间人可伪装成服务器（钓鱼网站），骗取用户数据。
二、HTTPS 核心解析
HTTPS 不是新协议，是 HTTP 运行在 SSL/TLS 加密层之上 的安全协议，核心目标是解决 HTTP 的安全缺陷。
1. HTTPS 核心改进
| 改进点 |
说明 |
| 加密传输 |
数据通过 SSL/TLS 加密后再传输，中间人无法解析明文 |
| 身份验证 |
服务器需部署 CA 签发的证书，客户端可验证服务器合法性，防止冒充 |
| 完整性校验 |
通过哈希算法校验数据，确保传输过程中未被篡改 |
| 缓存兼容 |
缓存逻辑与 HTTP 一致，缓存资源加密存储，更安全 |
2. HTTPS 连接建立过程（TCP 三次握手 + TLS 握手）
| 阶段 |
具体步骤 |
作用 |
| 阶段 1：TCP 三次握手 |
1. 客户端发送 SYN 报文 → 服务器2. 服务器返回 SYN+ACK 报文 → 客户端3. 客户端发送 ACK 报文 → 服务器 |
建立客户端与服务器的可靠 TCP 连接 |
| 阶段 2：TLS 握手（核心） |
1. Client Hello：客户端发送支持的 TLS 版本、加密套件、随机数 1 |
协商加密规则，生成密钥的基础数据 |
|
2. Server Hello：服务器返回选定的 TLS 版本、加密套件、随机数 2 |
确认加密规则，补充密钥基础数据 |
|
3. 服务器发证书：服务器发送 CA 签发的证书（含公钥、CA 签名） |
客户端验证服务器合法身份 |
|
4. Server Hello Done：服务器告知客户端 Hello 阶段结束 |
进入密钥协商阶段 |
|
5. 客户端验证证书：客户端向 CA 验证证书合法性，失败则终止连接 |
防止连接到钓鱼网站 |
|
6. 客户端发预主密钥：客户端生成预主密钥，用服务器公钥加密后发送 |
服务器用私钥解密，双方获取预主密钥 |
|
7. 生成会话密钥：双方通过「随机数 1 + 随机数 2 + 预主密钥」计算出会话密钥（对称加密密钥） |
对称加密效率高，用于后续数据传输 |
|
8. 加密握手完成：客户端和服务器分别用会话密钥加密「握手完成」报文并发送 |
确认加密通信可用 |
| 阶段 3：加密数据传输 |
后续所有 HTTP 请求 / 响应数据，均通过会话密钥加密后传输 |
保证数据安全，防止窃听、篡改 |
3. HTTP 与 HTTPS 核心区别
| 对比维度 |
HTTP |
HTTPS |
| 默认端口 |
80 |
443 |
| 传输方式 |
明文传输，无加密 |
SSL/TLS 加密传输 |
| 安全性 |
无身份验证、无完整性校验，存在窃听 / 篡改 / 冒充风险 |
加密传输、服务器身份验证、数据完整性校验 |
| 性能 |
无加解密开销，速度快 |
证书验证、加解密存在少量性能开销（可优化） |
| 证书要求 |
无需证书 |
需 CA 签发的证书（免费 / 付费） |
| 缓存机制 |
缓存资源易被篡改 |
缓存资源加密存储，更安全 |
HTTP（HyperText Transfer Protocol，超文本传输协议）是客户端与服务器之间传输数据的应用层协议，是 Web 通信的基础。
1. HTTP 的核心特点
| 特点 |
说明 |
优势 / 问题 |
| 无状态 |
服务器不记录客户端的请求上下文，请求之间无关联 |
优势：轻量、高效；问题：需 Cookie/Session 等机制实现状态保持 |
| 无连接 |
HTTP/1.1 前每次请求新建 TCP 连接；1.1 引入持久连接（Keep-Alive） |
优势：简化设计；问题：早期频繁建连消耗资源，1.1 已优化 |
| 明文传输 |
所有请求 / 响应数据均为纯文本，无加密处理 |
优势：易调试；问题：存在窃听、篡改风险，核心安全短板 |
| 灵活扩展 |
支持自定义请求头 / 响应头、请求方法（GET/POST/PUT 等） |
优势：适配 RESTful API、文件上传等多场景 |
| 基于请求 - 响应模型 |
客户端发起请求 → 服务器返回响应，单向交互 |
优势：逻辑简单；问题：无法主动推送，需 WebSocket 补充 |
| 缓存友好 |
支持多缓存策略，通过头字段控制缓存行为 |
优势：减少请求次数、降低服务器负载、提升访问速度；问题：配置不当易导致数据不一致 |
2. HTTP 缓存核心机制
HTTP 缓存是客户端（浏览器）或中间代理服务器临时存储服务器返回的资源，后续请求相同资源时优先读取本地缓存的机制。
（1）缓存分类（按存储位置与优先级）
| 缓存类型 |
存储位置 |
优先级 |
核心特点 |
| 强缓存 |
浏览器本地磁盘 / 内存 |
最高 |
直接读取本地缓存，不向服务器发送请求 |
| 协商缓存 |
浏览器本地磁盘 / 内存 |
次高 |
向服务器发送请求，由服务器判断缓存是否有效 |
| 代理缓存 |
CDN、Nginx 等中间代理服务器 |
中等 |
为多个客户端提供缓存服务，降低源站压力 |
| 数据库缓存 |
服务器端数据库 |
低 |
属于服务器内部优化，非 HTTP 层面缓存 |
（2）强缓存（核心控制头字段）
强缓存是浏览器优先使用的本地缓存策略，服务器通过Cache-Control（主流）或Expires头字段，给资源设定有效期。有效期内，浏览器请求相同资源时，直接从本地读取，无需和服务器通信，既省流量又提速度。但弊端是，若服务器资源更新，浏览器因未请求，会继续使用旧缓存，适用于长期不变的静态资源（如图片、CSS）。
| 头字段 |
类型 |
格式 / 指令 |
作用说明 |
Expires |
响应头（HTTP/1.0） |
绝对时间（GMT 格式）例：Expires: Wed, 21 Oct 2026 07:28:00 GMT |
浏览器对比本地时间与该时间，未过期则用缓存；依赖本地时间，易受时间篡改影响 |
Cache-Control |
响应头（HTTP/1.1，推荐） |
多指令组合例：Cache-Control: public, max-age=3600 |
用相对时间控制缓存，指令优先级高于 Expires |
- max-age=N |
Cache-Control 子指令 |
N 为秒数 |
缓存有效期为响应返回后 N 秒 |
- public |
Cache-Control 子指令 |
- |
允许浏览器、代理服务器等所有节点缓存 |
- private |
Cache-Control 子指令 |
- |
仅允许浏览器缓存，禁止代理服务器缓存（如用户个人数据） |
- no-cache |
Cache-Control 子指令 |
- |
不使用强缓存，直接进入协商缓存流程 |
- no-store |
Cache-Control 子指令 |
- |
禁止任何缓存，每次请求都从服务器获取新资源（如敏感数据） |
（3）协商缓存（核心控制头字段）
协商缓存是强缓存过期后的备选方案，浏览器会携带资源标识（ETag或Last-Modified）请求服务器。服务器对比标识，若资源未更新，返回304状态码，浏览器继续用本地缓存；若已更新，返回新资源和新标识。它兼顾性能与资源时效性，ETag基于内容哈希，比基于修改时间的Last-Modified精度更高，适合频繁更新的动态资源（如 HTML）。
| 头字段组 |
头字段类型 |
作用说明 |
交互流程 |
Last-Modified If-Modified-Since |
Last-Modified：响应头If-Modified-Since：请求头 |
基于文件最后修改时间判断缓存有效性，时间精度为秒级 |
1. 服务器返回资源时，通过 Last-Modified 携带最后修改时间2. 强缓存过期后，浏览器通过 If-Modified-Since 携带该时间请求服务器3. 服务器对比：未修改则返回 304 Not Modified；已修改则返回 200 OK + 新资源 |
ETag If-None-Match |
ETag：响应头If-None-Match：请求头 |
基于文件内容哈希值判断缓存有效性，内容变则哈希值变，精度更高 |
1. 服务器返回资源时，通过 ETag 携带资源唯一哈希值2. 强缓存过期后，浏览器通过 If-None-Match 携带该哈希值请求服务器3. 服务器对比：哈希一致则返回 304 Not Modified；不一致则返回 200 OK + 新资源 |
（4）缓存完整执行流程
- 浏览器请求资源 → 检查本地是否有缓存
- 无缓存 → 发送请求到服务器 → 返回
200 OK + 资源 + 缓存头 → 存储缓存
- 有缓存 → 检查强缓存是否过期
- 未过期 → 直接使用本地缓存（状态码：
200 from cache）
- 已过期 → 发送协商缓存请求到服务器
- 服务器判断缓存有效 → 返回
304 Not Modified → 使用本地缓存
- 服务器判断缓存无效 → 返回
200 OK + 新资源 + 新缓存头 → 更新缓存
（5）缓存实战配置建议
| 资源类型 |
缓存配置方案 |
配置目的 |
| 静态资源（CSS/JS/ 图片） |
Cache-Control: public, max-age=604800（7 天）+ 文件指纹（如 app.v2.js） |
长期缓存降低请求次数，文件更新时修改指纹触发新请求 |
| 动态页面（HTML） |
Cache-Control: no-cache |
强制走协商缓存，保证页面实时性 |
| 敏感数据（用户订单 / 支付信息） |
Cache-Control: no-store |
禁止任何缓存，每次请求都获取最新数据 |
3. HTTP 角色认证实现机制
HTTP 无状态，需通过请求头 / 响应头传递认证信息，实现服务器对用户身份的识别。
| 认证机制 |
核心逻辑 |
头字段示例 |
特点 |
| Cookie + Session |
服务器生成唯一 Session ID，通过响应头发给客户端；客户端后续请求通过请求头携带该 ID |
响应头：Set-Cookie: JSESSIONID=abc123; Path=/; HttpOnly; Max-Age=3600请求头：Cookie: JSESSIONID=abc123 |
Session 存储在服务器，易受 CSRF 攻击；需配置 HttpOnly 防止 XSS 窃取 Cookie |
| Token 认证（JWT 为主） |
服务器验证身份后生成加密 Token，返回给客户端；客户端请求时通过请求头携带 Token |
请求头：Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9... |
Token 存储在客户端，服务器无需存储，适合分布式系统；Token 泄露会导致身份冒用，需配合 HTTPS |
| Basic 认证 |
客户端将用户名和密码用 Base64 编码后，通过请求头传递 |
请求头：Authorization: Basic dXNlcjE6cGFzc3dvcmQ= |
明文编码无加密，仅适用于测试 / 内网场景 |
| OAuth2.0 |
第三方授权机制，通过授权码获取 Token，实现跨平台登录（如微信 / QQ 登录） |
请求头：Authorization: Bearer [第三方授权 Token] |
无需用户提供账号密码，安全性高；流程较复杂 |
4. HTTP 请求头 / 响应头核心分类
| 头字段分类 |
核心头字段 |
作用 |
| 身份认证 |
Authorization、Cookie、Set-Cookie |
传递认证信息，实现用户身份识别 |
| 缓存控制 |
Cache-Control、Expires、ETag、Last-Modified、If-None-Match、If-Modified-Since |
控制缓存策略，优化资源加载性能 |
| 内容协商 |
Content-Type、Accept |
Content-Type 声明响应体格式；Accept 声明客户端支持的格式 |
| 跨域控制 |
Access-Control-Allow-Origin |
解决跨域请求问题，如 * 允许所有域名访问 |
| 连接控制 |
Connection |
控制持久连接，如 Connection: Keep-Alive |
| 安全防护 |
X-Content-Type-Options、X-XSS-Protection |
基础安全防护，无法解决明文传输问题 |
5. HTTP 核心缺陷（引出 HTTPS）
HTTP 明文传输的特性导致三大致命问题：
- 窃听风险：中间人可抓取数据包，获取账号密码、支付信息等敏感数据；
- 篡改风险：中间人可修改请求 / 响应内容（如篡改订单金额、植入恶意代码）；
- 冒充风险：中间人可伪装成服务器（钓鱼网站），骗取用户数据。
二、HTTPS 核心解析
HTTPS 不是新协议，是 HTTP 运行在 SSL/TLS 加密层之上 的安全协议，核心目标是解决 HTTP 的安全缺陷。
1. HTTPS 核心改进
| 改进点 |
说明 |
| 加密传输 |
数据通过 SSL/TLS 加密后再传输，中间人无法解析明文 |
| 身份验证 |
服务器需部署 CA 签发的证书，客户端可验证服务器合法性，防止冒充 |
| 完整性校验 |
通过哈希算法校验数据，确保传输过程中未被篡改 |
| 缓存兼容 |
缓存逻辑与 HTTP 一致，缓存资源加密存储，更安全 |
2. HTTPS 连接建立过程（TCP 三次握手 + TLS 握手）
| 阶段 |
具体步骤 |
作用 |
| 阶段 1：TCP 三次握手 |
1. 客户端发送 SYN 报文 → 服务器2. 服务器返回 SYN+ACK 报文 → 客户端3. 客户端发送 ACK 报文 → 服务器 |
建立客户端与服务器的可靠 TCP 连接 |
| 阶段 2：TLS 握手（核心） |
1. Client Hello：客户端发送支持的 TLS 版本、加密套件、随机数 1 |
协商加密规则，生成密钥的基础数据 |
|
2. Server Hello：服务器返回选定的 TLS 版本、加密套件、随机数 2 |
确认加密规则，补充密钥基础数据 |
|
3. 服务器发证书：服务器发送 CA 签发的证书（含公钥、CA 签名） |
客户端验证服务器合法身份 |
|
4. Server Hello Done：服务器告知客户端 Hello 阶段结束 |
进入密钥协商阶段 |
|
5. 客户端验证证书：客户端向 CA 验证证书合法性，失败则终止连接 |
防止连接到钓鱼网站 |
|
6. 客户端发预主密钥：客户端生成预主密钥，用服务器公钥加密后发送 |
服务器用私钥解密，双方获取预主密钥 |
|
7. 生成会话密钥：双方通过「随机数 1 + 随机数 2 + 预主密钥」计算出会话密钥（对称加密密钥） |
对称加密效率高，用于后续数据传输 |
|
8. 加密握手完成：客户端和服务器分别用会话密钥加密「握手完成」报文并发送 |
确认加密通信可用 |
| 阶段 3：加密数据传输 |
后续所有 HTTP 请求 / 响应数据，均通过会话密钥加密后传输 |
保证数据安全，防止窃听、篡改 |
3. HTTP 与 HTTPS 核心区别
| 对比维度 |
HTTP |
HTTPS |
| 默认端口 |
80 |
443 |
| 传输方式 |
明文传输，无加密 |
SSL/TLS 加密传输 |
| 安全性 |
无身份验证、无完整性校验，存在窃听 / 篡改 / 冒充风险 |
加密传输、服务器身份验证、数据完整性校验 |
| 性能 |
无加解密开销，速度快 |
证书验证、加解密存在少量性能开销（可优化） |
| 证书要求 |
无需证书 |
需 CA 签发的证书（免费 / 付费） |
| 缓存机制 |
缓存资源易被篡改 |
缓存资源加密存储，更安全 |