跳转到内容
Jason's Study

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

待复核

是什么

Section titled “是什么”

SPDY 是 Google 2009 年开始推的协议，想替代 HTTP 1.1 让网页加载更快；它后来演化成 HTTP/2。

这篇 NSDI 2014 论文做了一件反共识的事——实测一遍：换上 SPDY 之后，页面加载时间（PLT，Page Load Time）真的变短了吗？

结论比宣传冷静：忽略依赖与浏览器计算时，SPDY 往往明显更快；但把真实页面依赖和计算加回来后，收益常被吃掉——论文摘要里低带宽、高 RTT 场景大约只剩 约 7%。Google 早期白皮书写过约 27–60% 加速，和真实部署差距很大。丢包时单 TCP 连接甚至会让 SPDY 更慢。

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

为什么重要

Section titled “为什么重要”

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

  • 为什么 HTTP/2 上线后，很多大站实测”换了反而没快多少”
  • 为什么后来又有 QUIC / HTTP/3——它要绕开这篇点出的 TCP 单连接弱点
  • 为什么”benchmark 快了 30%“经常忽悠人——单点测试说明不了真实部署
  • 为什么协议设计要看完整 stack：网络、TCP、浏览器计算、页面结构是耦合的

核心要点

Section titled “核心要点”

论文关键贡献是 isolating framework（隔离式测试）：把影响 PLT 的变量拆开测。

  1. 网络：用 dummynet（内核层流量整形，像给水管装阀门）固定 RTT 和丢包率。类比：先只测路况，不管司机反应。
  2. 浏览器计算：用 Epload 录下计算延迟再回放，剥离真实浏览器抖动。类比：把收费站耗时录成固定秒数。
  3. 页面依赖：保留”CSS 必须先到才能跑后续 JS”这类串行约束。类比：车队必须按顺序过闸。

核心发现：多路复用在低丢包时省 RTT；单连接在高丢包时变成队头阻塞（HoL，Head-of-Line——前面一辆车停了，后面全堵）；计算与依赖常把协议收益压到个位数；服务器推送（server push）有潜力，但工程上难做对。

一句话记住：协议层赢的条件很窄，页面结构和浏览器计算经常把赢面抹平。

实践案例

Section titled “实践案例”

下列秒数为教学示意（按论文机制编的对照），不是论文某张表的原数字；相对结论（丢包伤 SPDY、计算吃掉收益、高 RTT 更受益）来自论文。

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

Section titled “案例 1：丢包让 SPDY 反而更慢”

最小对照思路：固定 RTT=200ms、丢包≈1%，同一组对象分别用 HTTP 1.1（最多 6 条 TCP）和 SPDY（1 条 TCP）测 PLT。

条件: RTT 200ms, loss ~1%
HTTP 1.1 (6 连接)  → 示意 PLT 较短
SPDY    (1 连接)  → 示意 PLT 更长

逐部分解释：

  1. HTTP 开 6 条连接：一条丢包重传时，另外 5 条还能继续传
  2. SPDY 把所有 stream 塞进一条 TCP：TCP 要保序，丢一个包 → 整条连接停（HoL）
  3. 所以”更先进的多路复用”在丢包网络上可能输给”笨但分散”的 6 连接策略——这也是后来 QUIC 改走 UDP 的动机之一

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

Section titled “案例 2：浏览器计算压死协议优化”
示意拆分（新闻页）:
  网络下载: HTTP 1.2s → SPDY 0.9s   （协议省 0.3s）
  解析渲染: 两边都是 1.6s           （协议帮不上）
  总 PLT  : 2.8s → 2.5s             （总收益被稀释）

逐部分解释：

  1. 先把总 PLT 拆成”网络”和”计算”两段（论文 isolating 的思路）
  2. SPDY 只缩短网络段；计算段不变
  3. 当计算 ≥ 网络时，换协议的天花板就是网络那一小段——再快也救不了慢 JS

案例 3：高 RTT 零丢包时 SPDY 才显本事

Section titled “案例 3：高 RTT 零丢包时 SPDY 才显本事”
示意: RTT 300ms, loss ≈ 0
HTTP 1.1: 多连接各付握手/慢启动成本 → 更慢
SPDY    : 单连接复用，握手只付一次   → 更快

逐部分解释：

  1. 高 RTT 时，每次新连接的握手和慢启动都很贵
  2. SPDY 单连接把多次往返摊薄，多路复用优势兑现
  3. 论文也写：低带宽、长 RTT 时约 70–80% 页面 PLT 下降；短快链路则几乎无感，最差约 20% 页面还会变慢

（服务器推送：论文显示按依赖推送有潜力，且可比 mod_spdy 少推约 80% 字节；但要服务器懂页面结构，HTTP/2 push 后来基本没人用。）

踩过的坑

Section titled “踩过的坑”
  1. 不是说 SPDY 没用：HTTPS 握手贵、移动高 RTT 时仍有价值；论文说的是”远不如宣传”，不是”完全没用”。
  2. 2014 实现偏早期：实验用 SPDY/3 + 自研客户端/服务端，不是今天的成熟 HTTP/2 栈，数字不可直接外推；但 HoL、依赖、计算这些结构问题仍在。
  3. isolating 会丢交互：真实浏览里下载与解析重叠，完全拆开测会漏掉重叠收益。
  4. benchmark 要先问 workload：白皮书漂亮数字常来自平坦页面、近零丢包、近 CDN——先问测了什么条件。

适用 vs 不适用场景

Section titled “适用 vs 不适用场景”

适用：

  • 想理解 HTTP/2 / HTTP/3 设计动机（直接源头文献）
  • 学系统性能方法学：isolating + 参数扫描（RTT 20/100/200ms，丢包 0–2% 等）
  • 批判”换协议就能加速 X%“类宣传时的对照工具
  • 量化直觉：RTT≥约 200ms 且丢包≈0 时，单连接复用更可能赢；丢包≥约 1% 时要警惕 HoL

不适用：

  • 想直接得到”今天该用 SPDY 还是 HTTP 1.1”——答案早是 HTTP/2 / 3
  • 移动端深度优化——本文主测受控桌面/仿真环境，移动只是小补充
  • 想学 QUIC 帧格式与拥塞细节——那是后续工作

历史小故事（可跳过）

Section titled “历史小故事（可跳过）”
  • 2009：Google 启动 SPDY，目标”让 web 快两倍”，早期 demo 很漂亮
  • 2012–2013：Twitter / Facebook 等部署，内部数据不一致
  • 2014：Wang 等人 NSDI 论文把”为什么不一致”讲清楚，影响 HTTP/2 讨论
  • 2015：HTTP/2（RFC 7540）发布，基本是 SPDY 改名
  • 2018–2022：QUIC → HTTP/3；HTTP/2 server push 从规范删除，印证”工程难做对”

学到什么

Section titled “学到什么”
  1. 协议优化必须看完整 stack：网络、TCP、浏览器、页面结构耦合，单层优化易被吃掉
  2. 方法学比单个百分比更值钱：isolating framework 让后续研究可复现对照
  3. 多路复用 + 单 TCP = HoL 风险：这是 SPDY → QUIC 的重要驱动力
  4. 任何”快 X%“都要先问 workload、实现、网络条件

延伸阅读

Section titled “延伸阅读”

关联

Section titled “关联”
  • akamai-2002 —— CDN 缩小 RTT，和协议层省 RTT 互补
  • saltzer-1984-e2e —— 端到端原则的活教材：换传输层不等于页面变快
  • bbr-2017 —— 拥塞控制影响丢包恢复，进而影响单连接多路复用表现
  • quic —— 用 UDP 多路复用绕开 TCP HoL，直接回应本篇指出的弱点
  • http-2 —— SPDY 的标准化后继；读完本篇再看规范更清楚取舍
  • mptcp-2012 —— 另一条”多路径/多连接”思路，和 SPDY 单连接策略对照

反向链接

Section titled “反向链接”
  • b4-2013 —— B4 — Google 用 SDN 把跨数据中心 WAN 利用率拉到 95%+