HTTP协议

为什么面试总爱问 HTTP

HTTP 是 Web 世界里最常见的应用层协议。浏览器打开页面、前端调用接口、服务端返回 JSON、CDN 分发静态资源，本质上都绕不开一次次 HTTP 交互。

面试里问 HTTP，通常不是想听“HTTP 是超文本传输协议”这一句定义，而是想判断你是否理解：一个请求从发出到返回，中间经历了什么；协议版本为什么不断演进；HTTP/1.1、HTTP/2、HTTP/3 分别解决了哪些问题，又留下了哪些代价。

HTTP 的基本定位

HTTP，全称 HyperText Transfer Protocol，是一种运行在应用层的请求-响应协议。它本身不负责寻址、传输可靠性和加密，通常需要依赖下层协议：

• IP：负责把数据包送到目标主机。
• TCP：提供可靠、有序、面向连接的字节流传输。
• TLS：在 HTTPS 中提供加密、身份认证和完整性校验。
• QUIC：在 HTTP/3 中替代 TCP，基于 UDP 实现可靠传输、多路复用和拥塞控制。

从使用者视角看，HTTP 关心的是“客户端想要什么资源”和“服务端如何返回结果”。一个典型请求包含请求行、请求头、空行和请求体；一个典型响应包含状态行、响应头、空行和响应体。

GET /articles/httpProtocol HTTP/1.1
Host: example.com
Accept: text/html

服务端会返回状态码、响应头和内容：

HTTP/1.1 200 OK
Content-Type: text/html
Cache-Control: max-age=3600

这套文本格式很直观，利于调试，也让 HTTP/1.x 很容易被人理解。但随着页面资源越来越多、接口数量越来越大，文本协议、连接管理和传输效率逐渐暴露出瓶颈。

一次 HTTP 请求发生了什么

以浏览器访问一个 HTTPS 页面为例，大致流程如下：

1. URL 解析：浏览器解析协议、域名、端口、路径和查询参数。
2. DNS 查询：把域名解析成 IP 地址，可能命中浏览器、系统、路由器或递归 DNS 缓存。
3. 建立连接：HTTP/1.0、HTTP/1.1、HTTP/2 通常先建立 TCP 连接；HTTPS 还要完成 TLS 握手。
4. 发送请求：浏览器按协议格式发送请求行、请求头和请求体。
5. 服务端处理：网关、应用服务、缓存、数据库等组件协作生成响应。
6. 返回响应：服务端返回状态码、响应头和响应体。
7. 连接复用或关闭：根据协议版本和连接策略，连接可能被关闭，也可能继续给后续请求使用。

这里最容易被忽略的是连接成本。一次 TCP 连接需要三次握手，HTTPS 还要 TLS 握手。如果每个资源都重新建连，延迟会被放大。因此 HTTP 的版本演进，很大一部分都在围绕“减少连接成本”和“提升单连接吞吐”展开。

HTTP/1.0：简单但连接成本高

HTTP/1.0 的模型很直接：客户端发起请求，服务端返回响应，然后通常关闭连接。

这种设计的优点是简单，服务端实现成本低，请求之间天然隔离。但它也带来明显问题：一个页面如果有 HTML、CSS、JS、图片等几十个资源，就可能需要反复建立 TCP 连接。

HTTP/1.0 的特点

• 默认短连接：每个请求通常独占一个 TCP 连接，请求完成后连接关闭。
• 无强制 Host 头：早期一个 IP 通常只对应一个站点，虚拟主机场景支持不足。
• 缓存能力较弱：已有 Expires、If-Modified-Since 等机制，但整体不如后续版本完善。
• 实现简单：适合早期页面资源少、并发压力不高的 Web 场景。

HTTP/1.0 最大的问题不是“不能用”，而是“不适合现代网页的资源规模”。当页面加载需要大量小资源时，频繁建连会带来额外 RTT、慢启动和服务端连接压力。

HTTP/1.1：长连接、管线化与更成熟的缓存

HTTP/1.1 最重要的改进是默认使用持久连接，也就是常说的长连接。多个请求可以复用同一个 TCP 连接，避免每次请求都重新握手。

连接复用

HTTP/1.1 默认开启 Connection: keep-alive。客户端请求一个资源后，连接不会立即关闭，后续请求可以继续使用这条连接。

这解决了 HTTP/1.0 频繁建连的问题，但也没有完全解决并发问题。HTTP/1.1 在同一条连接上，请求和响应仍然要按顺序处理。即使引入了管线化，客户端可以连续发送多个请求，服务端响应也必须按请求顺序返回。

队头阻塞

HTTP/1.1 的队头阻塞发生在应用层。同一条连接上连续发送三个请求时：

请求 A -> 请求 B -> 请求 C

如果请求 A 的响应很慢，请求 B 和请求 C 即使已经处理完成，也不能越过 A 先返回。这样一来，慢请求会挡住后面的快请求。

浏览器后来通常通过“同一域名开多个 TCP 连接”来缓解这个问题。但连接开多了又会带来新的成本：更多握手、更多拥塞窗口、更多服务端资源占用。

HTTP/1.1 的特点

• 默认长连接：减少 TCP 握手和慢启动成本。
• Host 头必需：支持同一 IP 部署多个站点。
• 缓存机制增强：引入 Cache-Control、ETag、If-None-Match 等更灵活的缓存控制。
• 支持分块传输：Transfer-Encoding: chunked 允许响应体边生成边发送。
• 存在应用层队头阻塞：同一连接内响应顺序受限。

HTTP/1.1 适合大量传统 Web 服务和 REST API，兼容性极好。即使今天 HTTP/2 和 HTTP/3 已经普及，HTTP/1.1 仍然是很多系统的基础兜底协议。

HTTP/2：二进制分帧与多路复用

HTTP/2 的核心目标是提升单个连接的传输效率。它没有改变 HTTP 的语义，请求方法、状态码、URI、Header 这些概念都还在；真正变化的是底层传输格式。

HTTP/1.x 是文本协议，HTTP/2 改成了二进制协议。请求和响应会被拆成更小的帧，在同一条 TCP 连接里交错传输。

二进制分帧

HTTP/2 把通信单位拆成帧，常见帧包括：

• HEADERS 帧：传输请求头或响应头。
• DATA 帧：传输请求体或响应体。
• SETTINGS 帧：协商连接参数。
• WINDOW_UPDATE 帧：用于流量控制。

帧属于某个 Stream。一个 Stream 对应一次请求-响应。多个 Stream 可以共享同一个 TCP 连接。

多路复用

多路复用是 HTTP/2 最关键的能力。多个请求不再需要排队等待完整响应，而是可以在一条 TCP 连接上并发传输：

连接：A1 B1 C1 A2 C2 B2 A3

接收端根据 Stream ID 把不同帧重新组装成各自的请求或响应。这样，请求 B 不必等待请求 A 完整返回，HTTP/1.1 的应用层队头阻塞被明显缓解。

但要注意，HTTP/2 仍然基于 TCP。TCP 要保证字节流有序可靠，如果某个 TCP 包丢了，后续已经到达的包也不能直接交给上层处理。于是 HTTP/2 解决了 HTTP 层面的队头阻塞，却仍然可能遇到 TCP 层面的队头阻塞。

Header 压缩

HTTP 请求头经常很大，尤其是 Cookie、User-Agent、Accept 等字段。HTTP/1.x 每次都以文本形式重复发送，浪费带宽。

HTTP/2 使用 HPACK 做 Header 压缩。它通过静态表、动态表和 Huffman 编码减少重复头部的传输体积。简单理解，连接两端维护一张“常用头部字典”，后续请求可以用索引代替完整字符串。

HTTP/2 的特点

• 二进制分帧：解析更高效，也为多路复用打基础。
• 多路复用：多个 Stream 共享一条 TCP 连接，减少连接数量。
• Header 压缩：HPACK 降低重复头部带宽开销。
• 服务端推送：服务端可以主动推送资源，但实际落地复杂，现代浏览器支持已逐渐收缩。
• 仍受 TCP 队头阻塞影响：丢包时整个 TCP 连接上的 Stream 都可能被拖慢。

HTTP/2 适合 HTTPS 网站、接口较多的单页应用、静态资源较多的页面，以及希望减少连接数和提升首屏加载效率的场景。

HTTP/3：基于 QUIC 的下一代 HTTP

HTTP/3 最大的变化是把传输层从 TCP 换成了 QUIC。QUIC 基于 UDP 实现，但它不是“不可靠传输”。相反，QUIC 在用户态重新实现了可靠性、拥塞控制、流量控制、连接迁移和加密握手。

为什么要用 QUIC

HTTP/2 的多路复用已经很好，但它仍然受制于 TCP。TCP 只认识一条有序字节流，不知道里面有多少个 HTTP Stream。只要底层某个包丢了，后续数据即使属于其他 Stream，也必须等丢失数据重传后才能继续交付。

QUIC 从设计上就理解“流”的概念。不同 Stream 之间相互独立，一个 Stream 丢包，不会阻塞其他 Stream 的数据交付。这就是 HTTP/3 解决 TCP 层队头阻塞的关键。

可靠性与拥塞控制

QUIC 虽然基于 UDP，但仍然提供可靠传输。它会对数据包编号、确认、重传，并维护发送窗口。和 TCP 类似，QUIC 也有拥塞控制，用来避免把网络链路打满导致整体性能下降。

不同点在于，QUIC 在用户态实现，迭代速度更快，不需要等待操作系统内核升级。它还把 TLS 1.3 集成进握手流程，减少建连延迟。在理想情况下，QUIC 可以做到 0-RTT 恢复连接，对移动网络和频繁建连场景很友好。

连接迁移

TCP 连接由四元组标识：源 IP、源端口、目标 IP、目标端口。手机从 Wi-Fi 切到 4G，IP 变了，TCP 连接通常就断了。

QUIC 使用 Connection ID 标识连接。即使客户端 IP 或端口变化，只要 Connection ID 还能被识别，连接就可以迁移。这对移动端、弱网和网络切换场景非常重要。

HTTP/3 的特点

• 基于 QUIC/UDP：绕开 TCP 的内核限制，在用户态实现传输能力。
• 天然多路复用：Stream 独立传输，减少传输层队头阻塞。
• 内置 TLS 1.3：安全能力成为协议基础部分。
• 连接建立更快：支持更少 RTT 的握手和 0-RTT 恢复。
• 连接迁移友好：适合移动网络切换。
• 部署成本更高：UDP 可用性、负载均衡、网关、防火墙和观测体系都需要配套支持。

HTTP/3 适合对延迟敏感、移动端占比高、跨地域访问多、弱网明显的业务。但在内网服务、传统企业网络或 UDP 受限环境中，HTTP/2 和 HTTP/1.1 仍然需要作为回退方案。

四个版本的核心对比

这张表可以作为面试回答的骨架。展开时不要只背结论，要顺着“问题—改进—新代价”的逻辑说：HTTP/1.0 简单但建连多；HTTP/1.1 复用连接但有队头阻塞；HTTP/2 多路复用但受 TCP 丢包影响；HTTP/3 用 QUIC 缓解传输层阻塞，但部署复杂度更高。

常见面试追问

HTTP/2 已经多路复用了，为什么还需要 HTTP/3

因为 HTTP/2 的多路复用发生在 HTTP 层，底层仍然是一条 TCP 有序字节流。TCP 丢包时，后续数据即使属于其他 Stream，也不能被上层及时使用。HTTP/3 使用 QUIC，让 Stream 在传输层就相互独立，减少丢包对其他请求的影响。

HTTP/3 基于 UDP，是不是不可靠

不是。UDP 只是不提供可靠性，但 QUIC 在 UDP 之上实现了可靠传输，包括包编号、ACK、重传、流量控制和拥塞控制。可以把 UDP 理解成 QUIC 的承载层，而不是业务直接裸用 UDP。

HTTP/1.1 的 keep-alive 和 HTTP/2 多路复用有什么区别

keep-alive 是复用 TCP 连接，但同一连接内响应仍然受顺序约束；HTTP/2 多路复用是把多个请求拆成帧并交错传输，接收端按 Stream ID 组装。前者主要减少建连成本，后者进一步提升同一连接上的并发传输能力。

Header 压缩为什么重要

现代请求头可能包含大量 Cookie、鉴权信息、客户端能力声明等字段。如果每个请求都重复发送完整头部，会浪费带宽，尤其是在移动网络和高频接口场景中更明显。HTTP/2 的 HPACK、HTTP/3 的 QPACK 都是为减少这部分重复开销设计的。

生产选型建议

实际项目里，很少需要开发者手动“实现” HTTP 版本，更多是在浏览器、网关、CDN、负载均衡和服务框架中做启用与回退。

• 兼容性优先：HTTP/1.1 仍然要保留，作为各种客户端和网络环境的兜底。
• Web 站点默认优先 HTTP/2：开启成本相对低，对多资源页面和接口并发都有收益。
• 移动端和弱网可评估 HTTP/3：如果 CDN、网关、监控和安全设备都支持，再逐步灰度。
• 不要迷信单一版本：协议升级不是万能药，缓存策略、资源合并拆分、CDN 命中率、服务端响应时间同样会影响体验。
• 关注观测能力：上线 HTTP/2 或 HTTP/3 后，需要观察握手耗时、TTFB、错误率、重传率、P95/P99 延迟等指标。

总结

HTTP 的演进主线可以概括为：更少的连接成本，更高的并发效率，更低的队头阻塞影响。

HTTP/1.0 胜在简单，但短连接成本高；HTTP/1.1 通过长连接和更成熟的缓存机制支撑了很长时间的 Web 发展，但应用层队头阻塞明显；HTTP/2 通过二进制分帧、Header 压缩和多路复用提升了单连接效率，不过仍受 TCP 队头阻塞影响；HTTP/3 基于 QUIC，把可靠性、拥塞控制、多路复用和 TLS 1.3 集成到新的传输协议中，更适合移动网络和低延迟场景。

面试回答时，最稳的表达方式是先讲 HTTP 的请求-响应模型，再按版本说明它们分别解决了什么问题。只要能把连接复用、队头阻塞、二进制分帧、多路复用、Header 压缩和 QUIC 这几条线串起来，HTTP 协议这类题基本就能答得比较完整。