SPDY、HTTP/2、QUIC协议
1 SPDY协议
1.1 概述SPDY为speedy（单词原意：快速的）的缩写，读音也就是speedy。
SPDY协议已发布过4个草案，分别为版本1、2、3、3.1。目前版本4已在试验阶段，但未发布，Chromium里已有一些针对版本4的代码。
SPDY对比HTTP的优势：
1. 复用连接，可在一个TCP连接上传送多个资源。应对了TCP慢启动的特性。
2. 请求分优先级，重要的资源优先传送。
3. HTTP头部数据也被压缩，省流量。
4. 服务器端可主动连接客户端来推送资源（Server Push）。
缺点：
1. 单连接会因TCP线头阻塞（head-of-line blocking）的特性而传输速度受限。加上存在可能丢包的情况，其负面影响已超过压缩头部和优先级控制带来的好处。
由于这些缺点，SPDY在小网站（资源文件数量较少）的效果不明显，有可能比多并发连接更慢。（由此催生了QUIC）
1.2 协议层次基于安全的考虑，SPDY规定建立在TLS之上，即URL scheme为https。发明者表示TLS的握手是在一定程度上占用了时间和流量，但网络安全是必然的趋势，所以不计较这一成本。协议层次如下：
SPDY ← HTTP
↓
TLS ← NPN
↓
TCP
对比普通的HTTPS协议层次：
HTTP
↓
SSL/TLS
↓
TCP
SPDY协议虽然在TLS基础上代替了HTTP协议，但SPDY的内容又包含了HTTP协议的内容，用设计模式来理解就是应用装饰者模式扩展了HTTP。
另外为了在TLS之上不使用标准规定的HTTP协议，为TLS扩展出NPN（Next Protocol Negotiation，协议协商）。
1.3 NPNNPN简单来说就是在TLS的握手阶段增加一些字段来表明服务器端和客户端希望在TLS基础上使用HTTP之外的（SPDY）协议。NPN同样是Google提出的，为SPDY铺路。
Client端程序的实现是：握手前对OpenSSL（或封装它的库）设置可接受哪些协议，握手后获取选择了哪个协议，然后按选择的协议进行通信。
1.4 数据格式本节不会完整介绍SPDY，只讲重点，并假定读者熟悉HTTP协议而不解释SPDY中类似HTTP的概念。
SPDY把一次单向传输（服务器到客户端或客户端到服务器）的内容称作帧（frame），按协议组装帧内容称为装帧（framing）。帧内容分为头部（header）和载荷（payload），类似于HTTP的头部（header）和实体（entity），但有以下区别：
1. SPDY的头部都是8个字节，根据其中一些位的数值不同来表示不同的信息，并把HTTP的头部放到SPDY的载荷里。
2. HTTP的实体（除POST信息外）是文件数据（data），SPDY的载荷除了可以是文件数据还可以是其它信息。
根据载荷的内容，帧分为控制帧和数据帧。
控制帧的数据格式：
+----------------------------------+
|C| Version(15bits) | Type(16bits) |
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Data |
+----------------------------------+
数据帧的数据格式：
+----------------------------------+
|C| Stream-ID (31bits) |
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Data |
+----------------------------------+
各数据位的意义：
* C是第一个bit，值为0或1分别表示数据帧和控制帧。
* Version为SPDY协议版本号，目前为3。
* Type用作区分控制帧的类型。
* Flags标记一些操作指示，不同的Type有不同的Flag。常见的是FLAG_FIN表示一个Stream结束。
* Length表示Data的数据长度。
* Data也就是payload。数据帧的Data就是一个文件（HTML文档、图片、脚本等），控制帧的Data根据Type不同而有不同。
* Stream-ID记录流水号。
SPDY把一次HTTP Request/Response来回称作流（Stream），因为复用TCP连接，所以一个SPDY连接里会有多个流。为了区分不同的流，用Stream-ID来标记流水号（注：因为可以reload，所以不能以URL来确定一个流）。Stream-ID还存在于4种控制帧（SYN_STREAM、SYN_REPLY、RST_STREAM、HEADERS）的payload里。
控制帧的8种类型及作用：
1. SYN_STREAM：创建流，在payload里携带请求（Request）。
2. SYN_REPLY：回复创建流，在payload里携带HTTP头部。注意：SPDY把HTTP response拆开，response header放在控制帧SYN_REPLY的payload里并经过压缩，response entity放在数据帧里。
3. RST_STREAM：报告流错误，payload里携带错误类型。
4. SETTINGS：查询或设置控制信息。可处理的信息有8种：上传带宽、下载带宽、Round Trip时间、最大并行流数量、TCP的CWND值、下载重传率、初始窗口（Window）值、证书数量。
5. PING：一种机制来测量Round Trip时间。
6. GOAWAY：通知即将断开TCP连接。
7. HEADERS：可做补充SVN_REPLY中的response header，或传递私有信息，特定的应用可用做自定义的扩展。
8. WINDOW_UPDATE：设置窗口大小。
下图为帧格式的整理参考（需对照协议文档来理解具体意义，可跳过，点击查看大图）：
1.5 流程
普通流程如下图：
Server Push的server端流程：回复client端的SYN_STREAM之后，再在server端发起SYN_STREAM，并在payload中用字段Associated_To_Stream_ID表示这个推送与哪个stream关联。
2 HTTP/2
2.1 概述HTTP/2准第11版草案于2014年3月17日更新在http://http2.github.io/http2-spec/。
HTTP/2由标准化组织来制定，是基于SPDY的，差别是：
1. 增加了HTTP/1.1 Upgrade的机制，可在TCP上直接使用HTTP/2，不像SPDY那样必须在TLS上。
2. HTTPS连接时使用NPN的规范版ALPN（Applcation Layer Protocol Negociation）。
3. 更完善的协议商讨和确认流程。
4. 更完善的Server Push流程。
5. 增加控制帧的种类，并对帧格式考虑得更细致。
6. 有新算法HPACK专门压缩SPDY header block。
HTTP/2文档带有一些示例和详细说明，这是SPDY没有的。
Chromium最新代码和Google网站已支持HTTP2-10（HTTP/2第10版草案）。
2.2 ALPN
ALPN第5版草案于2014年3月3日发布在http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05。 它是基于NPN的，并做了流程优化，但原则没变，就是在TLS握手过程增加一种协商协议的手段。标准流程为：
Client Server
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- serverhellodone
certificate*
clientkeyexchange*
certificateverify*
[changecipherspec]
finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
目前Chromium的PC发布版已经在使用ALPN，不用NPN了。
如果server支持HTTP/2，则以状态码101回复，形式如下：
然后双方开始以HTTP/2作为传输协议。否则以HTTP/1.1回复response，即HTTP/1.1 200 OK。
3 QUIC
QUIC是Quick UDP Internet Connections的缩写，读作quick。由Google开发，概要设计文档放在google docshttps://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit，还在不断更新。传输格式的详细设计文档放在https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit。
概要设计文档从TCP/UDP特性、网络安全等考虑出发，做了非常多设计思路方面的论述，开头就阐述了SPDY的4个缺点：
1. 单个包（packet）丢失会阻塞整个流（stream）。
2. TCP避免拥堵的机制做的不好，导致带宽降低和序列化的等待时间开销。
3. TLS会话重连的等待时间开销。握手机制带来额外的Round Trip。
4. TLS解密的开销。先到的包必须等后面的包到来才能解密。
可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。
QUIC的文档还算未完成的状态，且Chromium的实现代码也在完善中，这还是个试验性的半成品，没有性能比较的数据。只浅浅研究即止，不深入了。
4 研究与调查
4.1 SPDY服务器搭建4.1.1 Apache具体的搭建方法请参考《Linux Mint + Apache2.2搭建SSL/HTTPS/SPDY服务器》。
环境配置为Linux + Apache2.2 + mod_spdy。其中mod_spdy是Chromium为Apache开发的插件，只支持Apache2.2，直接安装插件包即可。SPDY协议支持版本为3。
4.1.2 Nginx具体的搭建方法请参考《Linux Mint + Nginx 1.5.11搭建SSL/HTTPS/SPDY服务器》。
环境配置为Linux + Nginx1.5.11，需要编译源码来启用SPDY，普通发布包并不支持。SPDY协议支持版本为3.1，还不支持Server Push。
4.1.3 份额根据新闻网页http://www.csdn.net/article/2013-07-04/2816099-nginx-just-became-the-most-used-web-server表示，在全球排名前1000的高流量网站所使用的Web服务器中，Nginx占34.9%，Apache占34.5%。两者分别排名第一和第二，第三的Microsoft-IIS并不支持SPDY。
4.2 Wireshark截包Chromium为Wireshark1.7.1做了源码patch，名为spdyshark，需要下载Wireshark源码和spdyshark源码共同编译才能令Wireshark支持SPDY协议。具体的编译安装方法请参考《Linux Mint下编译安装支持SPDY协议的Wireshark》。
因为SPDY基于TLS，所以Wireshark截包需要先解密SSL，再解析SPDY协议。具体的截包方法请参考《Wireshark+Apache2.4解密SSLv3》和《使用支持SPDY协议的Wireshark截包（含spdyshark插件）》。
4.3 Server端应用现状4.3.1 调查方法调查Web服务器是否支持SPDY，可使用第三方网站的方法：访问http://spdycheck.org/，在网页中输入网址即可反馈结果
但是国内网站并非全站都用HTTPS scheme，所以需要人工找到登录账号的页面来做测试。
还可使用Wireshark截包，在TLS的Server Hello信息中找Extension，ALPN会显示Unknown 16，NPN能识别出是Extension: next_protocol_negotiation。
可知目前Google网站用3.1：
Facebook用2和3：
4.3.2 调查结果
国内外的常见网站看了看，只发现四家：Google、Facebook、wordpress.com和www.cloudflare.com。国内还没有网站支持。（注，此调查结果很粗浅，不可当权威结论）
4.4 Browser端应用现状
4.4.1 测试方法用目标浏览器访问https://isspdyenabled.com/即会在页面上显示是否支持SPDY。
4.4.2 数据根据第三方数据，支持SPDY的浏览器有：
1. Internet Explorer 11 部分支持
2. Firefox 13+
3. Chrome 4+
4. Opera 12.1+
5. Android系统浏览器3.0+（应该是错的，测试的结果是4.1+才对）
6. Opera Mobile 12.1+
7. Chrome for Android 33+
8. Firefox for Android 26+
支持SPDY的浏览器占65.26%。具体请参看http://caniuse.com/spdy。
搜索到CNZZ统计了中国的浏览器份额，但无法直观地看出支持SPDY的占比，个人估算是桌面版低于50%，移动版低于30%。http://brow.data.cnzz.com/main.php?s=brow&uv=1&type=2&date=2014%E5%B9%B402%E6%9C%88。
5 浏览器实现方案
SPDY对浏览器的实现来说，工作在加载框架的网络层。假如已实现SPDY，下图描述网络层内部再分层细化以及各细化层的职责：
无论是HTTP还是SPDY，在一次加载流程中都需要各细化层承担所有的职责。在代码实现来看，若HTTP和SPDY有不同，则需要对各职责设计基类，HTTP和SPDY各自继承基类以实现不同的过程。
SPDY特殊实现的职责有：
1. Callback回调机制。SPDY的HTTP header是压缩的，要与普通HTTP流程对接的话，要么先行解压，要么由callback解压。
2. Protocol Transport协议传输过程控制。特别是Server Push特性。
3. error错误处理
4. SPDY全双工。SPDY的socket是全双工应用，同时发送和接收，和一般的HTTP先发送后接收不同。
5. Framing装帧。这层大部分都和HTTP不同。
6. SSL/TLS handshake握手过程。因为SPDY有NPN。
7. SpdyConnection。Connection一般由URL的scheme、host、port来区分，SPDY和HTTPS的这些区分点全都相同，故connection的复用需增加protocol来区分。
除了Chromium自己外，其SPDY文档还列出了几种实现。C/C++的其它实现，都有个共同点：因为工作在底层，依赖比较多的外部库代码。而且他们最近三个月都还有更新，多数并未支持所有的SPDY特性，并且在修复bug。所以代码的完善程度还不能达到浏览器级别的标准。
6 网站是否该支持SPDY
暂无必要支持SPDY、HTTP/2和QUIC。
原因：
1. SPDY是公司标准，还不是行业标准，存在缺陷，待完善。
2. SPDY成熟的时候就会被接纳并完善成为行业标准甚至国际标准，那时候再支持也不迟。HTTP/2草案就是基于SPDY的，且HTTP/2优于SPDY，SPDY迟早会退出历史舞台，届时业界会大量支持HTTP/2。
3. Server端本身对SPDY的支持不完善，未完全实现所有特性，且存在bug。网站贸然使用的话存在一定风险。Apache2.2 + mod_spdy只支持SPDY3，Nginx1.5.1只支持SPDY3.1，未实现Server Push。等到Server端程序较完善的时候再做也不迟。收费的Server端程序没有一个开始支持SPDY，等到他们开始支持的时候，可认为是一个标志，代表业界会开始做很多配套的东西来支持新标准。
4. Server端并未普及，已应用的网站寥寥无几。
5. 支持SPDY的浏览器在中国的份额低于50%，网站还没迫切必要支持SPDY。Safari完全不支持，即SPDY还未获Apple认可。
1.1 概述SPDY为speedy（单词原意：快速的）的缩写，读音也就是speedy。
SPDY协议已发布过4个草案，分别为版本1、2、3、3.1。目前版本4已在试验阶段，但未发布，Chromium里已有一些针对版本4的代码。
SPDY对比HTTP的优势：
1. 复用连接，可在一个TCP连接上传送多个资源。应对了TCP慢启动的特性。
2. 请求分优先级，重要的资源优先传送。
3. HTTP头部数据也被压缩，省流量。
4. 服务器端可主动连接客户端来推送资源（Server Push）。
缺点：
1. 单连接会因TCP线头阻塞（head-of-line blocking）的特性而传输速度受限。加上存在可能丢包的情况，其负面影响已超过压缩头部和优先级控制带来的好处。
由于这些缺点，SPDY在小网站（资源文件数量较少）的效果不明显，有可能比多并发连接更慢。（由此催生了QUIC）
1.2 协议层次基于安全的考虑，SPDY规定建立在TLS之上，即URL scheme为https。发明者表示TLS的握手是在一定程度上占用了时间和流量，但网络安全是必然的趋势，所以不计较这一成本。协议层次如下：
SPDY ← HTTP
↓
TLS ← NPN
↓
TCP
对比普通的HTTPS协议层次：
HTTP
↓
SSL/TLS
↓
TCP
SPDY协议虽然在TLS基础上代替了HTTP协议，但SPDY的内容又包含了HTTP协议的内容，用设计模式来理解就是应用装饰者模式扩展了HTTP。
另外为了在TLS之上不使用标准规定的HTTP协议，为TLS扩展出NPN（Next Protocol Negotiation，协议协商）。
1.3 NPNNPN简单来说就是在TLS的握手阶段增加一些字段来表明服务器端和客户端希望在TLS基础上使用HTTP之外的（SPDY）协议。NPN同样是Google提出的，为SPDY铺路。
Client端程序的实现是：握手前对OpenSSL（或封装它的库）设置可接受哪些协议，握手后获取选择了哪个协议，然后按选择的协议进行通信。
1.4 数据格式本节不会完整介绍SPDY，只讲重点，并假定读者熟悉HTTP协议而不解释SPDY中类似HTTP的概念。
SPDY把一次单向传输（服务器到客户端或客户端到服务器）的内容称作帧（frame），按协议组装帧内容称为装帧（framing）。帧内容分为头部（header）和载荷（payload），类似于HTTP的头部（header）和实体（entity），但有以下区别：
1. SPDY的头部都是8个字节，根据其中一些位的数值不同来表示不同的信息，并把HTTP的头部放到SPDY的载荷里。
2. HTTP的实体（除POST信息外）是文件数据（data），SPDY的载荷除了可以是文件数据还可以是其它信息。
根据载荷的内容，帧分为控制帧和数据帧。
控制帧的数据格式：
+----------------------------------+
|C| Version(15bits) | Type(16bits) |
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Data |
+----------------------------------+
数据帧的数据格式：
+----------------------------------+
|C| Stream-ID (31bits) |
+----------------------------------+
| Flags (8) | Length (24 bits) |
+----------------------------------+
| Data |
+----------------------------------+
各数据位的意义：
* C是第一个bit，值为0或1分别表示数据帧和控制帧。
* Version为SPDY协议版本号，目前为3。
* Type用作区分控制帧的类型。
* Flags标记一些操作指示，不同的Type有不同的Flag。常见的是FLAG_FIN表示一个Stream结束。
* Length表示Data的数据长度。
* Data也就是payload。数据帧的Data就是一个文件（HTML文档、图片、脚本等），控制帧的Data根据Type不同而有不同。
* Stream-ID记录流水号。
SPDY把一次HTTP Request/Response来回称作流（Stream），因为复用TCP连接，所以一个SPDY连接里会有多个流。为了区分不同的流，用Stream-ID来标记流水号（注：因为可以reload，所以不能以URL来确定一个流）。Stream-ID还存在于4种控制帧（SYN_STREAM、SYN_REPLY、RST_STREAM、HEADERS）的payload里。
控制帧的8种类型及作用：
1. SYN_STREAM：创建流，在payload里携带请求（Request）。
2. SYN_REPLY：回复创建流，在payload里携带HTTP头部。注意：SPDY把HTTP response拆开，response header放在控制帧SYN_REPLY的payload里并经过压缩，response entity放在数据帧里。
3. RST_STREAM：报告流错误，payload里携带错误类型。
4. SETTINGS：查询或设置控制信息。可处理的信息有8种：上传带宽、下载带宽、Round Trip时间、最大并行流数量、TCP的CWND值、下载重传率、初始窗口（Window）值、证书数量。
5. PING：一种机制来测量Round Trip时间。
6. GOAWAY：通知即将断开TCP连接。
7. HEADERS：可做补充SVN_REPLY中的response header，或传递私有信息，特定的应用可用做自定义的扩展。
8. WINDOW_UPDATE：设置窗口大小。
下图为帧格式的整理参考（需对照协议文档来理解具体意义，可跳过，点击查看大图）：
1.5 流程
普通流程如下图：
Server Push的server端流程：回复client端的SYN_STREAM之后，再在server端发起SYN_STREAM，并在payload中用字段Associated_To_Stream_ID表示这个推送与哪个stream关联。
2 HTTP/2
2.1 概述HTTP/2准第11版草案于2014年3月17日更新在http://http2.github.io/http2-spec/。
HTTP/2由标准化组织来制定，是基于SPDY的，差别是：
1. 增加了HTTP/1.1 Upgrade的机制，可在TCP上直接使用HTTP/2，不像SPDY那样必须在TLS上。
2. HTTPS连接时使用NPN的规范版ALPN（Applcation Layer Protocol Negociation）。
3. 更完善的协议商讨和确认流程。
4. 更完善的Server Push流程。
5. 增加控制帧的种类，并对帧格式考虑得更细致。
6. 有新算法HPACK专门压缩SPDY header block。
HTTP/2文档带有一些示例和详细说明，这是SPDY没有的。
Chromium最新代码和Google网站已支持HTTP2-10（HTTP/2第10版草案）。
2.2 ALPN
ALPN第5版草案于2014年3月3日发布在http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05。 它是基于NPN的，并做了流程优化，但原则没变，就是在TLS握手过程增加一种协商协议的手段。标准流程为：
Client Server
ClientHello --------> ServerHello
(ALPN extension & (ALPN extension &
list of protocols) selected protocol)
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- serverhellodone
certificate*
clientkeyexchange*
certificateverify*
[changecipherspec]
finished -------->
[ChangeCipherSpec]
<-------- Finished
Application Data <-------> Application Data
目前Chromium的PC发布版已经在使用ALPN，不用NPN了。
如果server支持HTTP/2，则以状态码101回复，形式如下：
然后双方开始以HTTP/2作为传输协议。否则以HTTP/1.1回复response，即HTTP/1.1 200 OK。
3 QUIC
QUIC是Quick UDP Internet Connections的缩写，读作quick。由Google开发，概要设计文档放在google docshttps://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/edit，还在不断更新。传输格式的详细设计文档放在https://docs.google.com/document/d/1WJvyZflAO2pq77yOLbp9NsGjC1CHetAXV8I0fQe-B_U/edit。
概要设计文档从TCP/UDP特性、网络安全等考虑出发，做了非常多设计思路方面的论述，开头就阐述了SPDY的4个缺点：
1. 单个包（packet）丢失会阻塞整个流（stream）。
2. TCP避免拥堵的机制做的不好，导致带宽降低和序列化的等待时间开销。
3. TLS会话重连的等待时间开销。握手机制带来额外的Round Trip。
4. TLS解密的开销。先到的包必须等后面的包到来才能解密。
可以认为QUIC是为了解决SPDY在TCP遇到的瓶颈而在UDP上做探索所设计的方案。参考SPDY来理解，可认为QUIC的传输内容分两层，高层类似SPDY，低层是在UDP上模仿实现TCP的面向连接特性和可靠性并加入类似TLS的加密过程。
QUIC的文档还算未完成的状态，且Chromium的实现代码也在完善中，这还是个试验性的半成品，没有性能比较的数据。只浅浅研究即止，不深入了。
4 研究与调查
4.1 SPDY服务器搭建4.1.1 Apache具体的搭建方法请参考《Linux Mint + Apache2.2搭建SSL/HTTPS/SPDY服务器》。
环境配置为Linux + Apache2.2 + mod_spdy。其中mod_spdy是Chromium为Apache开发的插件，只支持Apache2.2，直接安装插件包即可。SPDY协议支持版本为3。
4.1.2 Nginx具体的搭建方法请参考《Linux Mint + Nginx 1.5.11搭建SSL/HTTPS/SPDY服务器》。
环境配置为Linux + Nginx1.5.11，需要编译源码来启用SPDY，普通发布包并不支持。SPDY协议支持版本为3.1，还不支持Server Push。
4.1.3 份额根据新闻网页http://www.csdn.net/article/2013-07-04/2816099-nginx-just-became-the-most-used-web-server表示，在全球排名前1000的高流量网站所使用的Web服务器中，Nginx占34.9%，Apache占34.5%。两者分别排名第一和第二，第三的Microsoft-IIS并不支持SPDY。
4.2 Wireshark截包Chromium为Wireshark1.7.1做了源码patch，名为spdyshark，需要下载Wireshark源码和spdyshark源码共同编译才能令Wireshark支持SPDY协议。具体的编译安装方法请参考《Linux Mint下编译安装支持SPDY协议的Wireshark》。
因为SPDY基于TLS，所以Wireshark截包需要先解密SSL，再解析SPDY协议。具体的截包方法请参考《Wireshark+Apache2.4解密SSLv3》和《使用支持SPDY协议的Wireshark截包（含spdyshark插件）》。
4.3 Server端应用现状4.3.1 调查方法调查Web服务器是否支持SPDY，可使用第三方网站的方法：访问http://spdycheck.org/，在网页中输入网址即可反馈结果
但是国内网站并非全站都用HTTPS scheme，所以需要人工找到登录账号的页面来做测试。
还可使用Wireshark截包，在TLS的Server Hello信息中找Extension，ALPN会显示Unknown 16，NPN能识别出是Extension: next_protocol_negotiation。
可知目前Google网站用3.1：
Facebook用2和3：
4.3.2 调查结果
国内外的常见网站看了看，只发现四家：Google、Facebook、wordpress.com和www.cloudflare.com。国内还没有网站支持。（注，此调查结果很粗浅，不可当权威结论）
4.4 Browser端应用现状
4.4.1 测试方法用目标浏览器访问https://isspdyenabled.com/即会在页面上显示是否支持SPDY。
4.4.2 数据根据第三方数据，支持SPDY的浏览器有：
1. Internet Explorer 11 部分支持
2. Firefox 13+
3. Chrome 4+
4. Opera 12.1+
5. Android系统浏览器3.0+（应该是错的，测试的结果是4.1+才对）
6. Opera Mobile 12.1+
7. Chrome for Android 33+
8. Firefox for Android 26+
支持SPDY的浏览器占65.26%。具体请参看http://caniuse.com/spdy。
搜索到CNZZ统计了中国的浏览器份额，但无法直观地看出支持SPDY的占比，个人估算是桌面版低于50%，移动版低于30%。http://brow.data.cnzz.com/main.php?s=brow&uv=1&type=2&date=2014%E5%B9%B402%E6%9C%88。
5 浏览器实现方案
SPDY对浏览器的实现来说，工作在加载框架的网络层。假如已实现SPDY，下图描述网络层内部再分层细化以及各细化层的职责：
无论是HTTP还是SPDY，在一次加载流程中都需要各细化层承担所有的职责。在代码实现来看，若HTTP和SPDY有不同，则需要对各职责设计基类，HTTP和SPDY各自继承基类以实现不同的过程。
SPDY特殊实现的职责有：
1. Callback回调机制。SPDY的HTTP header是压缩的，要与普通HTTP流程对接的话，要么先行解压，要么由callback解压。
2. Protocol Transport协议传输过程控制。特别是Server Push特性。
3. error错误处理
4. SPDY全双工。SPDY的socket是全双工应用，同时发送和接收，和一般的HTTP先发送后接收不同。
5. Framing装帧。这层大部分都和HTTP不同。
6. SSL/TLS handshake握手过程。因为SPDY有NPN。
7. SpdyConnection。Connection一般由URL的scheme、host、port来区分，SPDY和HTTPS的这些区分点全都相同，故connection的复用需增加protocol来区分。
除了Chromium自己外，其SPDY文档还列出了几种实现。C/C++的其它实现，都有个共同点：因为工作在底层，依赖比较多的外部库代码。而且他们最近三个月都还有更新，多数并未支持所有的SPDY特性，并且在修复bug。所以代码的完善程度还不能达到浏览器级别的标准。
6 网站是否该支持SPDY
暂无必要支持SPDY、HTTP/2和QUIC。
原因：
1. SPDY是公司标准，还不是行业标准，存在缺陷，待完善。
2. SPDY成熟的时候就会被接纳并完善成为行业标准甚至国际标准，那时候再支持也不迟。HTTP/2草案就是基于SPDY的，且HTTP/2优于SPDY，SPDY迟早会退出历史舞台，届时业界会大量支持HTTP/2。
3. Server端本身对SPDY的支持不完善，未完全实现所有特性，且存在bug。网站贸然使用的话存在一定风险。Apache2.2 + mod_spdy只支持SPDY3，Nginx1.5.1只支持SPDY3.1，未实现Server Push。等到Server端程序较完善的时候再做也不迟。收费的Server端程序没有一个开始支持SPDY，等到他们开始支持的时候，可认为是一个标志，代表业界会开始做很多配套的东西来支持新标准。
4. Server端并未普及，已应用的网站寥寥无几。
5. 支持SPDY的浏览器在中国的份额低于50%，网站还没迫切必要支持SPDY。Safari完全不支持，即SPDY还未获Apple认可。