How Speedy is SPDY — 换协议没让网页变快多少

是什么

SPDY 是 Google 2009 年开始推的一个新协议，号称要替代 HTTP 1.1，让网页加载更快。它后来直接演化成了 HTTP/2，今天浏览器和服务器都默认在用。

这篇 NSDI 2014 论文做了一件挺反共识的事——实测一遍，问”换上 SPDY 之后网页真的变快了吗？”

结论让人意外：在真实场景下，SPDY 比 HTTP 1.1 大概快 4–15%，标准差还很大；遇到丢包甚至更慢。和 Google 当初宣传的”提速 50%+“差距巨大。

日常类比：你新装了一条更宽的高速公路（SPDY 多路复用），但发现堵车的真正原因是收费站慢（浏览器解析 JS）+ 车队必须按顺序走（页面资源依赖）。路再宽也没用。

为什么重要

不理解这篇，下面这些事都没法解释：

为什么 HTTP/2 出来了，但很多大网站测试发现”换了反而没快”
为什么后来 Google 又搞了 QUIC（HTTP/3）——它解决的正是这篇里点出的 TCP 单连接弱点
为什么”系统优化”经常被一句”benchmark 显示快了 30%“忽悠——单点测试根本说明不了真实部署
为什么协议设计要看完整 stack：网络层、TCP、浏览器计算、页面结构是耦合的

核心要点

论文的关键贡献是一个叫 isolating framework 的测试方法。把影响网页加载时间的三大变量分别隔离测量：

网络：固定 RTT 和丢包率（用 dummynet 在内核层 shape 流量）
浏览器计算：先把页面下载完缓存，再用 cache 模式回放，剥离网络
页面依赖：分析 HTML，看哪些资源必须串行加载

只有把这三块分开，才能看清楚 SPDY 到底是哪一段帮了忙、哪一段没帮上。之前的工作（包括 Google 自己的）都是端到端测一个数字，混杂的变量太多，结论经常互相矛盾。

测下来核心发现：

多路复用确实减少了网络 RTT——但只在丢包率极低时才显著
TCP 单连接是双刃剑：丢包时所有 stream 一起卡住（队头阻塞，HoL blocking）
浏览器计算在很多页面上 > 网络时间：协议再快也救不了
资源依赖让多路复用打折：CSS 必须先到才能解析后续 JS，并行下载没意义
服务器推送有用：如果服务器主动 push 依赖资源，能补回大部分差距
HTTP 1.1 的 6-连接策略意外抗丢包：每条连接独立恢复，损失被分散

实践案例

案例 1：丢包让 SPDY 反而更慢

测试条件：RTT 200ms，packet loss 1%。

协议	平均 PLT	备注
HTTP 1.1（6 连接）	3.2s	一个连接丢包，其他 5 个继续跑
SPDY（1 连接）	4.1s	单连接丢包，所有 stream 暂停

为什么：HTTP 1.1 浏览器开 6 条 TCP 连接做”水平扩展”，丢包伤害被分散。SPDY 把一切塞进一条连接，TCP 的有序保证让丢包变成全局停顿。这个问题最后逼出了 QUIC——把多路复用搬到 UDP 上避开 TCP。

案例 2：浏览器计算压死协议优化

测试一个新闻类页面：

HTTP 1.1 总 PLT：2.8s
  网络下载：1.2s
  解析+渲染：1.6s

SPDY 总 PLT：2.5s
  网络下载：0.9s（省了 0.3s）
  解析+渲染：1.6s（一秒没省）

协议层省下的 0.3s 在 1.6s 的解析+渲染面前看起来很小。协议优化的天花板就是网络部分本身。

案例 3：服务器推送的潜力

如果服务器分析过页面、知道一个 HTML 后续会请求哪些 CSS / JS，可以在 HTML 响应里主动 push这些资源。测试显示这能再省 20-30% PLT。

普通 SPDY：2.5s
SPDY + push 关键资源：1.9s

但这需要服务器懂页面结构，工程上很难做对——所以 HTTP/2 的 push 后来基本没人用，2022 年从规范里直接删了。

案例 4：高 RTT 长肥管道下 SPDY 才显出真本事

跨太平洋链路、RTT 300ms、丢包率几乎为 0：

HTTP 1.1：5.8s（每条连接握手都吃一个 RTT）
SPDY    ：3.4s（单连接复用，握手只付一次）

这种场景下多路复用不被 TCP 拖累，SPDY 的设计优势真的兑现。也解释了为什么移动网络（高 RTT）部署 SPDY 收益更明显。

踩过的坑

不是说 SPDY 没用：对 HTTPS 站点（每次握手贵）和移动网络（高 RTT），SPDY 仍有真实价值。论文说的是”远不如宣传”，不是”完全没用”。
2014 年的实现不成熟：测试用的浏览器和服务器 SPDY 栈都还在早期。今天 HTTP/2 实现质量好很多，差距可能比论文里小。但结构性问题（HoL、依赖、计算）依然在。
isolating 是双刃：把网络/计算/依赖完全分开测，丢失了一些真实交互。比如计算和下载会重叠，论文的简化模型抓不到。
benchmark 容易误导：Google 早期”SPDY 快 50%“的数据是在内部最优条件下测的（页面平坦、无丢包、CDN 近）。任何”协议 / 系统快 X%“的宣传都要先问”在什么 workload 下”。

适用 vs 不适用场景

适用：

想理解 HTTP/2 / HTTP/3 设计动机——这篇是直接源头
做系统性能研究，需要参考方法学——isolating framework 是经典案例
评估”换协议就能加速”类宣传时的批判工具
网络协议课程的实证文献入门

不适用：

想直接拿到”该用 SPDY 还是 HTTP 1.1”的工程结论——今天答案早是 HTTP/2 / 3
移动端深度优化——本论文主要测桌面 Chrome
想了解 QUIC 细节——QUIC 是后续工作

历史小故事

2009 年：Google 启动 SPDY 项目，目标是”让 web 快两倍”。早期 demo 数据非常漂亮。
2012-2013 年：Twitter / Facebook 等大站开始部署 SPDY，但内部数据并不一致——有人快、有人没快。
2014 年：Wang 等人发表这篇 NSDI 论文，把”为什么不一致”系统讲清楚。这篇影响了 IETF 在 HTTP/2 标准化时的取舍。
2015 年：HTTP/2 发布（RFC 7540），基本是 SPDY 改了名字。
2018 年：Google 把 QUIC（基于 UDP，绕开 TCP HoL）变成 IETF 标准，2022 年成为 HTTP/3。Wang 这篇里点出的 TCP 单连接缺陷正是 QUIC 的核心动机。
2022 年：HTTP/2 server push 从规范里被删除——印证论文里”工程上很难做对”的判断。

学到什么

协议优化必须看完整 stack：网络、TCP、浏览器、页面结构是耦合的，单层优化容易被其他层吃掉
方法学比结论更重要：isolating framework 让后续研究能可复现地对照测试，比”SPDY 快 X%“更有长期价值
多路复用 + 单连接 = 队头阻塞：这是 SPDY → QUIC 的根本驱动力，TCP 的有序保证在多 stream 下成了负担
benchmark 要警惕：任何”我们的系统 / 协议比基线快 X%“的数字，都要先问”测了哪些 workload？谁的实现？哪种网络条件？”
工业标准的演化路径：好想法（SPDY）→ 实证发现局限（这篇）→ 设计修正（QUIC）→ 标准化（HTTP/3）。每一步隔几年。

关联

akamai-2002 —— CDN 是另一条加速路径，和协议优化互补：协议层省 RTT，CDN 把 RTT 直接缩小
saltzer-1984-e2e —— 端到端原则；提醒”低层优化不能保证应用层好处”，本篇是这个原则的活教材
tcp-bbr —— TCP 拥塞控制改进；和 SPDY 是不同层的努力，丢包恢复策略影响 SPDY 表现

反向链接

akamai-2002 —— Akamai 2002 — 把网站搬到离用户 10 毫秒的地方
b4-2013 —— B4 — Google 用 SDN 把跨数据中心 WAN 利用率拉到 95%+
saltzer-1984-e2e —— End-to-End Arguments — 把功能尽量推到端上做