SPDY协议123

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 协议的不足

1. 单路连接请求低效

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

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

（注2：这里只能请求一个资源不敢苟同，连接从三次握手建立到四次握手释放，中间的处理并非只会请求一个资源，具体为何，以后复习下网站开发才会更清除）

2. HTTP 只允许由客户端主动发起请求

服务端只能等待客户端发送一个请求，在可以满足预加载的现状是一种桎梏。

3. HTTP 头冗余

HTTP 头在同一个会话里是反复发送的，中间的冗余信息，比如 User-Agent、Host等不需要重复发送的信息也在反复发送，浪费带宽和资源。

SPDY 协议的优点

1. 多路复用请求优化

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

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

2. 支持服务器推送技术

服务器可以主动向客户端发起通信向客户端推送数据，这种预加载可以使用户一直保持一个快速的网络。

3. SPDY 压缩了 HTTP 头

舍弃掉了不必要的头信息，经过压缩之后可以节省多余数据传输所带来的等待时间和带宽。

4. 强制使用 SSL 传输协议

Google 认为 Web未来的发展方向必定是安全的网络连接，全部请求 SSL加密后，信息传输更加安全。

SPDY 协议的意义

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

1. 普通用户：

对于使用者来说，隐藏在浏览器下面的 SPDY相比 HTTP 没有任何区别，但是我们可以感觉到 Google服务在 Chrome 下异常的快，这就是 SPDY 的功劳了。此外网站信息传输加密后不用担心信息被截取等，大大增加了安全性和保密性。

2. 前端人员：

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

3. 运维人员：

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 部署要求：

1. Apache 2.2 (≥2.2.4)
2. mod_ssl 模块开启

SPDY 部署步骤：

1. 下载 mod_spdy 模块

到下载页面下载对应系统的安装包

2. 安装 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）

4. 确定开启与否

打开 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也是明智的选择。

具体的SPDY协议解析

SPDY 连接都是持久的，连接建立后，客户端和服务端会交换帧信息(framed messages)。SPDY 有两种类型的帧：控制帧和数据帧。

SPDY 定义了多种控制帧，其中有三种用来管理流(stream)：

SYN_STREAM：打开流;

SYN_REPLY：远程确认新打开的流;

RST_STREAM：关闭流;

SYN_STREAM 和 SYN_REPLY

SYN_STREAM 控制帧用来打开流，它的格式如下：

BASH+------------------------------------+
|1| version | 1 |
+------------------------------------+
| Flags (8) | Length (24 bits) |
+------------------------------------+
|X| Stream-ID (31bits) |
+------------------------------------+
|X| Associated-To-Stream-ID (31bits) |
+------------------------------------+
| Pri|Unused | Slot | |
+-------------------+ |
| Number of Name/Value pairs (int32) | <+
+------------------------------------+ |
| Length of name (int32) | | This section is the
+------------------------------------+ | "Name/Value Header Block",
| Name (string) | | and is compressed.
+------------------------------------+ |
| Length of value (int32) | |
+------------------------------------+ |
| Value (string) | |
+------------------------------------+ |
| (repeats) | <+

简单介绍下这些字段含义：

第一行是：控制位(数据帧的控制位是 0，控制帧是 1)、SPDY 版本和类型(SYN_STREAM 的类型是 1);

flags 是帧标识，有 0x01(FLAG_FIN)和 0x02(FLAG_UNIDIRECTIONAL)两种。FIN 表示该帧是当前流的最后一帧，发送者随后进入半关闭状态;UNIDIRECTIONAL 作用是让接收者进入半关闭状态;

Length(长度)，表示这一帧剩余部分字节数。对于 SYN_STREAM 来说，它是固定 10 字节加上压缩后键 / 值对的长度;

Stream-ID 是流的标识符，会被用于这个流里所有的帧。客户端初始化的流 id 必须是奇数，服务端创建的流是偶数，流 id 在两端必须连续;

Associated-To-Stream-ID，关联的流。如果没有关联的流，它应该为 0;

Pri(Priority)，流优先级，0 表示优先级最高，7 表示最低。发送者和接收者应该尽可能的按照这个优先级去处理流;

Name/Value Header Block(键 / 值头部块)，SYN_STREAM 携带的一组键 / 值对，这个块一定会使用 zlib 压缩;

SYN_REPLY 控制帧用来确认新打开的流，它的格式是：

BASH+------------------------------------+
|1| version | 2 |
+------------------------------------+
| Flags (8) | Length (24 bits) |
+------------------------------------+
|X| Stream-ID (31bits) |
+------------------------------------+
| Number of Name/Value pairs (int32) | <+
+------------------------------------+ |
| Length of name (int32) | | This section is the
+------------------------------------+ | "Name/Value Header Block",
| Name (string) | | and is compressed.
+------------------------------------+ |
| Length of value (int32) | |
+------------------------------------+ |
| Value (string) | |
+------------------------------------+ |
| (repeats) | <+

这些字段与 SYN_STREAM 含义几乎一样：

第一行是也是控制位、SPDY 版本和类型(SYN_REPLY 的类型是 2);

Length(长度)，表示这一帧剩余部分字节数。对于 SYN_REPLY 来说，它是固定 4 字节加上压缩后键 / 值对的长度;

RST_STREAM 和其他控制帧，以及数据帧与本文关系不大，这里略过。

SPDY 上的 HTTP 请求

客户端通过 SYN_STREAM 帧来初始化请求。如果请求不包含正文部分(HTTP Body)，那么必须设置 FLAG_FIN 标志，表示客户端不会在这个流上发送其他帧了;否则，客户端会在 SYN_STREAM 之后发送一系列数据帧，并给最后一个数据帧设置 FLAG_FIN。

SYN_STREAM 中的 Name/Value Header Block，几乎与现在的 HTTP 头部相同，但也有改变：

状态行必须像其他 HTTP 头部一样展开为键 / 值对。我们知道，HTTP 协议请求中，第一行有这些信息：

<method> <request-URL> <version>

在 SPDY 中，这些信息必须放在键 / 值对中：

:method，这个请求对应的 HTTP method(如：GET、POST、HEAD 等);

:path，"/" 开头的 url 路径，参考 RFC3986;

:version，HTTP 版本号(如 HTTP/1.1);

另外，每个请求中，还需要补充以下两个键 / 值对：

:host，请求的主机和端口，参考 RFC1738，与当前 HTTP 的 HOST 头相同;

:scheme，URL 的协议部分(如 https);

所有头部名都需要小写。我们已经看到，SPDY 新增的键 / 值对的 key 都是小写的，其他已有的 HTTP 头部的 key 也都需要转成小写。

不能发送某些头部。Connection、Host、Keep-Alive、Proxy-Connection、Transfer-Encoding 这些头都不能发送。这些头多半与连接控制和传输方式有关，SPDY 已经不需要他们，HOST 则被 :host 代替。

客户端必须支持 gzip 压缩。也就是说，无论客户端是否发送 accept-encoding，服务端始终可以发送 gzip 或者 deflate 编码后的内容。(扩展阅读：Nginx 在 SPDY 协议下不发送 Vary: Accept-Encoding 响应头)

如果服务端收到数据帧长度和不等于 content-length 的请求，必须返回 400(Bad Request)。同时，对于 POST 请求，也需要包含 content-length 头部。

另外，客户端可以通过 SYN_STREAM 帧中的 Pri 字段，给不同资源指定不同的优先级。后续我会专门写文章介绍 Chrome 浏览器的优先级策略。

如果 SYN_STREAM 帧没有包含 :method、:host、:path、:scheme 以及 :version，服务端必须返回 400(Bad Request)。

SPDY 上的 HTTP 响应

服务端用 SYN_REPLY 帧响应客户端的请求。同样，FLAG_FIN 用来标识该响应是否包含正文。与 SPDY 请求类似，SPDY 响应也有一些改变：

状态行必须像其他 HTTP 头部一样展开为键 / 值对。我们知道，HTTP 协议响应中，第一行有这些信息：

<version> <status> <respon-phrase>

在 SPDY 中，他们也必须放在键/值对中：

:status，HTTP 响应状态码(如：200 或 200 OK);

:version，响应的 HTTP 版本号(如 HTTP/1.1);

所有头部名都需要小写。与前面请求头规则一致。

不能发送某些头部。Connection、Keep-Alive、Proxy-Connection、Transfer-Encoding 这些头都不能发送。与请求头类似。

响应头可以包含 content-length。如果 content-length 长度不等于响应数据帧长度之和，客户端必须忽略这个头。

如果服务端的 SYN_REPLY 中不包含 :status 或 :version头，客户端必须回复 RST_STREAM 帧。

SPDY 请求 / 响应实例

通过 Chrome 开发工具的网络面板，可以看到请求 / 响应头的相关信息。通过 chrome://net-internals/#events 界面，我们可以看到更多信息。我这里摘录了访问我博客的一段日志，并加上了注释，大家可以对照前面的介绍看看。

BASHt=2111847 [st = 1] SPDY_SESSION_SYN_STREAM 【客户端发送请求】
--> fin = true 【fin 标记表示这是当前流最后一帧】
--> :host: www.imququ.com 【请求头】
:method: GET
:path: /post/devtool-in-chrome32.html
:scheme: https
:version: HTTP/1.1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
accept-encoding: gzip,deflate,sdch
accept-language: zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2
cache-control: max-age=0
cookie: [172 bytes were stripped]
dnt: 1
referer: https://imququ.com/
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.60 Safari/537.36
--> spdy_priority = 0 【优先级，0 最高】
--> stream_id = 1 【流id，客户端创建的流 id 是奇数】
--> unidirectional = false
t=2111980 [st = 134] SPDY_SESSION_SYN_REPLY 【服务端返回响应】
--> fin = false 【fin 为false，表示后续还有数据帧】
--> :status: 200 OK 【响应头】
:version: HTTP/1.1
content-encoding: gzip
content-type: text/html; charset=utf8
date: Sat, 15 Mar 2014 06:08:47 GMT
server: nginx
strict-transport-security: max-age=31536000
x-cache: HIT from cache.ququ
x-powered-by: thinkjs-0.4.1
--> stream_id = 1
t=2111981 [st = 135] SPDY_SESSION_RECV_SETTINGS 【各种控制帧】
--> clear_persisted = true
--> host = "www.imququ.com:443"
t=2111981 [st = 135] SPDY_SESSION_RECV_SETTING
--> flags = 0
--> id = 4
--> value = 100
t=2111981 [st = 135] SPDY_SESSION_UPDATE_STREAMS_SEND_WINDOW_SIZE
--> delta_window_size = 2147418111
...
t=2112105 [st = 259] SPDY_SESSION_RECV_DATA 【数据帧】
--> fin = true 【当前流最后一帧】
--> size = 0
--> stream_id = 1
t=2112208 [st = 362] SPDY_SESSION_SYN_STREAM 【新的请求】
--> fin = true
--> :host: www.imququ.com
:method: GET
:path: /static/css/theme/the-bizness_datauri_178bc.css
:scheme: https
:version: HTTP/1.1
accept: text/css,*/*;q=0.1
accept-encoding: gzip,deflate,sdch
accept-language: zh-CN,zh;q=0.8,en-US;q=0.6,en;q=0.4,ja;q=0.2,de;q=0.2,zh-TW;q=0.2
cache-control: max-age=0
cookie: [172 bytes were stripped]
dnt: 1
if-modified-since: Mon, 10 Feb 2014 15:08:22 GMT
pragma: no-cache
referer: https://imququ.com/post/devtool-in-chrome32.html
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.60 Safari/537.36
--> spdy_priority = 1 【优先级为1】
--> stream_id = 3 【客户端创建的流 id 为奇数，且连续】
--> unidirectional = false
...

如何部署 SPDY 3.1

Chrome 很快就会移除对 SPDY 2 的支持，Firefox 28 也不支持 SPDY 2 了。如果你还在使用 SPDY 2，是时候升级了。

2014 年 2 月 4 日，Nginx 发布了 1.5.10 版，开始提供对 SPDY 3.1 的支持。下载 nginx 最新的 1.5.11 源码包后，再去 openssl 官网下一个最新的 openssl 库，就可以编译了。configure 时需要启用 spdy、ssl 模块，另外需要指定前面下载到的 openssl 库，这样才能确保使用最新的 ssl：

./configure --with-openssl=/home/jerry/tmp/openssl-1.0.1e/ --with-http_spdy_module --with-http_ssl_module

有了支持 SPDY 3.1 的 nginx，接下来在站点配置里启用就可以了，由于 SPDY 协议必须使用 HTTPS，所以端口默认是 443，证书什么的也需要提前配好。

BASHserver {
server_name www.imququ.com;
server_tokens off;
listen 443 ssl spdy;
ssl_certificate /home/jerry/ssl/server.crt;
ssl_certificate_key /home/jerry/ssl/server.key;
spdy_headers_comp 6;
add_header Strict-Transport-Security max-age=31536000;
... ...
}

一切 OK 后，打开 Chrome 的这个页面：chrome://net-internals/#spdy，可以查看 SPDY 的使用情况。

From：

http://network.51cto.com/art/201509/492693.htm

http://blog.csdn.net/oyangyujun/article/details/50039745

注：因为遇到该协议，所以接触下有个了解，方便之后出现时的解析

posted @ 2016-11-15 21:50 cloudren2020 阅读(358) 评论(0) 收藏举报

刷新页面返回顶部

苟日新,又日新,日日新

SPDY协议123

公告