什么是 HTTP

HTTP (HyperText Transfer Protocol，超文本传输协议) 是规定 Web 浏览器与服务器之间如何交换数据的通信协议。1991 年，Tim Berners-Lee 在创建万维网时设计了 HTTP/0.9，最初仅用于传输 HTML 文档。而 HTTP 承载的内容已不限于 HTML 文档，还包括图片、JSON API 响应和流媒体视频等各类 Web 资源。该协议的规范在 2022 年 6 月被重新整理为 RFC 9110 (HTTP 语义)、RFC 9111 (缓存) 和 RFC 9112 (HTTP/1.1 报文语法)，长期被引用的 RFC 2616 和 RFC 7230 系列已被废止。

当你在浏览器地址栏输入 URL 时，浏览器会向服务器发送 HTTP 请求，服务器处理后返回 HTTP 响应，这一往返过程是每个网页显示的基本机制。HTTP 是无状态协议，每个请求都是独立的，不携带之前交互的记忆。维持登录状态等功能需要借助 Cookie 或认证令牌等机制。

请求与响应的结构

HTTP 通信遵循简单的客户端-服务器模型：客户端发送请求，服务器返回响应。

方法 (GET、POST、PUT、DELETE) 指定对服务器的操作类型。URL 路径标识目标资源。请求头携带浏览器类型 (User-Agent)、可接受的数据格式 (Accept)、认证信息 (Authorization) 等元数据。POST 和 PUT 请求的请求体中包含表单数据或 JSON 负载。

状态码 (200、404、500) 表示处理结果。响应头包含内容类型 (Content-Type)、缓存控制 (Cache-Control)、安全头等信息。响应体包含实际数据，如 HTML、JSON、图片二进制数据等。

GET 请求用于获取资源，通常不包含请求体。RFC 9110 指出 GET 请求中的内容没有普遍定义的语义，并规定客户端不应在 GET 请求中发送请求体。POST 用于提交数据 (表单提交、API 调用)，请求体中携带数据。REST API 还广泛使用 PUT (更新)、DELETE (删除) 和 PATCH (部分更新)。

主要状态码

HTTP 状态码是三位数字，用于分类服务器的响应结果。首位数字决定类别。

200 OK 表示请求成功。201 Created 确认新资源已创建。204 No Content 表示成功但无响应体 (常见于 DELETE 操作后)。

301 Moved Permanently 表示永久 URL 变更。Google 说明其索引流程会把这一重定向视为「跳转目标才是规范 URL」的信号。302 Found 是临时重定向。304 Not Modified 告知客户端缓存版本仍然有效。

400 Bad Request 表示请求语法错误。401 Unauthorized 需要认证。403 Forbidden 拒绝访问。404 Not Found 资源不存在。429 Too Many Requests 超出速率限制。

500 Internal Server Error 是通用服务器错误。502 Bad Gateway 反向代理从后端收到无效响应。503 Service Unavailable 服务器因维护或过载暂时不可用。

正确使用状态码在 API 设计中至关重要，它使客户端能够优雅地处理错误，并简化调试过程。

HTTP 版本演进

HTTP 自 1991 年的 HTTP/0.9 以来，在三十多年间经历了重大演进，每个版本都针对前一版本的性能瓶颈进行了改进。

截至 2026 年 8 月仍被广泛使用。1997 年 1 月由 RFC 2068 规定，2022 年 6 月重新整理为 RFC 9112。引入了持久连接 (Keep-Alive)、分块传输编码和通过 Host 头实现的虚拟主机。但每个 TCP 连接同一时间只能处理一个请求，导致队头阻塞 (Head-of-Line Blocking)，前面的慢请求会阻塞后续所有请求。

基于 Google 的 SPDY 协议，于 2015 年 5 月由 RFC 7540 标准化，2022 年 6 月修订为 RFC 9113。实现了多路复用，在单个 TCP 连接上并行处理多个请求和响应，HPACK 头部压缩减少了开销。规范中还定义了在客户端请求之前主动推送资源的服务器推送，但 Chrome 已在 2022 年 9 月的 Chrome 106 中将其默认禁用，并推荐改用 103 Early Hints。此外 TCP 层面的队头阻塞问题仍然存在。

2022 年 6 月由 RFC 9114 标准化。用基于 UDP 的 QUIC (RFC 9000) 替代 TCP，彻底消除了 TCP 队头阻塞。首次连接的握手为 1-RTT，对曾经连接过的服务器可以使用 0-RTT 恢复。由于会话通过连接 ID 而非 IP 地址识别，在移动环境下 Wi-Fi 与蜂窝网络切换时连接不易中断。服务器通过 Alt-Svc 响应头等方式告知 HTTP/3 可用，不支持的客户端会回退到 HTTP/2 或更早版本。

HTTP/2 和 HTTP/3 实质上要求使用 HTTPS。主流浏览器不支持未加密的 HTTP/2 连接，而 HTTP/3 的 QUIC 协议内置了 TLS 1.3。协议的速度提升与安全增强是同步推进的。

HTTP 与 HTTPS 的关系

HTTP 以明文方式传输数据，网络路径上的任何人都可以窃听和篡改通信内容。HTTPS 在 HTTP 之上添加了 TLS 加密层，保护通信通道的安全。

HTTP：使用端口 80。数据未加密。截至 2026 年 8 月，Chrome 会在地址栏显示「不安全」提示，Chrome 和 Safari 还会尝试把 HTTP 页面跳转自动升级为 HTTPS。
HTTPS：使用端口 443。通信由 TLS 加密。Google 曾于 2014 年 8 月宣布开始把 HTTPS 作为搜索排名信号，并在当时说明这是「影响不到全球查询 1 % 的非常轻量的信号」。

即使在 HTTPS 成为事实标准的环境中，HTTP 仍然是底层协议。请求-响应模型、方法、头部和状态码在两者中完全相同，HTTPS 只是将 HTTP 交换包裹在加密隧道中。理解 HTTP 基础对于使用 HTTPS、利用开发者工具调试以及设计 API 都是必不可少的。

实务中容易出现的误解，是仅凭地址栏的外观来判断通信是否加密。Chrome 已在 2023 年 9 月的 Chrome 117 中取消锁形图标，改为打开站点设置的「tune」图标，因此判断依据应当是 URL 的协议是否为 https://，而不是有没有锁形标记。此外 HTTPS 保证的只是通信通道的加密和所连接域名的身份，并不保证网站运营者可信或内容正确，因为钓鱼网站同样可以用免费证书启用 HTTPS。

常见误解

HTTP 和 HTTPS 是完全不同的协议: HTTPS 是在 HTTP 基础上添加 TLS 加密的扩展。请求-响应结构、方法和状态码完全相同。理解了 HTTP 就理解了 HTTPS 的运作机制，区别在于是否有 TLS 加密层，以及随之而来的 URL 协议和默认端口 (80 与 443) 的差异。
升级到 HTTP/2 或 HTTP/3 一定能让网站变快: HTTP/2 的多路复用和 HTTP/3 的 QUIC 改善了网络层效率，但如果瓶颈在服务器端处理、数据库查询或前端渲染，感知速度可能不会改变。协议升级优化的是传输层，而非整个应用程序栈。
HTTP 是已经不再使用的过时技术: 在 HTTPS 成为公开网站事实标准之后，截至 2026 年 8 月，HTTP 仍在内部网络、开发环境以及 IoT 设备之间的通信中被广泛使用。而且 HTTP 的协议规范本身就是 HTTPS 的基础，两者的协议内容相同，只是在其上叠加了 TLS 加密。

HTTP (超文本传输协议)