SPDY(發音同"speedy")：Google開發的下一代HTTP協定
（解決HTTP協定的缺點,Wrapper模式）
概述
SPDY是Google宣布正在開發的下一代網絡協定，SPDY并不是一種用于替代HTTP的協定，而是對HTTP協定的增強。HTTP自上世紀90年代問世以來，已有二十年的曆史，期間網際網路本身發生了很大的變化，也使得HTTP的許多不足暴露了出來，現在它已經不能滿足許多web app的要求。Google表示，引入SPDY協定後，在實驗室測試中頁面加載速度比原先快64%，并且目前已經在Gmail等應用中使用。目前業界支援SPDY的伺服器有Netty和Nginx(将要支援)。Nginx 官方釋出下一個版本 1.3.0 的路線圖，該版本将支援 Google SPDY
Google之是以要改動HTTP協定而不是TCP/IP，是因為改變HTTP隻需更新Browser和web server就行了，而改動TCP/IP就困難多了，牽扯面太廣，需要更新巨量的路由器，伺服器和用戶端的作業系統。
SPDY的設計特點
SPDY的設計特點是在SSL層的基礎上，增加了一個session 層，進而在一個tcp 連接配接基礎上，實作了多并發和交叉流傳輸。HTTP 的GET ,POST 仍舊采用舊有的消息格式，當然SPDY 協定對原有的資料做了封裝和編碼，這裡采用Wrapper設計模式。
SPDY的目标就是通過其基本特性和進階特性，來達到低通路延遲。
SPDY的特性
1、流複用
SPDY最牛逼的地方，是允許在一個TCP連接配接裡面，允許無限并發流（在雙方資源可承受的情況下）。因為請求是在一個單一的通道交錯傳輸，TCP可以達到很高的效率，進而減少網絡連接配接需要，可以以很高的資料密度做傳輸。
2、優先級：（因為支援并行，是以必須要有優先級機制）
雖然無限的并行資料流解決了序列化問題，但是它們引入了另一個問題：如果由于信道帶寬的限制，用戶端可能會阻止怕堵塞通道的要求。為了克服這個問題，SPDY實作請求的優先次序：用戶端可以請求盡可能多的項目，每個請求配置設定一個優先級。這樣 即使高優先級的請求仍處在pending狀态，通道也不會傳輸非關鍵的，低優先級的請求，這樣就有效地阻止了傳輸擁塞。
3、Http header壓縮
對于HTTP 請求，響應頭，SPDY都做了壓縮，這樣包更小，對于RESTFUL類型的WEB2.0 ,or OpenAPI 業務，将會有可觀的效率提升。
4、伺服器端推送
SPDY通過X-Associated-Content 協定頭來向用戶端推送資料。通知用戶端，我要向你推送資源，準備接收好了。最近火爆的Google+ ,如果你用chrome浏覽器，預設就采用SPDY技術，并且開啟了伺服器推送技術。伺服器的推技術，全面提升了使用者體驗，使G+ 産品很快占據了足夠多的優勢，最近Facebook 開發自己的浏覽器，也有擺脫現在技術限制的考慮。
5、Server hint
不像上面提到的PUSH 技術，伺服器會先告訴浏覽器，你可以下載下傳ABC資源了，這個ABC資源，可能就是下一個頁面的JS ,CSS ，或者内容。伺服器不會主動推送的，仍舊等待用戶端請求，這對于低速網絡，是個很大的優化，有點類似于我們的預加載技術。
6、安全防攻擊
這點在官網上沒有介紹到，但由于SPDY采用了SSL+資料壓縮，安全性上有了很大提升。尤其很多國家的網絡審查将很難使用。這是否會成為SPDY發展的一個限制呢？
工作機制
從SPDY協定的設計角度來看，它在HTTP和SSL層之間增加了一個SPDY會話層，原有的GET和POST請求的格式都不變，SPDY會話層會把請求封裝成一個SPDY frame（SPDY幀），然後把SPDY幀丢給ssl層或者tcp層發送，這樣做一方面是為了盡量相容現有的HTTP協定，另一方面也主要是讓SPDY協定易于部署，對應用層來說是透明的。
在SPDY協定中有幾個概念是比較重要的：
1、session--會話，一個SPDY會話實質上就是一個tcp連接配接。
2、stream--虛拟流，一個SPDY會話可以擁有多條虛拟流，每條流都有辨別其身份的流ID，所有的請求和應答都是通過流進行的
3、frame--SPDY幀，在SPDY協定中，用戶端和伺服器互動的資料就是SPDY幀，SPDY幀可以分為控制幀和資料幀，資料幀和控制幀通過幀的第一個比特位進行區分，幀的具體結構這裡就不分析了，有興趣的可以去檢視google釋出的SPDY草案。
首先來看下SPDY協定中的http請求和應答格式，為了與目前的web應用盡可能的相容，SPDY協定基本上保留了http請求頭和響應頭語義，主要的變化有以下幾點：
1、請求和應答頭中的connection和keep-alive不再有效，即使存在也會被忽略，host頭也會被忽略
2、預設并且強制使用gzip壓縮
3、http請求和應答報頭都将被壓縮
當使用者請求打開一個網頁，SPDY會話層會向web伺服器發起一個tcp連接配接，（在spdy協定中所有的tcp連接配接都是長連接配接，用戶端一般不會斷開連接配接，除非使用者離開目前頁面，跳向另一個頁面，連接配接的斷開由伺服器負責， 伺服器會關掉那些長時間處于空閑的連接配接），建立tcp連接配接後，用戶端和伺服器就會開始進行幀的互動。
首先用戶端為了發送http請求，需要與服務端建立虛拟流連接配接，建立流連接配接的過程和tcp建立連接配接的過程很相似，如上圖所示，用戶端發送SYN_STREAM控制幀，控制幀中可以包含流優先級，高優先級流中的請求将會被伺服器優先處理，伺服器收到SYN_STREAM幀後将回複SYN_REPLY幀表示連接配接建立，這裡要注意的是，用戶端不需要等待SYN_REPLY幀，就可以直接在該條流上發送資料幀。當連接配接建立後，雙方就可以在流上發送資料了。當一方發送資料完畢後，就可以發送一個帶有FIN_FLAG标志的幀，表示不會在該流上發送資料，流連接配接處于半關閉狀态，如果雙方都處于半關閉狀态時，流就會被認為結束了，另外有個FIN_STREAM控制幀用于主動或者異常情況下結束流的傳輸。
與http協定相比
HTTP 1.1協定的不足:
1、一個連接配接同時隻能處理一個請求。
也就是說，一個HTTP連接配接一次隻能請求一個資源，即使是長連接配接，下 一個資源的請求也隻能等到上一個請求完成後才能執行，伺服器的端到端延遲使得tcp的重用率很低。為了提高網頁加載速度，浏覽器則通過建立多條連接配接來同時請求多個資源,（目前浏覽器設定每個域的連接配接數為6個），這會帶來一定的開銷，而且請求的連接配接數也是有限的。
2、HTTP請求和響應頭未壓縮
随着網際網路應用越來越多的使用cookie和useragents等擴充特性，目前HTTP的請求和響應頭越來越大，請求頭部大小達到700-800bytes已經很常見了，甚至還有達到2kb的，對于低帶寬的網絡，這會帶來很大的延遲，減小頭部的大小可以有效的降低資料傳輸延遲。
3、HTTP備援頭部
有些HTTP頭比如User-Agent，Host和Accept等會重複的發送，這些字段基本上是不變的，沒有必要進行重複發送。
4、隻有用戶端才能發送請求
在現在的HTTP協定中，隻有用戶端才能主動的發起請求，伺服器端即使知道用戶端需要哪些資源，它也不能主動的發送，隻能等待用戶端發起對該資源的請求。
SPDY協定認為以上不足嚴重影響了網頁的下載下傳速度，針對這些不足的地方SPDY協定主要進行了以下四個方面的改進(即四個特性)：
1、在一個SPDY連接配接中允許建立多條stream（虛拟流），并發發送多個HTTP請求，請求個數是沒有限制的，這裡涉及到連接配接中虛拟流的概念。
2、HTTP請求可以具有優先級，也就是說用戶端可以要求伺服器優先發送重要的資源，這就避免了一個處理時間很長的非關鍵請求阻塞了伺服器對後面請求的處理，影響網頁的加載速度。
3、SPDY協定允許壓縮頭部，減小HTTP頭部的大小，減小對帶寬的占用。
4、伺服器可以主動的給用戶端發送資料，不需要用戶端的主動請求