spdy如何旧版加速

本文目录导读：

1. 多路复用
2. 请求优先级
3. HTTP头部压缩
4. 服务器推送
5. 强制使用HTTPS（更安全的加速）
6. 为什么你现在几乎不用专门配置SPDY？

SPDY（发音为“Speedy”）是谷歌在2009年开发的一种应用层协议，旨在加速网页加载，它解决的核心问题是HTTP/1.1的队头阻塞和冗余连接。

虽然SPDY已经被HTTP/2（2015年标准化）所取代，但它在当时确实是一种“旧版但有效的加速方案”，下面是SPDY实现加速的核心技术原理：

多路复用

这是SPDY最核心的加速手段。

• 传统HTTP/1.1问题： 浏览器对一个域名通常只能建立6个左右的TCP连接，如果一个页面有上百个资源（图片、JS、CSS），这些资源需要排队等待，即使后面的资源已经准备好，前面的资源没传输完，它也得等着（队头阻塞）。
• SPDY的解决： 在一个单一的TCP连接上，同时并行发送多个请求和响应，数据被拆分成更小的帧（Frame），可以交错传输，发送图片A的第1帧、接着发CSS文件的第1帧、再发图片A的第2帧，服务器和客户端可以重新组装这些帧。这极大地减少了连接建立的开销和排队等待时间。

请求优先级

• 问题： 在HTTP/1.1中，所有资源请求在浏览器看来几乎是无序的，浏览器虽然能通过<link>标签或JS控制，但无法精细地告诉服务器哪些资源最重要。
• SPDY的解决： 客户端可以给每个请求分配一个优先级（0-7级），服务器会优先发送高优先级的资源（HTML文件、关键的CSS/JS），这避免了低优先级的图片阻塞了首屏渲染的关键CSS，让用户能更快看到页面内容。

HTTP头部压缩

• 问题： 即使在HTTP/1.1中，请求头的体积可能很大（例如Cookie、User-Agent等），而且每次请求几乎都会重复发送完全相同的头部（如User-Agent: Mozilla/5.0... 这个字符串可能几百字节）。
• SPDY的解决： 使用专门的算法（如后来被HTTP/2采纳的HPACK）对HTTP头部进行增量压缩，只有第一次发送完整的头部，后续相同的字段（如Cookie、Host）只用索引号表示。这极大地减少了上行和下行的数据传输量，尤其是在网络条件差（高延迟）的情况下效果显著。

服务器推送

• 原理： 服务器可以主动向客户端推送资源，而不用等待客户端明确请求。
• 场景： 当客户端请求一个HTML页面时，服务器可以提前推断出浏览器接下来肯定会请求该页面的CSS和JS文件，于是服务器直接在同一个连接中把CSS和JS“推送”给客户端浏览器，而不是等浏览器解析HTML后才发现需要这两个文件，再重新发起请求。
• 效果： 省掉了一次完整的HTTP请求/响应往返时间，对于有高延迟的网络（如移动网络）非常有效。

强制使用HTTPS（更安全的加速）

• SPDY强制要求使用TLS（即HTTPS），虽然加密本身计算量稍大，但：
  • 现代硬件可以高效处理TLS。
  • 它解决了HTTP明文传输时可能被中间人篡改或劫持的问题（如运营商插广告）。
  • 更重要的是：因为SPDY在单一连接上复用，TLS握手只需要做一次（而HTTP/1.1需要对每个TCP连接做一次），整体开销反而降低了。

为什么你现在几乎不用专门配置SPDY？

• 被HTTP/2取代： HTTP/2标准基于SPDY的经验开发，修复了SPDY的一些问题（如流控、头部压缩算法等），并成为官方标准，几乎所有现代浏览器和服务器都支持HTTP/2。
• 兼容性： 如果你的服务器配置了SPDY，大概率也同时支持HTTP/2，现代浏览器浏览器会自动选择HTTP/2，而忽略SPDY。

对于旧版系统（比如Windows XP的老浏览器、非常老的服务器），如何利用这个思路加速？

如果你确实在维护一个只能支持SPDY（而不支持HTTP/2）的旧环境，你可以：

1. 服务器端配置： 在Nginx（openresty）、Apache或Caddy上启用SPDY模块（spdy 指令），但强烈建议直接升级到支持HTTP/2和HTTP/3的版本。
2. 使用现代CDN： 如Cloudflare、CloudFront等，它们自动处理协议协商，即使你的源站是老的HTTP/1.1，CDN会用HTTP/2/HTTPS与客户端通信，从而享受到多路复用和头部压缩的好处。

总结一句话： SPDY通过多路复用（一个连接干多个活）和头部压缩（减少垃圾数据）来加速，这个思想被HTTP/2继承并发展，现在直接用HTTP/2或HTTP/3（基于QUIC的HTTP/3）即可获得更好的加速效果。

标签： 旧版加速