如果你正在使用Chrome瀏覽器查看Gmail郵件的話，那么你很可能已經在不知不覺中開始使用Google規劃的下一代互聯網通訊協議SPDY了。Google在2009年11月***對外宣布了SPDY協議，這是Google構建快速網絡中非常關鍵的一環。

在過去的18個月里面，SPDY已經逐漸被集成到了Stable分支的Chrome中。簡單來說SPDY是更先進，更有效率的HTTP協議。SPDY協議可以通過一個單獨的TCP鏈接實現并行的多路復用流通信，并且支持優先級，優先傳送最重要的HTML內容，而其他JavaScript，視頻等不是太重要的內容的優先級則會相對較低。總之，SPDY協議可以將頁面載入時間縮短到現在的一半左右。

SPDY***的優勢在于其是一個開源項目，現在我們正在使用的HTTP 1.1像個笨拙的巨獸，急需一個可以實現低延遲以及實時計算的新協議來取而代之。SPDY是個非常好的選擇，但是現在還沒有被大家廣泛接受，目前貌似只有一個適用于Apache的實驗性mod。

要想現在體驗SPDY的話，其實非常簡單：下載并安裝Chrome，打開某個Google的站點（比如Gmail），之后在Chrome里面打開chrome://net-internals即可看到當前活動的SPDY進程了。對于使用者來說，SPDY相比HTTP沒有任何區別，我們也很難“看”出使用了SPDY協議后有什么改進，但是我們肯定可以感覺到Google服務在Chrome下異常的快，這就是SPDY的功勞了。

拓展閱讀：

spdy的spec [ http://dev.chromium.org/spdy/spdy-protocol ]  里什么都說得很清楚了。這個spdy的想法似乎不是很高招，但是卻這么多年了沒人提出過，這也許不是因為其他人不夠聰明。***將會說到為什么。

http的性能損失，在spdy看來，來源于多鏈接。比如打開一個頁面，除了文本另外還有圖片等，那么瀏覽器就必須建立多個TCP，對每個資源發送http request。

而spdy提供了在一個TCP連接里請求多個資源的能力，并且提供了類似QoS的機制，使得瀏覽器對每個請求可以指定不同優先級，避免低優先級的請求把高優先級的給block了。另外，對http做了一些精簡，去掉了一些沒必要的headers。除此之外才是gzip壓縮。

spdy把payload用frame來劃分。frame分為control和data兩種，這點看起來類似于ftp和rtsp。每個frame有對應的flags，flags的設計類似于tcp。spdy的思想大概就這么多，剩下的都是細節，如果不是實現者，沒必要去研究了。spdy***的優點就是***程度的減少了tcp連接。

但是spdy有兩個與生俱來的缺點：

1 雖然減少了tcp連接數量，但是留下來的tcp全都是長連接。客戶端的負擔是減少了，但是對proxy和服務器來說，是否會帶來性能影響？存疑。

2 與現有的服務器兼容。不可能100%兼容。spec也說了，是盡量使其與現有服務器端兼容。而且從服務器和proxy的實現來說，現在的趨勢是歡迎大量短連接，以提高并發量，這恰恰與spdy的思想是相悖的。最樂觀的估計，chrome霸占了客戶端市場，那服務器端難道google也想把apache/iis/ngix以及各種proxy給swap了？