关于HTTP安全性的问题，我们可以使用HTTPS来解决。但是HTTP都发布十几年了，有些规则已经过时了，HTTP/1.1的规则在功能上完全可以开发一套新的协议来弥补，但是由于遵循HTTP协议的Web浏览器已经遍布全球，无法完全抛弃，只能在HTTP基础上不断的累加一些新的功能来满足需求。SPDY就是其中之一。
SPDY的诞生
SPDY（取自SPeeDY,发音同speedy）是Google在2010年发布的，其开发目标旨在解决HTTP的性能瓶颈，缩短Web页面的加载时间。
SPDY并不是一种用于替代HTTP的协议，而是对HTTP协议的增强。新协议的功能包括数据流的多路复用、请求优先级以及HTTP报头压缩等新机制。Google表示，引入SPDY协议后，在实验室测试中页面加载速度比原先快64%。
SPDY出现以后很多著名的互联网公司，例如百度、淘宝、UPYUN 都在自己的网站或 APP 中采用了 SPDY 系列协议，因为它对性能的提升是显而易见的。主流的浏览器（谷歌、火狐、Opera）也都早已经支持 SPDY，它已经成为了工业标准（其实现在的情况不是这样了，留个悬念后面说），HTTP Working-Group 最终决定以 SPDY/2 为基础，开发 HTTP/2。
SPDY以会话的形式加入，为了安全，它强制性使用SSL/TLS，控制对数据的流动，但还是采用HTTP建立通信连接。
SPDY进阶
前面简单说了一下SPDY的历史和发展，那么我们首先来看一下HTTP到底有哪些瓶颈，和引入SPDY的必要性。
HTTP的瓶颈
请求受限制
首先来说最初的HTTP/1.0的时候，一次TCP的链接上只能发送一个HTTP请求，导致HTTP传输的效率特别低。
好在HTTP/1.1的时候，引入了持久链接和管道机制，使得HTTP的传输效率得到了很大的提升（详细和可查看HTTP基本认识）。持久链接满足了一条TCP链接可以发送多条HTTP请求的问题，但是每次HTTP请求必须等上一次HTTP响应了以后才能发送新的一条HTTP请求。管道机制实现了在持久链接的基础上同时发送多条HTTP请求的机制，但是响应的时候必须按照顺序来响应（如下图）。
请求发起方必须是客户端
HTTP/1.1之前的HTTP请求的只能有客户端发起，服务端返回响应。这种模式导致服务端不能主动发送信息给客户端，所以一些像股票之类的要求时效性的信息无法及时推送到客户端。当然人们研究出了轮训、长轮询、流等解决方案实现，其中著名的就是Comet技术。但是它也存在问题，不是本文重点，就做详细描述了。
请求/响应首部未经过压缩
HTTP请求或者响应首部每次都要发送一些相关信息，但是HTTP/1.1之前每次HTTP请求都要重复发送这些信息，这样就有些浪费带宽了，而且现在首部信息越来越多，这个问题就更严重了。
任意选择数据压缩格式
HTTP/1.0中就提出了Content-Encoding字段来压缩数据，但是可任意选择数据压缩格式，非强制压缩发送。
针对以上HTTP的瓶颈，Google在2010年发布了SPDY。
SPDY基本功能
多路复用
通过单一的TCP链接，可以无限制处理多个HTTP请求，所有请求的处理都在一条TCP连接上完成，因此TCP的处理效率得到提高。
赋予请求优先级
SPDY不仅可以无限制地并发处理请求，还可以给请求逐个分配优先级顺序。这样主要是为了在发送多个请求时，解决因带宽低而导致响应变慢的问题。
压缩HTTP首部
压缩HTTP请求和响应首部。这样一来，通信产生的数据包数量和发送的字节数就更少了。
推送功能
支持服务器主动向客户端推送数据的功能。这样服务器可直接发送数据，而不必等待客户端的请求了。
服务器提示功能
服务器可以主动提示客户端请求所需的资源。由于在客户端发现资源之前就可以获知资源的存在，因此在资源已缓存等情况下，可以避免发送不必要的请求。
后记
前面说了这么多SPDY的优点，但是
谷歌计划于 2016 年初在 Chrome 中移除 SPDY。它还将移除对某些基于 SPDY 的 TLS 扩展。谷歌预计将在未来几周内，为 Chrome 40 添加 HTTP/2 协议支持。
所以现在你可以去直接学习HTTP/2了，好在HTTP Working-Group 最终决定以 SPDY/2 为基础，开发 HTTP/2。
本文借鉴资料：
