HTTP/1.1、HTTP/2与HTTP/3

可视化演示

交互式对比HTTP/1.1、HTTP/2和HTTP/3的核心特性差异，展示从文本协议到二进制分帧再到QUIC的演进历程，包括多路复用、头部压缩、0-RTT握手等关键改进。

文本传输时代

阿邮刚入行的日子最苦：网点规定，一辆单车一次只能装一件包裹，必须把这件送到、骑车回网点，才能领下一件。更麻烦的是，每次出车都要在门口盖章登记——相当于建立一条新连接。HTTP/1.1（1997 年发布）就是这样的单车时代：浏览器与服务器之间一次只能跑一个请求，请求和响应都是纯文本，像手写信一样逐行书写，人类用记事本都能直接读懂。

为了解决“每件包裹都重新登记”的浪费，HTTP/1.1 引入了 Keep-Alive 长连接，让同一辆单车在同一个村落里来回跑。但载客规则没变：一个连接上同时仍只能有一个请求在途。浏览器要加载网页里的 HTML、CSS、JS、图片等几十个资源时，只能排队——第一个资源没到，第二个请求根本发不出去，哪怕它只是一个小小的图标。

这种“前一个请求挡着后一个”的现象，就是队头阻塞（Head-of-Line Blocking）。它的延迟是串行叠加的：N 个资源要等 N 次往返。再加上新建连接时的 TCP 三次握手与 TLS 协商，每次连接都额外付出约两个往返时延（RTT）。在跨洋场景下 RTT 动辄上百毫秒，体验自然雪上加霜。

阿邮后来统计过：一个村子 30 个包裹，他要骑单车在同一条巷子里往返 30 趟，每趟还要回网点盖章。他说“我不是在送快递，是在排队”。HTTP/1.1 时代优化者的所有手段——开多个连接、拆多个域名——本质上都是“多雇几个阿邮”，可单车道的拥挤，并没有真正被解决。

二进制分帧

转机出现在 2015 年：公司引进了“集装箱化”——所有货物无论大小，一律拆装进统一规格的标准货箱，货箱上印着订单号，一辆大卡车可以同时装载几十个订单的箱子，到了同一条街，按订单号分发给不同客户。这就是 HTTP/2 的核心思想：二进制分帧层（Binary Framing Layer）。

HTTP/2 把请求和响应切成一个个二进制“帧”（Frame）：9 字节固定头部 + 最多 16KB 载荷。帧头里最重要的字段是 4 字节的流标识（Stream ID），它标注了这箱货属于哪个“订单”（流）。因为数据被切成带编号的小块，多个流的帧就能在同一条 TCP 连接上交错发送——你的请求和我的请求像混编在同一趟地铁车厢里的乘客，到站各自找门下车。

这种交错传输就是多路复用（Multiplexing）：一条连接同时承载成百上千个流，任何一个资源都不用等前面的资源完成。它从根上消灭了 HTTP 层的队头阻塞。帧按用途分为 HEADERS、DATA 等类型；流则有客户端发起的双向流与服务器发起的单向流之分，后者正是服务端推送的载体。帧的小而规整还带来额外红利：更细的传输粒度、更均匀的带宽占用，也为头部压缩创造了条件。

集装箱化的好处立竿见影，但阿邮很快发现新问题：卡车再能装，走的还是那条唯一的高速公路——TCP。公路上一旦修路（丢包），所有车、所有货都得停下来等交警放行（重传）。下一节，我们把目光投向这条“老公路”。

QUIC革新

2022 年，公司彻底换了玩法：给每件包裹配一架专属无人机。无人机自己带导航、自己报航线，完全不依赖地面的红绿灯和收费站。这就是 HTTP/3 的赌注——把传输层从服役四十年的 TCP 换成基于 UDP 的 QUIC。

为什么敢用“不可靠”的 UDP？因为 QUIC 在用户态（应用程序里）自己实现了可靠传输、拥塞控制、加密和流管理：相当于无人机自带飞行控制系统，不需要地面交警。TCP 做不到的事它都能做：每个流独立编号、独立确认、独立重传；连接用 Connection ID 标识而不是 IP 加端口；还能复用 TLS 1.3 的会话凭证，实现快速重连。

QUIC 有三张王牌：第一，独立流——一个流的丢包只重传自己，其他流照常送达，TCP 层的队头阻塞被彻底拆除；第二，0-RTT 握手——首次连接 1 个 RTT 即可发出请求，带会话恢复的重连甚至 0 个 RTT，而 HTTP/1.1 走 TCP+TLS 需要 2 到 4 个 RTT；第三，连接迁移——手机从 WiFi 切到 4G，连接不断、请求不丢，因为连接不再认“门牌号”（IP+端口），只认“身份证”（Connection ID）。

阿邮的无人机再也不怕“修路”了：哪怕一架飞机被大雨淋了返航，其他几十架照样把包裹准时送到。用户感受到的，就是视频不再转圈、游戏不再瞬移——这正是弱网环境下 HTTP/3 的杀手锏。

队头阻塞根因

让我们停下来，把“队头阻塞”这口锅看明白。它其实有两层：第一层在应用层——HTTP/1.1 的请求排队，像单车道的巷子里所有车只能鱼贯而行；第二层在传输层——TCP 的按序交付，像全城唯一的高速路有一段在修路，所有车都必须停下等待放行，哪怕你既不经过修路段，车上装的还是加急件。

HTTP/2 用多路复用拆掉了第一层——请求们不再排队了；但第二层它无能为力，因为所有流的数据最终都混进同一条 TCP 字节流，TCP 的规矩是“必须按顺序交给应用层”。一个数据段丢失后，后到的所有数据都要躺在接收缓冲区里等重传，即使它们属于其他毫发无损的流。这就是 HTTP/2 的“阿喀琉斯之踵”。

数学上这代价有多重？经典的 Mathis 公式给出了 TCP 连接的吞吐上限：吞吐 B 约等于最大报文段 MSS 除以 RTT 与丢包率平方根的乘积。丢包率从 0.1% 升到 1%，吞吐量就要掉到原来的约三分之一。在丢包率 1% 以上的弱网环境（移动、跨洋、卫星链路），这种退化肉眼可见。HTTP/3 的解法是“流”级别的独立：QUIC 里每个流都有独立的字节序列和确认机制，丢包的流自己慢慢等重传，其他流的数据立即上抛给应用——修你那一段路，其他车走自己的高架桥。

所以“队头阻塞”不是 HTTP/2 的 bug，而是 TCP 时代的地基缺陷。阿邮比喻成：卡车时代，只要高速路上有一段在修，满车包裹都困在源头；无人机时代，每架飞机有自己的航线，修路与我无关。理解了这一层，你就看懂了为什么所有云厂商都在抢着部署 HTTP/3。

连接复用进阶

聊完阻塞，再看“连接”本身怎么被一路优化。阿邮刚入职时，每送一单都要回网点重新盖章登记——每个请求都新建 TCP 连接，效率极低。HTTP/1.1 引入 Keep-Alive，让单车在同一个村落里反复使用，不用每次都登记；但规则仍是“一车一单”，单车道上依旧排队。

浏览器工程师们的对策很粗暴：开多条并行车道——为每个域名建立约 6 条连接（连接池管理），再把资源拆分到多个子域名上，让 6 条车道变成 18 条。代价是每条新连接都要付一次 TCP+TLS 握手的“登记费”，服务器也要维护海量连接的内存与文件描述符。HTTP/2 的答案完全不同：把 6 条小车道合成 1 条大高速公路，所有流在这条路上多路复用，只需要登记一次。

连接数量从多到少、从短到长，是三个版本最直观的演进线。HTTP/1.1 一请求一连接；HTTP/2 所有流共享一条 TCP 连接；HTTP/3 仍是一条连接，但这条连接是“打不死”的——QUIC 用 Connection ID 标识连接，设备换了 IP（WiFi 切 4G、DHCP 换地址），连接照样存活，应用层毫无感知。协议协商方面，浏览器通过 TLS 的 ALPN 扩展在握手时告诉服务器“我支持 HTTP/2 还是 HTTP/3”，双方选一个都能懂的语言，就像乘客上车前先确认坐几路公交。

阿邮的体会是：过去六辆小车排着队过收费口，每辆都要停车扫码；现在并成一辆大挂车，交一次费、一起进城。省下的时间在跨洋 RTT 超过 100ms 的场景里，是肉眼可见的“快了两三秒”。

头部压缩演进

阿邮每天最烦的是填快递单：同一个客户，姓名、电话、地址几乎不变，但他每寄一次包裹就要手写一次。HTTP/1.1 的请求头就是这张“重复填写的快递单”——User-Agent、Accept、Cookie、Host 等字段每次请求全量发送，动辄几百字节，而真正变化的内容往往只有几个字节，典型页面打开一次就要重复几千字节的头部。

HTTP/2 的 HPACK 压缩算法改变了规则：快递公司建了会员档案室。静态表预置 61 个常见字段的固定编号，比如"method: GET"直接用一个编号代替；动态表记录本次连接里新出现的字段，同一连接后续请求只需发一个索引号；再加上 Huffman 编码压缩长文本值。平均而言，一个 700 字节的请求头可以被压到 8~10 字节，体积约为原来的百分之一。

为什么头部压缩对 HTTP/2 尤其重要？因为多路复用下，一条连接承载大量小请求，头部的体积占比被放大了——如果每次请求都带全量头，前面公式里的帧效率 η 会被拖垮。而 HTTP/3 的 QPACK 是 HPACK 的“乱序适配版”：QUIC 的流可以乱序到达，动态表更新不能依赖“先到先查”的顺序，所以 QPACK 用专门的单向流同步表更新，让解压不依赖到达顺序。

会员档案建好之后，阿邮只需对着老客户喊一声“老地址”，对方就心领神会。头部压缩的道理一模一样：省下的不仅是流量，更是每一个请求的传输时间——在即时通信、网页加载这类短请求密集的场景里，收益被成倍放大。

流优先级控制

无人机多了，调度就成了艺术。阿邮的调度台屏幕上，任务分着轻重缓急：用户正在看的视频关键帧要立刻起飞，后台自动下载的安装包可以慢慢飞。HTTP/2 的流优先级机制，就是这个调度台。

每个流在创建时可以声明两件事：依赖关系（“我等 A 流先到”）和权重值（1~256 的整数，越大越优先）。服务器分配带宽时按权重比例切蛋糕：同级所有活跃流的权重之和是分母，某个流的权重是分子。这样浏览器就能让 HTML 和首屏 CSS 高权重快跑，让懒加载图片低权重慢飞，避免非关键资源抢占首屏的带宽。

流之间还能形成“优先级树”：父流先于子流，低优先级流可以给高优先级流让路。HTTP/3 沿用并强化了这套机制，还会在调度中加入抢占语义，让控制的颗粒度更细。一个现实例子：浏览网页时，如果图片下载和 CSS 下载同权重竞争，页面可能出现“样式闪变”；正确的优先级树能让 CSS 先行，画面一次渲染到位。

这就像医院分诊台：危重病人进抢救室，轻症患者排队候诊。调度台上的“优先级树”决定了用户体验的丝滑程度——首屏关键资源永远插队先飞，背景任务乖乖让路。阿邮说，真正的效率不是所有无人机一起抢，而是让该快的快、该等的等。

AI 应用场景

Python 演示

import random  def http11_latency(n_requests, rtt):    # HTTP/1.1: requests are serial, one RTT each    return n_requests * rtt  def http2_latency(n_requests, rtt, loss_p):    # HTTP/2: multiplexed but TCP is ordered, one loss stalls all streams    latency = rtt    for _ in range(n_requests):        if random.random() < loss_p:            latency += 3 * rtt  # retransmission timeout, every stream waits    return latency  def http3_latency(n_requests, rtt, loss_p):    # HTTP/3: independent streams, only the lost stream is delayed    latency = rtt    for _ in range(n_requests):        if random.random() < loss_p:            latency = max(latency, 3 * rtt)    return latency  def main():    random.seed(42)    n_requests = 10    rtt = 50  # ms    trials = 2000    for loss in (0.0, 0.02, 0.05):        l11 = sum(http11_latency(n_requests, rtt) for _ in range(trials)) / trials        l2 = sum(http2_latency(n_requests, rtt, loss) for _ in range(trials)) / trials        l3 = sum(http3_latency(n_requests, rtt, loss) for _ in range(trials)) / trials        print("loss={:.0%} http11={:.0f}ms http2={:.0f}ms http3={:.0f}ms".format(loss, l11, l2, l3))  if __name__ == "__main__":    main()

1. return n_requests * rttHTTP/1.1 串行：10 个请求就是 10 次往返时延，阿邮的单车只能一单一单送。
2. latency += 3 * rttHTTP/2 中一次丢包，整条连接都要等超时重传，所有流一起买单。
3. latency = max(latency, 3 * rtt)HTTP/3 中丢包只影响丢了的那个流，总延迟只看最慢的流。
4. random.seed(42)固定随机种子，让每次运行结果可复现，方便对比实验。
5. for loss in (0.0, 0.02, 0.05):分别模拟无丢包、2% 和 5% 丢包率下的三种协议延迟表现。

常见误区

面试题