1、從 http 協議說起

1996年IETF  HTTP工作組發布了HTTP協議的1.0版本 ，到現在普遍使用的版本1.1，HTTP協議經歷了17 年的發展。這種分布式、無狀態、基于TCP的請求/響應式、在互聯網盛行的今天得到廣泛應用的協議，相對于互聯網的迅猛發展，它似乎進步地很慢。互聯網從興起到現在，經歷了門戶網站盛行的web1.0時代，而后隨著ajax技術的出現，發展為web應用盛行的web2.0時代，如今又朝著web3.0的方向邁進。反觀http協議，從版本1.0發展到1.1，除了默認長連接之外就是緩存處理、帶寬優化和安全性等方面的不痛不癢的改進。它一直保留著無狀態、請求/響應模式，似乎從來沒意識到這應該有所改變。

2、Ajax 腳本發送的 http 請求

傳統的web應用要想與服務器交互，必須提交一個表單（form），服務器接收并處理傳來的表單，然后返回全新的頁面，因為前后兩個頁面的數據大部分都是相同的，這個過程傳輸了很多冗余的數據、浪費了帶寬。于是Ajax技術便應運而生。

Ajax是Asynchronous JavaScript and 的簡稱，由Jesse James Garrett 首先提出。這種技術開創性地允許瀏覽器腳本（JS）發送http請求。Outlook Web Access小組于98年使用，并很快成為IE4.0的一部分，但是這個技術一直很小眾，直到2005年初，google在他的goole groups、gmail等交互式應用中廣泛使用此種技術，才使得Ajax迅速被大家所接受。

Ajax的出現使客戶端與服務器端傳輸數據少了很多，也快了很多，也滿足了以豐富用戶體驗為特點的web2.0時代 初期發展的需要，但是慢慢地也暴露了他的弊端。比如無法滿足即時通信等富交互式應用的實時更新數據的要求。這種瀏覽器端的小技術畢竟還是基于http協議，http協議要求的請求/響應的模式也是無法改變的，除非http協議本身有所改變。

3、Comet  一種 hack 技術

以即時通信為代表的web應用程序對數據的Low Latency要求，傳統的基于輪詢的方式已經無法滿足，而且也會帶來不好的用戶體驗。于是一種基于http長連接的“服務器推”技術便被hack出來。這種技術被命名為Comet，這個術語由Dojo Toolkit 的項目主管Alex Russell在博文Comet: Low Latency Data for the Browser首次提出，并沿用下來。

其實，服務器推很早就存在了，在經典的client/server模型中有廣泛使用，只是瀏覽器太懶了，并沒有對這種技術提供很好的支持。但是Ajax的出現使這種技術在瀏覽器上實現成為可能， google的gmail和gtalk的整合首先使用了這種技術。隨著一些關鍵問題的解決（比如 IE 的加載顯示問題），很快這種技術得到了認可，目前已經有很多成熟的開源Comet框架。

以下是典型的Ajax和Comet數據傳輸方式的對比，區別簡單明了。典型的Ajax通信方式也是http協議的經典使用方式，要想取得數據，必須首先發送請求。在Low Latency要求比較高的web應用中，只能增加服務器請求的頻率。Comet則不同，客戶端與服務器端保持一個長連接，只有客戶端需要的數據更新時，服務器才主動將數據推送給客戶端。

Comet 的實現主要有兩種方式：

【1】基于 Ajax 的長輪詢（long-polling）方式

瀏覽器發出

【2】基于 Iframe 及 htmlfile 的流（http streaming）方式

Iframe是html標記，這個標記的src屬性會保持對指定服務器的長連接請求，服務器端則可以不停地返回數據，相對于第一種方式，這種方式跟傳統的服務器推則更接近。

在第一種方式中，瀏覽器在收到數據后會直接調用JS回調函數，但是這種方式該如何響應數據呢？可以通過在返回數據中嵌入JS腳本的方式，如“<script type="text/javascript">js_func(“data from server ”)</script>”，服務器端將返回的數據作為回調函數的參數，瀏覽器在收到數據后就會執行這段JS腳本。

但是這種方式有一個明顯的不足之處：IE、Morzilla Firefox 下端的進度欄都會顯示加載沒有完成，而且 IE 上方的圖標會不停的轉動，表示加載正在進行。Google 的天才們使用一個稱為“htmlfile”的 ActiveX 解決了在 IE 中的加載顯示問題，并將這種方法應用到了 gmail+gtalk 產品中。

4、Websocket 未來的解決方案

如果說 Ajax 的出現是互聯網發展的必然，那么 Comet 技術的出現則更多透露出一種無奈，僅僅作為一種 hack 技術，因為沒有更好的解決方案。Comet 解決的問題應該由誰來解決才是合理的呢？瀏覽器，html 標準，還是 http 標準？主角應該是誰呢？本質上講，這涉及到數據傳輸方式，http協議應首當其沖，是時候改變一下這個懶惰的協議的請求/響應模式了。

W3C 給出了答案，在新一代 html 標準 html5 中提供了一種瀏覽器和服務器間進行全雙工通訊的網絡技術 Websocket。從 Websocket 草案得知，Websocket 是一個全新的、獨立的協議，基于TCP協議，與http協議兼容、卻不會融入http協議，僅僅作為html5的一部分。于是乎腳本又被賦予了另一種能力：發起 websocket 請求。這種方式我們應該很熟悉，因為 Ajax 就是這么做的，所不同的是，Ajax 發起的是 http 請求而已。 

與http協議不同的請求/響應模式不同，Websocket 在建立連接之前有一個 Handshake（Opening Handshake）過程，在關閉連接前也有一個 Handshake（Closing Handshake）過程，建立連接之后，雙方即可雙向通信。

【1】Opening Handshake

客戶端發起連接 Handshake 請求：

　　GET /chat HTTP/1.1

        Host: server.example.com

        Upgrade: websocket

        Connection: Upgrade

        Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==

        Origin: http://example.com

        Sec-WebSocket-Protocol: chat, superchat

        Sec-WebSocket-Version: 13

服務器端響應：

        HTTP/1.1 101 Switching Protocols

        Upgrade: websocket

        Connection: Upgrade

        Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=

        Sec-WebSocket-Protocol: chat

“Upgrade：WebSocket”  表示這是一個特殊的 HTTP 請求，請求的目的就是要將客戶端和服務器端的通訊協議從 HTTP 協議升級到 WebSocket 協議。

“Sec-WebSocket-Key” 是一段瀏覽器 base64 加密的密鑰

“Sec-WebSocket-Accept” 服務器端在接收到的Sec-WebSocket-Key密鑰后追加一段神奇字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，并將結果進行sha-1哈希，然后再進行base64加密返回給客戶端。

“Sec-WebSocket-Protocol” 表示客戶端請求提供的可供選擇的子協議，及服務器端選中的支持的子協議，“Origin” 服務器端用于區分未授權的websocket瀏覽器

“HTTP/1.1 101 Switching Protocols”中101 為服務器返回的狀態碼，所有非101的狀態碼都表示handshake并未完成。

【2】Data Framing

Websocket 協議通過序列化的數據包傳輸數據。數據封包協議中定義了 opcode、payload length、Payload data 等字段。具體封包格式如下圖所示：

FIN: 標識是否為此消息的最后一個數據包，占 1 bit

RSV1, RSV2, RSV3:  用于擴展協議，一般為0，各占1bit

Opcode：數據包類型（frame type），占4bits

         0x0：標識一個中間數據包

         0x1：標識一個text類型數據包

         0x2：標識一個binary類型數據包

         0x3-7：保留

         0x8：標識一個斷開連接類型數據包

         0x9：標識一個ping類型數據包

         0xA：表示一個pong類型數據包

         0xB-F：保留

Payload length：Payload data的長度，占7bits，如果這個值等于126，則此后16bits用于表示Payload length，如果這個值等于127，則此后64bits用于表示Payload length

Payload data：應用層數據

【3】Closing Handshake

相對于 Opening Handshake，Closing Handshake 則簡單得多，主動關閉的一方向另一方發送一個關閉類型的數據包，對方收到此數據包之后，再回復一個相同類型的數據包，關閉完成。

關閉類型數據包遵守封包協議，Opcode為 0x8，Payload data 可以用于攜帶關閉原因或消息。 

雖然現階段 websocket 協議還處于草案階段，不過瀏覽器早就開始開始支持了，以下是不同瀏覽器兼容列表：

從瀏覽器支持角度來看，Websocket 還有很長的路要走，特別是在中國這個IE6依然盛行的國家，即便在 Websocket 標準化之后，舊版本瀏覽器的消亡也需要很長一段時間，因此現階段 comet 依然是最好的解決方案。

原文鏈接：http://www.shaoqun.com/a/54588.html