如果你正在使用Chrome瀏覽器查看Gmail郵件的話，那么你很可能已經(jīng)在不知不覺中開始使用Google規(guī)劃的下一代互聯(lián)網(wǎng)通訊協(xié)議SPDY了。Google在2009年11月***對外宣布了SPDY協(xié)議，這是Google構(gòu)建快速網(wǎng)絡(luò)中非常關(guān)鍵的一環(huán)。

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

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

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

拓展閱讀：

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

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

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

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

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

1 雖然減少了tcp連接數(shù)量，但是留下來的tcp全都是長連接?？蛻舳说呢摀菧p少了，但是對proxy和服務(wù)器來說，是否會帶來性能影響？存疑。

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