如何理解 TCP/IP, SPDY, WebSocket 三者之間的關係？

12-29

按照OSI網路分層模型，IP是網路層協議，TCP是傳輸層協議，而HTTP是應用層的協議。在這三者之間，SPDY和WebSocket都是與HTTP相關的協議，而TCP是HTTP底層的協議。

一、HTTP的不足
HTTP協議經過多年的使用，發現了一些不足，主要是性能方面的，包括：

HTTP的連接問題，HTTP客戶端和伺服器之間的交互是採用請求/應答模式，在客戶端請求時，會建立一個HTTP連接，然後發送請求消息，服務端給出應答消息，然後連接就關閉了。（後來的HTTP1.1支持持久連接）
因為TCP連接的建立過程是有開銷的，如果使用了SSL/TLS開銷就更大。
在瀏覽器里，一個網頁包含許多資源，包括HTML，CSS，JavaScript，圖片等等，這樣在載入一個網頁時要同時打開連接到同一伺服器的多個連接。
HTTP消息頭問題，現在的客戶端會發送大量的HTTP消息頭，由於一個網頁可能需要50-100個請求，就會有相當大的消息頭的數據量。
HTTP通信方式問題，HTTP的請求/應答方式的會話都是客戶端發起的，缺乏伺服器通知客戶端的機制，在需要通知的場景，如聊天室，遊戲，客戶端應用需要不斷地輪詢伺服器。

而SPDY和WebSocket是從不同的角度來解決這些不足中的一部分。除了這兩個技術，還有其他技術也在針對這些不足提出改進。

二、SPDY
SPDY的主要目的是減少50%以上的頁面載入時間，但是呢不增加部署的複雜性，不影響客戶端和服務端的Web應用，只需要瀏覽器和Web伺服器支持SPDY。主要有以下幾點：

多路復用，一個TCP連接上同時跑多個HTTP請求。請求可設定優先順序。
去除不需要的HTTP頭，壓縮HTTP頭，以減少需要的網路帶寬。
使用了SSL作為傳輸協議提供數據安全。
對傳輸的數據使用gzip進行壓縮
提供服務方發起通信，並向客戶端推送數據的機制。

實質上，SPDY就是想不影響HTTP語義的情況下，替換HTTP底層傳輸的協議來加快頁面載入時間。

SPDY的解決辦法就是設計了一個會話層協議--幀協議，解決多路復用，優先順序等問題，然後在其上實現了HTTP的語義。

三、WebSocket
WebSocket則提供使用一個TCP連接進行雙向通訊的機制，包括網路協議和API，以取代網頁和伺服器採用HTTP輪詢進行雙向通訊的機制。

本質上來說，WebSocket是不限於HTTP協議的，但是由於現存大量的HTTP基礎設施，代理，過濾，身份認證等等，WebSocket借用HTTP和HTTPS的埠。

由於使用HTTP的埠，因此TCP連接建立後的握手消息是基於HTTP的，由伺服器判斷這是一個HTTP協議，還是WebSocket協議。 WebSocket連接除了建立和關閉時的握手，數據傳輸和HTTP沒丁點關係了。

WebSocket也有自己一套幀協議。

四、SPDY和WebSocket的關係
SPDY和WebSocket的關係比較複雜。

補充關係，二者側重點不同。SPDY更側重於給Web頁面的載入提速，而WebSocket更強調為Web應用提供一種雙向的通訊機制以及API。
競爭關係，二者解決的問題有交集，比如在伺服器推送上SPDY和WebSocket都提供了方案。
承載關係，試想，如果SPDY的標準化早於WebSocket，WebSocket完全可以側重於API，利用SPDY的幀機制和多路復用機制實現該API。 Google提出草案，說WebSocket可以跑在SPDY之上。WebSocket的連接建立在SPDY的流之上，將WebSocket的幀映射到SPDY的幀上。
融合關係，如微軟在HTTP Speed+Mobility中所做的。

五、題外話
1. HTTP Speed+Mobility
還有一個有趣的技術叫做HTTP Speed+Mobility，和SPDY一樣都是HTTP 2.0標準的競爭者，HTTP Speed+Mobility來自微軟。HTTP SM借鑒了SPDY和WebSocket的協議，將二者揉為一體，又有所取捨。

HTTP SM的設計原則包括：

保留HTTP的語義，這一點和SPDY一致，但也正應如此，拋棄了SPDY里的ServerPush。
遵守分層的網路架構，TCP能做的，HTTP SM不做，因此去除了SPDY的流控。
使用現有標準，因此使用HTTP/1.1 Upgrade header機制，借用了WebSocket的握手機制和幀格式（RFC6455）。
客戶端掌握內容的控制，因此不強制使用壓縮和SSL/TLS。
考慮到網路的費用和電力，這點考慮到了移動設備以及物聯網，提供了Credit Control機制。

HTTP SM分以下幾層：

會話層和幀協議，這部分取自WebSocket協議。包括握手機制，以及幀格式。
流層（包括多路復用），這部分主要借鑒SPDY，包括多路復用，流優先順序，但增加了Credit Control。這部分作為 WebSocket協議的擴展。
HTTP層，在流層上實現HTTP語義，這部分也借鑒自SPDY。

2. Network-Friendly HTTP
NF是HTTP 2.0候選方案之一，主要提出以下改進：

對HTTP頭的名稱進行二進位編碼
對通用HTTP頭進行分組
請求/應答的多路復用
分層模型

NF同樣定義了幀和流，

3. WAKA
WAKA也是HTTP 2.0候選方案之一，是HTTP協議原作者Roy Fielding提出的一個提案。

WAKA支持多路復用，支持優先順序。WAKA提出了兩個新的HTTP方法，RENDER和MONITOR。

SPDY and Its Relation to WebSockets
http://britg.com/2012/03/15/spdy-and-its-relation-to-websockets/
SPDY is an augmentation to HTTP with the goal of making synchronous HTTP requests faster.
WebSockets is an alternative to HTTP with the goal of facilitating real time communication.

1. http的不足

OSI協議分為7層，目前主流TCP/IP分為4層。TCP/IP的最高層（應用層），隱式地需要實現會話層，表示層，應用層這三層的功能。（如果你認為OSI細分7層是有道理的話）。

對於HTTP協議來說，在TCP傳輸層上實現了端到端的連接之後，沒有進一步地將此通道復用的實現了。如果將HTTP協議看作OSI模型的第七層協議，它也確實沒有義務來實現將TCP傳輸層通道細分精分的。

如何高效率的利用一個傳輸層通道？
因為TCP的「三次握手」，「四次分手」，「慢啟動」等特性，HTTP的在某些使用場景下，響應速度會比較慢，而且由於HTTP固定的頭部帶了的傳輸開銷，所以可以在以下方面改善：
1，傳輸通道分成多個子通道，來標識不同的會話。
2，每個會話分離出多個事務（協議幀）。

HTTP協議本身的C-S模型，也限制了伺服器不能主動發起一個非同步請求。
所以SPDY協議在改善HTTP響應速度，傳輸效率，非同步方式，安全等方面，都做了改善，比如：
1. TCP層的多路復用。在一個TCP連接上，同時承載多個HTTP請求，並具有優先順序控制。
2. HTTP頭部壓縮，減少冗餘數據。同一個會話具有的某些固定的上下文信息，不必每次都通過無狀態的HTTP頭來傳輸。
3. 使用SSL作為傳輸層上的安全封裝。
4. 使用gzip壓縮數據。
5. 非同步模式， server可以主動發起請求，可以帶來更多的業務類型。