為我們準備的SPDY
最近周圍關于SPDY的討論很多,它是Google提出的一個新的協議,用來加速Web網絡訪問。大多數 主流 瀏覽器和 Web服務器已經開始發布支持SPDY的版本。所以我覺得去探索更多關于SPDY的知識和它對我們Web開發者的影響是值得的。什么是SPDY?
萬維網是在HTTP協議的基礎上開發的,它是一個應用層協議,使用TCP作為傳輸層(如果對分層概念混淆,參考
OSI參考模型)。這意味著客戶端的每個請求創建都要一個新的服務器連接。雖然它最初是可以幫助使問題簡單些,但對于現在Web的需求它會導致一些問題。
SPDY的設計,就是為了解決HTTP協議中的這些缺點。它使用單一連接來處理所有客戶端和服務器之間的請求/響應。
SPDY的核心是幀管理層(framing layer),它管理兩個端點間的連接和數據的傳輸。 兩個端點之間可以有多個數據流。 在幀管理層的頂部,SPDY實現了HTTP請求/響應處理。這使得我們不需要對現有網站做太大的更改或不更改就可以使用SPDY。
使用SPDY有什么好處?
因為少了為每個請求建立連接的開銷,響應延遲會很低。
除了數據部分,SPDY也會壓縮請求/響應頭。對于手機和其他速度很慢甚至要珍惜每個字節的連接,這將是有用的。
SPDY被設計為使用SSL處理所有客戶端和服務器間的通信,這意味著該網站會更加安全。
服務器可以使用SPDY推送數據到客戶端,而不是等待客戶端的請求,這可以幫助網站更有效的利用資源。
已經投入生產環境了?

訪問下面的URL,查看哪些網站正在使用SPDY.
chrome://net-internals/#spdy
怎樣給我的站點添加SPDY支持?
添加SPDY支持的最簡單方式是啟用Apache的
mod_spdy模塊。mod_spdy通過鉤子(hook)修改了Apache的默認請求/響應處理過程并添加了SPDY處理。
切換到SPDY帶來的速度提升可能會隨著網站現有配置而不同。如果你在使用像
wildcard asset hosts(如:assets%d.example.com)之類的HTTP性能優化,那將會導致SPDY創建為同一個端點創建多個連接,因此會降低性能。一些瀏覽器如Chrome通過
連接池巧妙的處理了這個問題。還有,一些CDN如Amazon Cloudfront仍然
不支持SPDY,所以這些資源需要使用HTTP連接去加載。
你可以使用類似
Chromium Page Benchmarker之類的工具來檢測你的網站不同配置下在使用和不使用SPDY情況下的表現。

我需要一個SSL證書嗎?
在初始化連接時,mod_spdy使用SSL握手和Next Protocol Negotiation (NPN)來通知客戶端服務器支持SPDY。此外,要在已存在的HTTP代理上工作,SPDY需要通過SSL隧道傳輸數據流,這意味著目前你需要一個有效的SSL證書來使你的網站支持SPDY。
然而,無SSL的情況下也是可以在本地測試SPDY的。所以,你可以使用參數--use-spdy=no-ssl運行Chrome,這樣就可以連接一個支持SPDY服務器而不使用SSL了。
SPDY可以幫助建立實時性Web應用程序嗎?
值得注意的是,SPDY并沒有為使用
WebSockets提供任何特別的好處。因此,從更高級別上看它們可能很像,都是完全獨立的協議。它們的創建是為了不同的目的,甚至它們兩個的內部幀算法都是不一樣的。
另一方面,SPDY固有的異步流(
asynchronous streams)將會幫助實現如
服務器發送事件(Server-Sent Event)之類的功能。
SPDY不是終極武器!
SPDY將會持續改進成為一個更加穩定的協議,并且以后會使HTTP協議更加成功。考慮到成本,除非你在運行一個負載較高的網站,否則添加SPDY支持不會有立竿見影的效果的。
所以,最好先考慮
一般的頁面優化技術然后再考慮SPDY,如果你想去掉那些額外的延遲。
進一步閱讀:
SPDY: It's Here! by Roberto Peon (Google I/O talk)
</div> 本文由用戶 jopen 自行上傳分享,僅供網友學習交流。所有權歸原作者,若您的權利被侵害,請聯系管理員。
轉載本站原創文章,請注明出處,并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺,歡迎各類分享!