超文本传输协议（Hypertext Transfer Protocol，HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议，是万维网数据通信的基础。它采用请求—响应模式，由客户端发起请求、服务器返回应答，通常承载在 TCP 之上，默认端口为 80，加密版本 HTTPS 默认使用 443 端口[1]。该协议由蒂姆·伯纳斯-李于 1989 年在欧洲核子研究组织发起，经互联网工程任务组与万维网协会协调，陆续以一系列 RFC 文件的形式发布。
定义
超文本传输协议是万维网上客户端与服务器之间交换信息所遵循的通信规则，规定了浏览器等客户端可以向服务器发送什么样的请求，以及服务器应当返回什么样的响应[2]。它是应用层协议的一种，其功能由运行在用户空间的应用程序实现，协议本身是一份记录在文档中的规范[2]。协议所传输的资源由统一资源标识符（Uniform Resource Identifiers，URI）来标识，设计它的最初目的是提供一种发布和接收 HTML 页面的方法。
协议本身并不限定必须使用 TCP，只要下层协议能够提供可靠传输即可，在 TCP/IP 协议族中实际使用 TCP 作为传输层。当它承载在 TLS 或 SSL 之上时，就形成了通常所说的 HTTPS[1]。
原理
HTTP 采用客户端／服务器模式，一次完整的交互被称为一个事务，基本过程包括建立连接、客户端发出请求、服务器返回响应、连接关闭等步骤[1]。请求与响应报文都由起始行、头部字段和可选的主体构成，头部以 ASCII 形式给出，消息内容则采用类似 MIME 的格式[2]。
协议是无状态的，即服务器不记忆此前请求的状态；这种设计使程序实现简单、便于服务器扩展，但无法跟踪多次交互的过程，购物类网站需要借助 cookie 等技术另行追踪[3]。为减轻服务器压力并提高效率，协议还引入了缓存机制，并允许传输任意类型的数据对象，由 Content-Type 标出正在传输的类型[1]。
HTTP/1.1 定义了多种请求方法，用来以不同方式操作指定资源。GET 用于请求读取资源，HEAD 只取回元信息而不传输资源主体，POST 用于向服务器提交数据，此外还有 PUT、DELETE、TRACE、OPTIONS 等方法。服务器返回的应答以一个三位数字的状态码开头，1xx 表示通知信息，2xx 表示成功，3xx 表示需要重定向，4xx 表示客户端错误，5xx 表示服务器错误[4]。
发展历程
协议的开发由蒂姆·伯纳斯-李于 1989 年在欧洲核子研究组织（CERN）发起，标准制定由万维网协会和互联网工程任务组协调推进，成果体现为一系列 RFC 文件。1991 年出现第一个有文档记载的正式版本，被命名为 HTTP/0.9，它只能传输文字，无法处理图片[2]。1996 年 5 月，RFC 1945 作为 HTTP/1.0 的最终修订版发布，该版本面向事务，对每一次请求与响应都建立并拆除一次连接[2]。
1999 年 6 月公布的 RFC 2616 定义了一直广泛使用的版本 HTTP/1.1，它默认采用持续连接，一个 TCP 连接可以传输多个请求，并增加了 Host 字段以支持在同一 IP 地址上运行多个虚拟主机。2014 年 6 月，HTTP/1.1 的规范被拆分为 RFC 7230 至 RFC 7235 等多份文档重新发布[5]。
与之前依赖 TCP 的版本不同，HTTP/3 使用基于 UDP 的 QUIC 传输协议，据称具有更低的延迟和更快的加载速度[2]。
HTTP/2 的前身是谷歌提出的 SPDY 协议，其设计思路被 HTTP/2 制定过程大量借鉴，因此 SPDY 通常被视为 HTTP/2 的前身[6]。HTTP/2 标准于 2015 年 5 月以 RFC 7540 正式发表。2022 年 6 月，HTTP/3 标准化为 RFC 9114[7]。
应用
浏览网页是 HTTP 最主要的应用场景，用户在浏览器中输入网址时，浏览器向服务器发出请求，服务器返回包含超文本标记语言、样式表、脚本和图片等内容的响应，浏览器解析后呈现页面[8]。除网页浏览外，只要通信双方都遵循该协议，它还可用于传输图片、视频等各种数据[1]。
服务器端的实现程序包括 httpd、nginx 等，客户端实现则主要是各类 Web 浏览器，此外还有 curl 等命令行工具[2]。在移动互联网中，各类客户端应用也大量使用该协议，电商类应用加载首页时可能发出十多个请求[9]。
由于协议以明文方式发送内容，不提供数据加密，若传输报文被截取，其中的信息可被直接读取，因此不适合传输信用卡号、密码等敏感信息，这类场景需要使用加密的 HTTPS[10]。
局限
协议采用严格的请求／响应模式，永远由客户端先发起请求、服务器再回送响应，因此无法在客户端未发起请求时由服务器主动推送消息；若需要服务器推送能力，可改用 WebSocket 或服务器发送事件等技术[1]。
HTTP/1.1 存在队头阻塞问题，即同一连接上前一个响应未完成时，后续响应只能等待，管道化技术试图缓解这一点但未能真正解决，因而多数浏览器默认将其关闭，改为对同一域名建立多个 TCP 连接来提升并发[11]。此外，HTTP/1.1 的头部字段是未压缩的文本，且每次请求都重复携带，造成不必要的流量开销[12]。
HTTP/2 通过多路复用解决了应用层的队头阻塞，但由于其底层仍是 TCP，而 TCP 保证按序交付，一个数据包丢失会阻塞连接上的所有流，因此传输层的队头阻塞依然存在，这正是 HTTP/3 转向 QUIC 的主要原因[12]。HTTP/2 中作为亮点提出的流优先级依赖树和服务器推送，在实际部署中因各浏览器与服务器实现不一致、收益有限而被弃用。
参见
参考资料
- Netty——HTTP之HTTP协议-华为开发者话题 | 华为开发者联盟 [引用日期2026-10-14]
- 科普中国-HTTP - 版权归原作者所有，如有侵权，请联系我们 [引用日期2026-10-14]
- インターネット用語1分解説～HTTPとは～ [引用日期2026-10-14]
- springer.com 上的网页 [引用日期2026-10-14]
- RFC_2616 [引用日期2026-10-14]
- HTTP/3 发布了，我们来谈谈 [引用日期2026-10-14]
- RFC 9114: HTTP/3 | RFC Editor [引用日期2026-10-14]
- 【计算机网络】HTTP 协议-1 [引用日期2026-10-14]
- [科普中国]-http [引用日期2026-10-14]
- 【前端 · 面试 】HTTP 总结（一）—— HTTP 概述 [引用日期2026-10-14]
- HTTP 2.0 为什么这么设计？ [引用日期2026-10-14]
- Hypertext Transfer Protocol Version 2 (HTTP/2) [引用日期2026-10-14]