2. HTTP协议栈与加速原理
HTTP 是 CDN 加速的核心承载协议。CDN 边缘节点之所以能显著降低首屏时间，很大程度上取决于它如何利用不同 HTTP 版本的传输特性来减少往返、并行传输和压缩冗余。理解 HTTP/1.1、HTTP/2、HTTP/3 在连接模型、并发方式、头部编码和握手时延上的差异，是判断“为什么某些站点上了 CDN 仍然慢”的基础。
一、HTTP/1.1：串行请求与队头阻塞的根源
HTTP/1.1 采用“一个 TCP 连接上请求—响应按序进行”的模型。虽然引入了持久连接（Keep-Alive）和管线化（Pipelining），但管线化要求响应必须按请求顺序返回，前一个响应未完成，后续响应只能等待，这就是应用层队头阻塞（HOL Blocking）。浏览器为了绕过它，通常对同一域名开启 6 个左右并发 TCP 连接，把请求分散到多条连接上。
这种做法的代价是：每条连接都要独立完成 TCP 三次握手和 TLS 握手，连接数越多，握手开销和拥塞控制慢启动的重复成本越高。此外，HTTP/1.1 头部以纯文本重复发送，Cookie、User-Agent 等字段在每个请求中反复出现，浪费带宽。在 CDN 场景中，若源站或边缘仍以 HTTP/1.1 回源，即使边缘缓存命中率很高，回源链路的队头阻塞仍会拖慢未命中请求。
二、HTTP/2：多路复用与头部压缩
HTTP/2 在一条 TCP 连接上引入二进制分帧层，把请求和响应拆分为带流 ID 的帧（HEADERS、DATA 等），实现多路复用：多个请求可同时在一条连接上交错传输，互不阻塞。这消除了 HTTP/1.1 的应用层队头阻塞，也减少了连接数量，使 TLS 握手和拥塞控制只需进行一次。
HTTP/2 还引入 HPACK 头部压缩：静态表预置常见头部字段，动态表记录本次连接中出现过的字段，后续请求只需发送索引而非完整字符串。对于携带大量 Cookie 的请求，HPACK 可显著降低头部体积。此外，HTTP/2 支持服务器推送（Server Push）和流优先级，但推送在实际 CDN 中因缓存和浏览器兼容问题使用谨慎。
需要注意的是，HTTP/2 的多路复用建立在单条 TCP 连接之上，一旦发生TCP 层丢包，所有流都会因 TCP 按序交付而等待重传，形成传输层队头阻塞。在弱网或高丢包环境下，HTTP/2 的加速效果可能反而不如多条 HTTP/1.1 连接。
三、HTTP/3：基于 QUIC 的0-RTT与流级独立
HTTP/3 将传输层从 TCP 换成 QUIC（基于 UDP）。QUIC 在用户态实现流控、重传和加密，每个流独立处理丢包：某条流丢包只影响该流，不会阻塞其他流，从根本上解决了传输层队头阻塞。
QUIC 将 TLS 1.3 握手与传输握手合并，首次连接通常只需 1 个 RTT 即可建立安全连接；对于之前连接过的服务器，客户端可缓存连接凭证，在后续连接中实现 0-RTT，即第一个数据包就可携带应用数据。这对 CDN 边缘节点意义重大：边缘节点分布广、用户重复访问同一节点概率高，0-RTT 能显著降低重复访问的建连时延。
不过 0-RTT 数据存在重放攻击风险，通常只用于幂等的 GET 请求。此外，QUIC 基于 UDP，部分企业网络或老旧防火墙可能限制 UDP 443 端口，导致回退到 HTTP/2。CDN 通常同时监听 TCP 443 和 UDP 443，通过 Alt-Svc 头部告知浏览器可升级到 HTTP/3。
四、关键特性对比与加速影响
下表从连接模型、并发方式、头部压缩、握手时延和队头阻塞五个维度对比三个版本，并给出对 CDN 加速的实际影响。
| 特性 | HTTP/1.1 | HTTP/2 | HTTP/3 |
|---|---|---|---|
| 传输层 | TCP | TCP | QUIC（UDP） |
| 并发方式 | 多连接（约6条/域名） | 单连接多路复用 | 单连接多路复用，流级独立 |
| 头部压缩 | 无（纯文本重复） | HPACK | QPACK |
| 建连时延 | TCP+TLS 多次 RTT | TCP+TLS，1-2 RTT | 1-RTT，可 0-RTT |
| 队头阻塞 | 应用层 HOL | TCP 层 HOL | 基本消除 |
| CDN 加速影响 | 连接多、握手重、头部冗余 | 减少连接与头部开销，弱网受 TCP 拖累 | 弱网与重复访问优势明显 |
五、CDN 工程中的选择与判断
在实际 CDN 部署中，边缘节点通常同时支持三种协议，由客户端与边缘协商决定。判断一个站点是否已从 HTTP/2 或 HTTP/3 中获益，可以观察以下信号：
- 连接数：HTTP/1.1 下浏览器对同域名并发约 6 条连接，HTTP/2/3 下通常收敛为 1 条。若抓包发现大量并发 TCP 连接，说明可能未启用 HTTP/2。
- 头部体积：对比同一页面在 HTTP/1.1 与 HTTP/2 下的请求头部字节数，HPACK 通常可减少 50% 以上。
- 弱网表现：在高丢包（如 3%～5%）环境下，HTTP/2 可能因 TCP 重传出现明显卡顿，而 HTTP/3 的流级独立能保持其他资源继续加载。
- 建连时延：重复访问同一 CDN 边缘节点时，HTTP/3 的 0-RTT 可将首字节时间进一步压缩，尤其对移动端和跨地域访问效果明显。
Alt-Svc 响应头引导浏览器升级到 HTTP/3；回源链路若源站支持 HTTP/2，也应启用，以减少回源连接数和头部开销。对于 UDP 被限制的网络，保留 HTTP/2 作为回退路径。
需要强调的是，协议升级并非万能。若站点瓶颈在源站计算、数据库查询或缓存命中率低，HTTP/3 的 0-RTT 也无法弥补。协议优化的价值在于：在传输层和表示层消除不必要的等待与冗余，让 CDN 的边缘缓存和就近接入优势真正转化为用户可感知的速度提升。