模块介绍
HTTP（超文本传输协议）是互联网的基石，也是 Web 服务的核心应用层协议，我们日常的网页浏览、API 接口调用、文件下载都基于 HTTP 协议实现。HTTPS 则是 HTTP 的安全增强版本，通过 TLS/SSL 加密解决了 HTTP 明文传输的安全缺陷，是当前互联网的主流协议。
本模块将从 HTTP 协议的基础特性、报文结构、核心机制，到版本演进、HTTPS 加密原理、工作流程，带你全面拆解 HTTP/HTTPS 协议，同时覆盖高频考点、常见问题与优化方案，帮你彻底掌握 Web 通信的底层逻辑。
一、HTTP 协议基础
1. 协议定义与核心定位
HTTP（HyperText Transfer Protocol，超文本传输协议）是一种基于 TCP/IP 的应用层请求 – 响应式协议，是万维网（WWW）的核心通信协议，由蒂姆・伯纳斯 – 李在 1991 年提出。
- 传输层依赖：默认基于 TCP 协议，端口号为 80；HTTP/3 则基于 QUIC（UDP）协议实现。
- 通信模型：客户端 – 服务器（C/S）模型，客户端主动发起请求，服务器被动响应。
- 核心目标：定义客户端与服务器之间的请求 / 响应规则，实现超文本、图片、视频等多种媒体资源的传输。
2. HTTP 核心特性
表格
| 特性 | 详细说明 | 影响与补充 |
|---|---|---|
| 无状态（Stateless） | 服务器不保存客户端的会话状态，每个请求都是独立的，服务器无法识别两次请求是否来自同一客户端。 | 简化服务器设计，但无法实现会话保持，需通过 Cookie/Session 补充。 |
| 无连接（早期版本） | HTTP/1.0 默认采用短连接，每次请求都要建立 TCP 连接，响应完成后立即释放连接。 | 频繁的三次握手 / 四次挥手导致性能低下，HTTP/1.1 引入长连接优化。 |
| 基于请求 – 响应模型 | 客户端先发送请求，服务器收到请求后再返回响应，请求与响应一一对应。 | 单向交互模式，服务器无法主动向客户端推送数据。 |
| 媒体无关（MIME） | 可以传输任意类型的数据，只要客户端和服务器都能识别数据格式。 | 支持 HTML、图片、视频、JSON 等多种资源类型，通过 Content-Type 字段标识。 |
二、HTTP 报文结构详解
HTTP 报文分为请求报文（客户端→服务器）和响应报文（服务器→客户端），两者结构高度相似，均由「起始行、头部字段、空行、数据体」四部分组成。
1. HTTP 请求报文
结构组成
plaintext
[请求行]
[请求头字段1: 值]
[请求头字段2: 值]
...
[空行]
[请求体（可选）]
各部分详解
- 请求行：包含三部分，格式为
[方法] [URL] [HTTP版本]- 方法：表示客户端的操作意图（如 GET、POST）
- URL：请求的资源路径（如
/index.html） - HTTP 版本：客户端使用的协议版本（如
HTTP/1.1）示例：GET /index.html HTTP/1.1
- 请求头字段：客户端向服务器传递的附加信息，以键值对形式存在，常用字段包括： 表格字段作用示例
Host服务器的域名 / IP + 端口，用于虚拟主机区分Host: www.example.comUser-Agent客户端的浏览器 / 设备信息User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)Accept客户端可接收的响应数据类型Accept: text/html,application/xhtml+xmlCookie客户端存储的会话信息，随请求发送给服务器Cookie: sessionid=abc123Referer请求的来源页面 URLReferer: https://www.google.comContent-Type请求体的数据格式（仅 POST/PUT 请求存在）Content-Type: application/json - 空行：分隔请求头和请求体，是 HTTP 报文的固定格式，必须存在。
- 请求体：客户端向服务器提交的数据，仅 POST、PUT 等方法存在，如表单数据、JSON 参数。
2. HTTP 响应报文
结构组成
plaintext
[状态行]
[响应头字段1: 值]
[响应头字段2: 值]
...
[空行]
[响应体（可选）]
各部分详解
- 状态行：包含三部分，格式为
[HTTP版本] [状态码] [原因短语]- HTTP 版本：服务器使用的协议版本
- 状态码：服务器对请求的处理结果（如 200、404）
- 原因短语：状态码的文本说明（如 OK、Not Found）示例：
HTTP/1.1 200 OK
- 响应头字段：服务器向客户端传递的附加信息，常用字段包括： 表格字段作用示例
Server服务器的软件信息Server: nginx/1.20.1Content-Type响应体的数据格式Content-Type: text/html; charset=utf-8Content-Length响应体的长度（字节数）Content-Length: 1024Set-Cookie服务器向客户端设置 CookieSet-Cookie: sessionid=abc123; HttpOnlyCache-Control缓存控制规则Cache-Control: max-age=3600Location重定向的目标 URL（3xx 状态码时使用）Location: https://www.example.com/new.html - 空行：分隔响应头和响应体，必须存在。
- 响应体：服务器返回给客户端的资源数据，如 HTML 页面、图片、JSON 数据。
三、HTTP 核心机制详解
1. HTTP 请求方法
HTTP 方法定义了客户端对服务器资源的操作意图，常用方法及特性如下：
表格
| 方法 | 作用 | 安全 / 幂等性 | 典型场景 |
|---|---|---|---|
GET | 获取服务器资源 | 安全、幂等 | 网页浏览、接口查询 |
POST | 向服务器提交数据 | 不安全、不幂等 | 表单提交、数据新增 |
PUT | 向服务器上传 / 更新资源 | 不安全、幂等 | 文件上传、资源更新 |
DELETE | 删除服务器资源 | 不安全、幂等 | 数据删除接口 |
HEAD | 获取资源的响应头，不返回响应体 | 安全、幂等 | 资源是否存在校验 |
OPTIONS | 查询服务器支持的请求方法 | 安全、幂等 | 跨域预检请求 |
高频考点：GET vs POST
表格
| 对比维度 | GET | POST |
|---|---|---|
| 数据传输方式 | 参数拼接在 URL 中，明文传输 | 数据放在请求体中传输 |
| 安全性 | 低，参数会被浏览器历史记录、服务器日志保存 | 较高，数据不会直接暴露在 URL 中 |
| 数据长度限制 | 受 URL 长度限制（通常 2KB~8KB） | 无限制 |
| 可缓存性 | 可被浏览器缓存 | 默认不缓存 |
| 使用场景 | 查询、获取资源 | 提交、修改数据 |
2. HTTP 状态码
状态码由三位数字组成，分为 5 大类，是服务器对请求处理结果的反馈，核心常用状态码如下：
表格
| 分类 | 范围 | 含义 | 常用状态码说明 |
|---|---|---|---|
| 1xx 信息响应 | 100~199 | 请求已接收，继续处理 | 100 Continue：客户端应继续发送请求体 |
| 2xx 成功响应 | 200~299 | 请求已成功处理 | 200 OK：请求成功201 Created：资源创建成功204 No Content：请求成功，无响应体 |
| 3xx 重定向响应 | 300~399 | 请求需进一步操作才能完成 | 301 Moved Permanently：永久重定向302 Found：临时重定向304 Not Modified：资源未修改，使用缓存 |
| 4xx 客户端错误 | 400~499 | 请求存在错误 | 400 Bad Request：请求格式错误401 Unauthorized：未授权，需登录403 Forbidden：服务器拒绝访问404 Not Found：资源不存在405 Method Not Allowed：请求方法不支持 |
| 5xx 服务器错误 | 500~599 | 服务器处理请求出错 | 500 Internal Server Error：服务器内部错误502 Bad Gateway：网关错误503 Service Unavailable：服务不可用504 Gateway Timeout：网关超时 |
3. HTTP 无状态与会话保持
无状态特性的问题
服务器不保存客户端的会话状态，无法识别两次请求是否来自同一用户，无法实现登录状态保持、购物车等场景。
解决方案：Cookie 与 Session
表格
| 技术 | 工作原理 | 优缺点 |
|---|---|---|
| Cookie | 服务器通过Set-Cookie字段向客户端发送 Cookie，客户端后续请求自动携带 Cookie，服务器通过 Cookie 识别用户。 | ✅ 实现简单，客户端存储❌ 明文传输，存在安全风险；大小限制 4KB |
| Session | 服务器为每个客户端创建会话，生成唯一 Session ID，客户端通过 Cookie 携带 Session ID，服务器通过 Session ID 读取会话数据。 | ✅ 会话数据存储在服务器，安全可控❌ 服务器压力大，分布式场景需 Session 共享 |
4. HTTP 缓存机制
HTTP 缓存是 Web 性能优化的核心手段，通过复用已获取的资源，减少重复请求，提升加载速度，分为强缓存和协商缓存两类。
表格
| 缓存类型 | 核心字段 | 工作流程 | 资源状态 |
|---|---|---|---|
| 强缓存 | Cache-Control/Expires | 客户端请求时，先判断资源是否在有效期内，若有效则直接使用本地缓存，不向服务器发送请求。 | 命中缓存：返回 200（from disk cache/from memory cache） |
| 协商缓存 | Last-Modified/If-Modified-SinceETag/If-None-Match | 强缓存失效后，客户端向服务器发送校验请求，服务器校验资源是否更新，未更新则返回 304，客户端继续使用缓存。 | 未更新：返回 304 Not Modified已更新：返回 200 + 新资源 |
5. HTTP 连接管理
- HTTP/1.0：短连接：每次请求都要建立 TCP 连接，响应完成后立即释放，频繁握手导致性能低下。
- HTTP/1.1：长连接（Keep-Alive）：默认开启长连接，一次 TCP 连接可发送多个请求 / 响应，无需重复握手，通过
Connection: keep-alive字段控制。 - HTTP/1.1 管线化（Pipeline）：客户端可连续发送多个请求，无需等待前一个请求的响应，但服务器需按顺序返回响应，存在队头阻塞问题。
四、HTTP 版本演进
1. HTTP/1.0（1996）
- 核心特性：短连接、无缓存机制、不支持虚拟主机
- 缺陷：性能差，无法满足复杂 Web 应用的需求
2. HTTP/1.1（1999，至今仍广泛使用）
- 核心改进：✅ 引入长连接（Keep-Alive），复用 TCP 连接✅ 新增缓存控制字段（Cache-Control、ETag）✅ 支持虚拟主机，同一 IP 可部署多个网站✅ 新增更多请求方法（PUT、DELETE）
- 缺陷：队头阻塞、头部冗余、性能瓶颈明显
3. HTTP/2.0（2015）
- 核心改进：✅ 二进制协议：将文本格式改为二进制，解析更高效✅ 多路复用：同一 TCP 连接可并行发送多个请求 / 响应，解决队头阻塞✅ 头部压缩（HPACK）：减少请求头的冗余数据✅ 服务器推送：服务器可主动向客户端推送资源
- 缺陷：仍基于 TCP 协议，TCP 层面的队头阻塞问题未彻底解决
4. HTTP/3.0（2022，最新版本）
- 核心改进：基于 QUIC 协议（UDP）实现 HTTP/2.0 的所有特性✅ 彻底解决 TCP 队头阻塞问题✅ 连接迁移：网络切换（WiFi→4G）时无需重建连接✅ 更快的握手：QUIC 握手仅需 1-RTT，比 TCP+TLS 更高效
- 现状：主流浏览器和服务器已支持，正在逐步普及
五、HTTPS 协议详解
1. HTTP 的安全缺陷
HTTP 协议以明文传输数据，存在三大安全风险：
- 数据窃听：传输的数据可被第三方直接读取，如账号密码、支付信息。
- 数据篡改：第三方可修改传输的数据，如篡改转账金额、广告内容。
- 身份伪造：无法验证服务器身份，客户端可能访问伪造的钓鱼网站。
HTTPS（HyperText Transfer Protocol Secure）通过 TLS/SSL 加密解决了这些问题，是 HTTP 的安全增强版本。
2. HTTPS 核心定义与端口
- 协议全称：HTTP Over SSL/TLS
- 传输层依赖：基于 TCP 协议，默认端口号为 443
- 核心原理：在 HTTP 与 TCP 之间增加 TLS/SSL 层，对传输的数据进行加密和身份验证。
3. TLS/SSL 工作流程
TLS/SSL（传输层安全协议）是 HTTPS 的核心，工作流程分为两个阶段：握手阶段和数据传输阶段。
阶段 1：TLS 握手（1-RTT/2-RTT）
- 客户端 Hello：客户端向服务器发送 TLS 版本号、加密套件列表、随机数。
- 服务器 Hello：服务器选择双方都支持的 TLS 版本和加密套件，返回服务器证书、随机数。
- 证书验证：客户端验证服务器证书的合法性（是否由 CA 颁发、是否过期、域名是否匹配）。
- 密钥交换：双方通过非对称加密交换预主密钥，生成会话密钥。
- 握手完成：双方使用会话密钥对后续数据进行对称加密传输。
阶段 2：数据加密传输
握手完成后，双方使用协商好的会话密钥，对 HTTP 数据进行对称加密传输，确保数据的机密性、完整性和真实性。
4. HTTPS 加密机制
HTTPS 采用混合加密机制，结合了对称加密和非对称加密的优势：
表格
| 加密方式 | 作用 | 优缺点 |
|---|---|---|
| 非对称加密（RSA/ECC） | 服务器用私钥加密，客户端用公钥解密，用于传输对称密钥和验证服务器身份。 | ✅ 安全，可验证身份❌ 加密 / 解密速度慢，不适合大数据传输 |
| 对称加密（AES/ChaCha20） | 双方用同一密钥加密 / 解密，用于传输 HTTP 数据。 | ✅ 加密 / 解密速度快，适合大数据传输❌ 密钥分发存在安全风险 |
混合加密流程
- 服务器持有 CA 颁发的数字证书（含公钥），客户端验证证书后，使用服务器公钥加密会话密钥，发送给服务器。
- 服务器用私钥解密，得到会话密钥。
- 双方使用会话密钥对 HTTP 数据进行对称加密传输，兼顾安全与性能。
5. 数字证书与 CA 机构
数字证书是服务器身份的凭证，由受信任的 CA（证书颁发机构）签发，核心作用是防止中间人攻击。
- 证书内容：服务器域名、公钥、证书有效期、CA 签名、证书序列号。
- 验证流程：客户端收到证书后，通过 CA 的公钥验证证书签名，确认证书未被篡改、服务器身份合法。
六、HTTP 与 HTTPS 核心对比
表格
| 对比维度 | HTTP | HTTPS |
|---|---|---|
| 传输端口 | 80 | 443 |
| 安全性 | 明文传输，无加密，存在窃听、篡改、伪造风险 | TLS/SSL 加密传输，防窃听、防篡改、防伪造 |
| 传输层协议 | 仅 TCP | TCP+TLS/SSL（HTTP/3 为 UDP+QUIC） |
| 性能开销 | 无加密开销，性能高 | TLS 握手和加密 / 解密存在额外开销 |
| 浏览器标识 | 地址栏显示 “不安全” | 地址栏显示锁形图标，标记为 “安全” |
| SEO 权重 | 无优势 | 搜索引擎优先收录 HTTPS 网站 |
| 合规要求 | 部分场景不合规（如支付、政务网站） | 多数行业（电商、金融）强制要求 |
七、HTTPS 性能优化与常见问题
1. HTTPS 性能优化方案
- TLS 会话复用：通过 Session ID 或 Session Ticket 复用会话，减少 TLS 握手次数。
- TLS 1.3 升级：TLS 1.3 将握手次数从 2-RTT 优化为 1-RTT，大幅降低握手延迟。
- OCSP Stapling：服务器提前获取证书状态，在握手时直接返回，减少客户端证书验证延迟。
- HTTP/2 + HTTPS：HTTP/2 的多路复用和头部压缩，抵消部分 HTTPS 的性能开销。
2. 常见问题与排查
- 证书相关错误：证书过期、域名不匹配、不信任证书（需安装根证书或更换受信任 CA 证书）。
- 混合内容问题：HTTPS 页面中加载 HTTP 资源，浏览器会拦截或降级显示。
- TLS 版本不兼容：客户端或服务器不支持 TLS 1.2 及以上版本，导致连接失败。
模块总结与学习指引
HTTP/HTTPS 是 Web 通信的核心协议，本模块我们掌握了：
- HTTP 协议的报文结构、请求方法、状态码、缓存机制和版本演进。
- HTTPS 通过 TLS/SSL 加密解决 HTTP 的安全缺陷，混合加密和数字证书是其安全的核心。
- HTTP/2 和 HTTP/3 通过多路复用、QUIC 协议等技术，解决了早期版本的性能瓶颈。
No responses yet