Li6Daily

Appearance

2024-09-06
1647
6.2m

HTTP 版本 ​

一、总览 ​

版本发布年份传输层核心变化
HTTP/0.91991TCP仅 GET，无头部，纯文本
HTTP/1.01996TCP引入请求/响应头、状态码
HTTP/1.11997TCP持久连接、管道化、Host 头
HTTP/22015TCP二进制分帧、多路复用、头部压缩
HTTP/32022QUIC(UDP)解决队头阻塞、连接迁移

本文重点对比 HTTP/1.1、HTTP/2、HTTP/3 三者的特性区别与优化提升。

二、HTTP/1.1 ​

HTTP/1.1 是长期以来的主流版本，在 HTTP/1.0 基础上做了大量增强。

主要特性 ​

  • 持久连接（Keep-Alive）：默认 Connection: keep-alive，多个请求复用同一条 TCP 连接，避免频繁三次握手和慢启动开销。
  • 管线化（Pipelining）：理论上可一次性发送多个请求，但响应必须按序返回，存在队头阻塞（Head-of-Line Blocking），且多数服务器/代理支持有限，实际很少启用。
  • 分块传输（Chunked）：Transfer-Encoding: chunked 支持流式传输，不必提前知道内容长度。
  • Host 头（必需）：支持虚拟主机，一台服务器可托管多个域名。
  • 缓存控制增强：引入 Cache-Control、ETag、If-None-Match 等更精细的缓存机制。
  • 断点续传：Range 请求支持部分内容获取。
  • 新增方法：PUT、DELETE、OPTIONS、PATCH 等。

主要问题（被后续版本优化） ​

  1. 队头阻塞：虽然连接可复用，但同一条连接上请求必须串行等待，前一个响应慢会阻塞后面所有请求。
  2. 并发受限：浏览器对同一域名的并行 TCP 连接数有限（通常 6 个），高并发时仍需多条连接。
  3. 头部冗余：每次请求都重复发送大量相似头部（Cookie、User-Agent 等），浪费带宽。
  4. 文本协议：解析效率低，易出错。

三、HTTP/2 ​

HTTP/2 于 2015 年发布（基于 Google 的 SPDY 协议），语义与 HTTP/1.1 完全兼容（方法、状态码、头部字段不变），但传输方式彻底重构。

核心优化 ​

  1. 二进制分帧（Binary Framing）

    • 不再是人类可读的文本，而是把数据拆成二进制帧（Frame），解析高效、不易出错。
    • 帧是最小传输单位，归属于某个流（Stream）。

  2. 多路复用（Multiplexing） —— 最核心的改进

    • 在单条 TCP 连接上并行传输多个请求/响应。
    • 每个请求是一个独立的流（Stream），带有流 ID，帧可交错发送，接收端按 ID 重组。
    • 彻底解决 HTTP/1.1 的应用层队头阻塞，同时减少 TCP 连接数。
    HTTP/1.1:  连接1: [请求A]→[响应A] [请求B]→[响应B]   (串行)
HTTP/2:    连接1:  流1: A帧A帧   流2: B帧B帧B帧    (交错并行)

  3. 头部压缩（HPACK）

    • 维护客户端/服务器两张静态+动态字典表，重复头部只传索引。
    • 大幅降低头部体积（常见场景下头部可压缩 80%~90%）。

  4. 服务器推送（Server Push）

    • 服务器可主动把客户端「可能需要的资源」推过去（如 HTML 引用的 CSS/JS），减少往返。
    • 实际使用中因缓存、带宽控制等问题效果有限，部分浏览器已弃用。

  5. 请求优先级（Stream Priority）

    • 可给流设置优先级，重要资源（如 CSS）优先传输。

仍存在的局限 ​

  • TCP 层的队头阻塞：HTTP/2 的多路复用建立在单条 TCP 连接上。一旦 TCP 层某个包丢失，整个连接的所有流都要等待重传，这就是 TCP 级队头阻塞。
  • 握手延迟：基于 TCP + TLS，仍需多次往返才能建连。

四、HTTP/3 ​

HTTP/3 于 2022 年正式标准化（RFC 9114），最大的改变是把传输层从 TCP 换成了基于 UDP 的 QUIC 协议。

为什么会诞生 HTTP/3？ ​

HTTP/2 的瓶颈在 TCP：单连接上的多路复用，一旦丢包整条连接阻塞。而 TCP 的队头阻塞无法在应用层修复，只能换传输层。QUIC 在 UDP 之上重建了可靠的、多路复用的传输能力。

核心优化 ​

  1. 基于 QUIC（UDP）

    • QUIC 在用户态实现可靠传输，多个流独立，单个流丢包只阻塞该流，彻底解决 TCP 级队头阻塞。

  2. 0-RTT / 1-RTT 建连

    • 首次连接 1-RTT（QUIC + TLS 合并握手）。
    • 后续重连可 0-RTT 直接发数据，相比 TCP+TLS 的 2~3 RTT 大幅降低延迟。

  3. 连接迁移（Connection Migration）

    • 用 Connection ID 标识连接，而不是靠「IP + 端口」四元组。
    • 切换网络（如 Wi-Fi 切 4G）时连接不中断，无需重连。

  4. 内置 TLS 1.3

    • QUIC 将加密层与传输层融合，所有数据默认加密，更安全。

  5. 改进的拥塞控制与丢包恢复

    • QUIC 在用户态实现，更新迭代更快，拥塞控制算法可灵活替换。

代价与挑战 ​

  • UDP 可能被部分网络/防火墙限制或限速。
  • 内核无法像 TCP 那样深度优化，实现复杂度集中在用户态。
  • 加密解密开销上移到用户态。

五、三版本对比总表 ​

对比项HTTP/1.1HTTP/2HTTP/3
传输层TCPTCPQUIC（基于 UDP）
协议格式文本二进制帧二进制帧
并发模型多连接 + 管线化（受限）单连接多路复用单连接多路复用
队头阻塞应用层阻塞解决应用层，存在 TCP 层阻塞彻底解决（流级独立）
头部明文重复传输HPACK 压缩QPACK 压缩（类似 HPACK）
建连延迟TCP+TLS 2~3 RTT同 HTTP/1.11-RTT / 0-RTT 重连
连接迁移不支持（IP 变即断）不支持支持（Connection ID）
服务器推送无有（已渐弃用）已移除
安全性可选 HTTPS普遍 HTTPS强制内置 TLS 1.3
兼容性最广泛语义兼容 1.1需客户端/服务端支持

六、演进脉络一句话总结 ​

  • HTTP/1.1 → HTTP/2：从「文本 + 多连接」升级为「二进制 + 单连接多路复用 + 头部压缩」，解决了应用层队头阻塞和头部冗余。
  • HTTP/2 → HTTP/3：从「TCP」换到「UDP + QUIC」，解决了 TCP 层队头阻塞，并带来 0-RTT 建连和连接迁移能力，核心目标是降低延迟、提升弱网/移动网络体验。

选择建议：现代 Web 站点应优先启用 HTTP/2（兼容性最好）；面向移动端、弱网或延迟敏感场景可进一步启用 HTTP/3；二者通常通过 CDN/反向代理（如 Nginx、Cloudflare）开启，对业务代码透明。

最近更新