SPDY 是什么？如何部署 SPDY？HTTPS、SPDY和HTTP/2的性能比较

作者：发布时间：2020-02-27 来源:佚名点击数：

当老迈的 HTTP 协议逐渐不能满足人们需求的时候，Google 的 SPDY 协议出现在面前，那么这个长期以来一直被认为是 HTTP 2.0 唯一可行选择的 SPDY 是什么呢？当下我们如何能部署上 SPDY 呢？

左边是普通 HTTPS 加载，右边是 SPDY 加载。是不是很神奇？

SPDY 是什么？

SPDY 是 Google 开发的基于传输控制协议 (TCP) 的应用层协议，开发组正在推动 SPDY 成为正式标准（现为互联网草案）。SPDY 协议旨在通过压缩、多路复用和优先级来缩短网页的加载时间和提高安全性。（SPDY 是 Speedy 的昵音，意思是更快）

SPDY 与 HTTP 的关系

SPDY 协议只是在性能上对 HTTP 做了很大的优化，其核心思想是尽量减少连接个数，而对于 HTTP 的语义并没有做太大的修改。具体来说是，SPDY 使用了 HTTP 的方法和页眉，但是删除了一些头并重写了 HTTP 中管理连接和数据转移格式的部分，所以基本上是兼容 HTTP 的。

Google 在 SPDY 白皮书里表示要向协议栈下面渗透并替换掉传输层协议（TCP），但是因为这样无论是部署起来还是实现起来暂时相当困难，因此 Google 准备先对应用层协议 HTTP 进行改进，先在 SSL 之上增加一个会话层来实现 SPDY 协议，而 HTTP 的 GET 和 POST 消息格式保持不变，即现有的所有服务端应用均不用做任何修改。

因此在目前，SPDY 的目的是为了加强 HTTP，是对 HTTP 一个更好的实现和支持。至于未来 SPDY 得到广泛应用后会不会演一出狸猫换太子，替换掉 HTTP 并彻底颠覆整个 Internet 就是 Google 的事情了。

为什么要重新建立一个 SPDY ？

距离万维网之父蒂姆·伯纳斯-李发明并推动 HTTP 成为如今互联网最流行的协议已经过去十几年了（现用 HTTP 1.1 规范也停滞了 13 年了），随着现在 WEB 技术的飞速发展尤其是 HTML5 的不断演进，包括 WebSockets 协议的出现以及当前网络环境的改变、传输内容的变化，当初的 HTTP 规范已经逐渐无法满足人们的需要了，HTTP 需要进一步发展，因此 HTTPbis 工作组已经被组建并被授权考虑 HTTP 2.0 ，希望能解决掉目前 HTTP 所带来的诸多限制。而 SPDY 正是 Google 在 HTTP 即将从 1.1 跨越到 2.0 之际推出的试图成为下一代互联网通信的协议，长期以来一直被认为是 HTTP 2.0 唯一可行选择。

HTTP 协议的不足

单路连接请求低效
HTTP 协议的最大弊端就是每个 TCP 连接只能对应一个 HTTP 请求，即每个 HTTP 连接只请求一个资源，浏览器只能通过建立多个连接来解决。此外在 HTTP 中对请求是严格的先入先出（FIFO）进行的，如果中间某个请求处理时间较长会阻塞后面的请求。

（注：虽然 HTTP pipelining 对连接请求做了改善，但复杂度增加很大，并未普及）

HTTP 只允许由客户端主动发起请求
服务端只能等待客户端发送一个请求，在可以满足预加载的现状是一种桎梏。
HTTP 头冗余
HTTP 头在同一个会话里是反复发送的，中间的冗余信息，比如 User-Agent、Host 等不需要重复发送的信息也在反复发送，浪费带宽和资源。

SPDY 协议的优点

多路复用请求优化
SPDY 规定在一个 SPDY 连接内可以有无限个并行请求，即允许多个并发 HTTP 请求共用一个 TCP会话。这样 SPDY 通过复用在单个 TCP 连接上的多次请求，而非为每个请求单独开放连接，这样只需建立一个 TCP 连接就可以传送网页上所有资源，不仅可以减少消息交互往返的时间还可以避免创建新连接造成的延迟，使得 TCP 的效率更高。

此外，SPDY 的多路复用可以设置优先级，而不像传统 HTTP 那样严格按照先入先出一个一个处理请求，它会选择性的先传输 CSS 这样更重要的资源，然后再传输网站图标之类不太重要的资源，可以避免让非关键资源占用网络通道的问题，提升 TCP 的性能。

支持服务器推送技术
服务器可以主动向客户端发起通信向客户端推送数据，这种预加载可以使用户一直保持一个快速的网络。
SPDY 压缩了 HTTP 头
舍弃掉了不必要的头信息，经过压缩之后可以节省多余数据传输所带来的等待时间和带宽。
强制使用 SSL 传输协议
Google 认为 Web 未来的发展方向必定是安全的网络连接，全部请求 SSL 加密后，信息传输更加安全。

SPDY 协议的意义
按照 Google 的说法，SPDY 被创造出来的唯一目的就是让 Web 更快（strive to make the whole web fast），其名字 SPDY（Speedy）也似乎在暗示着这一点。那么 SPDY 的意义又在哪里呢？

普通用户：
对于使用者来说，隐藏在浏览器下面的 SPDY 相比 HTTP 没有任何区别，但是我们可以感觉到 Google 服务在 Chrome 下异常的快，这就是 SPDY 的功劳了。此外网站信息传输加密后不用担心信息被截取等，大大增加了安全性和保密性。
前端人员：
对于前端工程师们来说，提升页面效率是一件很重要的事情，目前大多采用像 CSS Sprites 等方法来优化网站，对于因为页面加载时每张图片、icon 都请求一个连接甚至采用在不同页面引用不同图片来降低一个页面内图片的请求数量。而现在有了 SPDY 的请求优化可以将请求顺序进行重排，这样可以在很大程度上缓解页面加载时图片请求带来的影响。例如像极客公园的报名页面，如果报名用户过多，例如极客公园2012年创新大会或极客公园第 27 期长城会，可以很明显的感觉出头像的请求会拖累整体页面加载变慢甚至变卡，相信对于这点，经常上淘宝或刷微博的会深有体会，一旦网速稍微慢点就会出现页面加载异常，还有像苹果 App Store（除去服务器因为地区的延迟），豌豆荚这类应用分发平台上应用图标刷新缓慢等，如下面这个视频所示。

运维人员：
SPDY 在降低连接数目的同时，还使得服务器上每个客户端占用的资源也减少，从而可以释放出更多内存和 CPU 。此外 SPDY 综合起来可以将浏览速度提升一倍，页面加载延迟方面的改进达 64% 。

众家支持的 SPDY 协议
如果你在使用 Chrome 浏览器，同时使用像 Gmail 等 Google 的网络服务的话，其实你已经不再是通过 HTTP 访问这些服务了。在浏览器打开 chrome://net-internals/#spdy 就会发现你已经在使用 SPDY 协议了。（除了包括 Google 自家的 Gmail、Google Plus 等 Google 系服务外，其他公共站点例如 Twitter 和 Webtide 也已经支持该协议。在国内，基于 WebKit 的豌豆荚 2.0 也曾表示将引进Chrome的SPDY技术来进一步提升速度。

就像上图所示的那样，SPDY 的实现需要浏览器客户端和 Web 服务器同时支持。在客户端浏览器这快 Google自家的 Chrome 和Chromium 全系列不用说，都已经支持SPDY； Mozilla 家的 Firefox 自 Firefox 13 也默认开启对 SPDY 的支持。而亚马逊家的 Silk 利用 SPDY 的深度其实不比 Google 自家的 Chrome 和 Firefox 差。

在Web 服务器方面包括最流行和最广泛的 Apache 在内，Netty、Jeety、Varnish、Erlang 和 Hightide 应用服务器以及面向 node.js 的服务器也都已经宣布支持 SPDY。（Nginx 也表示将支持 SPDY）

如何部署 SPDY？

近日 Google 正式发布了适用于最流行 Web 服务器 Apache 的插件 mod_spdy，将其下载安装后你的 Apache 服务器就能使用 SPDY 协议与兼容 SPDY 协议的浏览器如 Chrome、FireFox 等进行通信。像之前所说的那样，SPDY 是运行在 HTTPS 上，非 HTTPS 流量并不会受到 mod_spdy 影响。

SPDY 部署要求：

Apache 2.2 (≥2.2.4)
mod_ssl 模块开启

SPDY 部署步骤：

下载 mod_spdy 模块
到下载页面下载对应系统的安装包
安装 mod_spdy 模块
在系统终端运行下面命令行
```
dpkg -i mod-spdy-*.deb
apt-get -f install

-系统为 Debian/Ubuntu

------------------------------------------------------------

yum install at (if you do not already have ‘at’ installed)
rpm -U mod-spdy-*.rpm

-系统为 CentOS/Fedora

3. 重启服务器（Apache）

sudo /etc/init.d/apache2 restart （Debian/Ubuntu）
```

确定开启与否
打开 Chrome 浏览器，输入并前往 chrome://net-internals/#spdy 页面，查看主机名称是否出现在标识栏中。如果出现说明已经部署完毕，如果没有出现去服务器错误日志（error.log）里查询。

未来的web基础？
在最新的协议文档里 Google 重新将 SPDY 分为了两层，其中一层被描述为 HTTP-like，大有取代 HTTP 的意图（Google 最近的一篇文章已经直呼 SPDY 为“a replacement for HTTP”）。同时 HTTP 2.0 标准制定工作组（HTTPbis）也表示，SPDY 很有希望接替当前的 HTTP 传输实现。

考虑到 Chrome 和安卓的份额以及标准的推动，相信 SPDY 会有一个好前景。因此选择此刻支持 SPDY 也是明智的选择。

VIA http://www.geekpark.net/read/view/158198

HTTPS、SPDY和HTTP/2的性能比较
http://www.infoq.com/cn/news/2015/02/https-spdy-http2-comparison/

https://segmentfault.com/a/1190000002765886

SPDY对当前的HTTP协议有4个改进：

多路复用请求；
对请求划分优先级；
压缩HTTP头；
服务器推送流（即Server Push技术）；
SPDY试图保留HTTP的现有语义，所以cookies、ETags等特性都是可用的。[3]

SPDY令人赞叹。这是十几年来对HTTP的第一次真正的升级，它不仅解决了高延迟移动网络的性能问题，还增强了Web的安全性。SPDY与HTTP有许多区别，但它最大的价值是它能通过复用仅仅一条（或几条)TCP连接，在客户端与服务器间发送几十个请求或回应。

之前的评测吹嘘说SPDY极其强力，从页面加载速度变两倍到相比纯HTTP用SPDY和HTTPS能让无线网站加载速度快23%。不过在实际生活中的网站上我没发现有这么大的进步。老实说，我的测试表明SPDY仅比HTTPS快一点点，同时还比HTTP要慢。

为什么？简单的说，SPDY改进了HTTP，但对大多数网站来说，HTTP不是瓶颈。

SPDY（读作“SPeeDY”）是Google开发的基于TCP的传输层协议，用以最小化网络延迟，提升网络速度，优化用户的网络使用体验。SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩。谷歌表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。[1-2]

定位
将页面加载时间减少50%。
最大限度地减少部署的复杂性。SPDY使用TCP作为传输层，因此无需改变现有的网络设施。
避免网站开发者改动内容。支持SPDY唯一需要变化的是客户端代理和Web服务器应用程序。
具体技术目标
单个TCP连接支持并发的HTTP请求。
压缩报头和去掉不必要的头部来减少当前HTTP使用的带宽。
定义一个容易实现，在服务器端高效率的协议。通过减少边缘情况、定义易解析的消息格式来减少HTTP的复杂性。
强制使用SSL，让SSL协议在现存的网络设施下有更好的安全性和兼容性。
允许服务器在需要时发起对客户端的连接并推送数据。[1-2]
https://baike.baidu.com/item/SPDY/3399551?fr=aladdin

HTTP/2 新特性浅析：

HTTP/2 源自 SPDY/2
SPDY 系列协议由谷歌开发，于 2009 年公开。它的设计目标是降低 50% 的页面加载时间。当下很多著名的互联网公司，例如百度、淘宝、UPYUN 都在自己的网站或 APP 中采用了 SPDY 系列协议（当前最新版本是 SPDY/3.1），因为它对性能的提升是显而易见的。主流的浏览器（谷歌、火狐、Opera）也都早已经支持 SPDY，它已经成为了工业标准，HTTP Working-Group 最终决定以 SPDY/2 为基础，开发 HTTP/2。

但是，HTTP/2 跟 SPDY 仍有不同的地方，主要是以下两点：

HTTP/2 支持明文 HTTP 传输，而 SPDY 强制使用 HTTPS

HTTP/2 消息头的压缩算法采用 HPACK，而非 SPDY 采用的 DELEFT

HTTP/2 的优势
相比 HTTP/1.x，HTTP/2 在底层传输做了很大的改动和优化：

HTTP/2 采用二进制格式传输数据，而非 HTTP/1.x 的文本格式。二进制格式在协议的解析和优化扩展上带来更多的优势和可能。

HTTP/2 对消息头采用 HPACK 进行压缩传输，能够节省消息头占用的网络的流量。而 HTTP/1.x 每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。头压缩能够很好的解决该问题。

多路复用，直白的说就是所有的请求都是通过一个 TCP 连接并发完成。HTTP/1.x 虽然通过 pipeline 也能并发请求，但是多个请求之间的响应会被阻塞的，所以 pipeline 至今也没有被普及应用，而 HTTP/2 做到了真正的并发请求。同时，流还支持优先级和流量控制。

Server Push：服务端能够更快的把资源推送给客户端。例如服务端可以主动把 JS 和 CSS 文件推送给客户端，而不需要客户端解析 HTML 再发送这些请求。当客户端需要的时候，它已经在客户端了。

HTTP/2 主要是 HTTP/1.x 在底层传输机制上的完全重构，HTTP/2 是基本兼容 HTTP/1.x 的语义的（详细兼容性说明请戳这里）。Content-Type 仍然是 Content-Type，只不过它不再是文本传输了。那么 HTTP/2 的这些新特性又是如何实现的呢？

HTTP/2 的基石－ Frame

Frame 是 HTTP/2 二进制格式的基础，基本可以把它理解为它 TCP 里面的数据包一样。HTTP/2 之所以能够有如此多的新特性，正是因为底层数据格式的改变。 Frame 的基本格式如下（图中的数字表示所占位数，内容摘自 http2-draft-17）:

+———————————————————————-+
| Length (24) |
+———————-+———————-+———————-+
| Type (8) | Flags (8) |
+-+——————-+———————-+—————————-+
|R| Stream Identifier (31) |
+=+=================================================+
| Frame Payload (0…) …
+—————————————————————————-+
Length: 表示 Frame Payload 部分的长度，另外 Frame Header 的长度是固定的 9 字节（Length + Type + Flags + R + Stream Identifier = 72 bit）。

Type: 区分这个 Frame Payload 存储的数据是属于 HTTP Header 还是 HTTP Body；另外 HTTP/2 新定义了一些其他的 Frame Type，例如，这个字段为 0 时，表示 DATA 类型（即 HTTP/1.x 里的 Body 部分数据）

Flags: 共 8 位，每位都起标记作用。每种不同的 Frame Type 都有不同的 Frame Flags。例如发送最后一个 DATA 类型的 Frame 时，就会将 Flags 最后一位设置 1（flags &= 0x01），表示 END_STREAM，说明这个 Frame 是流的最后一个数据包。

R: 保留位。

Stream Identifier: 流 ID，当客户端和服务端建立 TCP 链接时，就会先发送一个 Stream ID = 0 的流，用来做些初始化工作。之后客户端和服务端从 1 开始发送请求/响应。

Frame 由 Frame Header 和 Frame Payload 两部分组成。不论是原来的 HTTP Header 还是 HTTP Body，在 HTTP/2 中，都将这些数据存储到 Frame Payload，组成一个个 Frame，再发送响应/请求。通过 Frame Header 中的 Type 区分这个 Frame 的类型。由此可见语义并没有太大变化，而是数据的格式变成二进制的 Frame。

为 HTTP/2 头压缩专门设计的 HPACK

如果我们约定将常用的请求比如 GET /index.html 用一个 1 来表示，POST /index.html 用 2 来表示。那么是不是可以节省很多字节？

为 HTTP/2 的专门量身打造的 HPACK 便是类似这样的思路延伸。它使用一份索引表来定义常用的 HTTP Header。把常用的 HTTP Header 存放在表里。请求的时候便只需要发送在表里的索引位置即可。例如 :method=GET 使用索引值 2 表示，:path=/index.html 使用索引值 5 表示（完整的列表参考：HPACK Static Table）。只要给服务端发送一个 Frame，该 Frame 的 Payload 部分存储 0x8285，Frame 的 Type 设置为 Header 类型，便可表示这个 Frame 属于 HTTP Header，请求的内容是：

GET /index.html
为什么是 0x8285，而不是 0x0205？这是因为高位设置为 1 表示这个字节是一个完全索引值（key 和 value 都在索引中）。类似的，通过高位的标志位可以区分出这个字节是属于一个完全索引值，还是仅索引了 key，还是 key 和 value 都没有索引。因为索引表的大小的是有限的，它仅保存了一些常用的 HTTP Header，同时每次请求还可以在表的末尾动态追加新的 HTTP Header 缓存。动态部分称之为 Dynamic Table。Static Table 和 Dynamic Table 在一起组合成了索引表：

<————— Index Address Space —————>
<— Static Table —> <— Dynamic Table —>
+—-+—————-+—-+ +—-+—————-+—-+
| 1 | … | s | |s+1| … |s+k|
+—-+—————-+—-+ +—-+—————-+—-+
^ |
| V
Insertion Point Dropping Point
HPACK 不仅仅通过索引键值对来降低数据量，同时还会将字符串进行霍夫曼编码来压缩字符串大小。

以常用的 User-Agent 为例，它在静态表中的索引值是 58，它的值是不存在表中的，因为它的值是多变的。第一次请求的时候它的 key 用 58 表示，表示这是一个 User-Agent ，它的值部分会进行霍夫曼编码（如果编码后的字符串变更长了，则不采用霍夫曼编码）。服务端收到请求后，会将这个 User-Agent 添加到 Dynamic Table 缓存起来，分配一个新的索引值。客户端下一次请求时，假设上次请求User-Agent的在表中的索引位置是 62，此时只需要发送 0xBE（同样的，高位置 1），便可以代表： User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/33.0.1750.146 Safari/537.36。其过程如下图所示:

图片引用自这里

最终，相同的 Header 只需要发送索引值，新的 Header 会重新加入 Dynamic Table。

Multipexing 多路复用
每个 Frame Header 都有一个 Stream ID 就是被用于实现该特性。每次请求/响应使用不同的 Stream ID。就像同一个 TCP 链接上的数据包通过 IP:PORT来区分出数据包去往哪里一样。通过 Stream ID 标识，所有的请求和响应都可以欢快的同时跑在一条 TCP 链接上了。下图是 http 和 spdy(http2 的模型和 spdy 是类似的) 的并发模型对比：

当流并发时，就会涉及到流的优先级和依赖。优先级高的流会被优先发送。图片请求的优先级要低于 CSS 和 SCRIPT，这个设计可以确保重要的东西可以被优先加载完。

Server Push
当服务端需要主动推送某个资源时，便会发送一个 Frame Type 为 PUSH_PROMISE 的 Frame，里面带了 PUSH 需要新建的 Stream ID。意思是告诉客户端：接下来我要用这个 ID 向你发送东西，客户端准备好接着。客户端解析 Frame 时，发现它是一个 PUSH_PROMISE 类型，便会准备接收服务端要推送的流。