Web Sockets的目標是在一個單獨的持久連接上提供全雙工、雙向通信。在Javascript創(chuàng)建了Web Socket之后，會有一個HTTP請求發(fā)送到瀏覽器以發(fā)起連接。在取得服務(wù)器響應(yīng)后，建立的連接會將HTTP升級從HTTP協(xié)議交換為WebSocket協(xié)議。
由于WebSocket使用自定義的協(xié)議，所以URL模式也略有不同。未加密的連接不再是http://，而是ws://;加密的連接也不是https://，而是wss://。在使用WebSocket URL時，必須帶著這個模式，因為將來還有可能支持其他的模式。
使用自定義協(xié)議而非HTTP協(xié)議的好處是，能夠在客戶端和服務(wù)器之間發(fā)送非常少量的數(shù)據(jù)，而不必擔(dān)心HTTP那樣字節(jié)級的開銷。由于傳遞的數(shù)據(jù)包很小，所以WebSocket非常適合移動應(yīng)用。
上文中只是對Web Sockets進行了籠統(tǒng)的描述，接下來的篇幅會對Web Sockets的細節(jié)實現(xiàn)進行深入的探索，本文接下來的四個小節(jié)不會涉及到大量的代碼片段，但是會對相關(guān)的API和技術(shù)原理進行分析，相信大家讀完下文之后再來看這段描述，會有一種豁然開朗的感覺。
“握手通道”是HTTP協(xié)議中客戶端和服務(wù)端通過"TCP三次握手"建立的連接通道。客戶端和服務(wù)端使用HTTP協(xié)議進行的每次交互都需要先建立這樣一條“通道”，然后通過這條通道進行通信。我們熟悉的ajax交互就是在這樣一個通道上完成數(shù)據(jù)傳輸?shù)?，下面是HTTP協(xié)議中建立“握手通道”的過程示意圖：
上文中我們提到：在Javascript創(chuàng)建了WebSocket之后，會有一個HTTP請求發(fā)送到瀏覽器以發(fā)起連接，然后服務(wù)端響應(yīng)，這就是“握手“的過程，在這個握手的過程當中，客戶端和服務(wù)端主要做了兩件事情：
說到這里可能有人會問：HTTP協(xié)議為什么不復(fù)用自己的“握手通道”，而非要在每次進行數(shù)據(jù)交互的時候都通過TCP三次握手重新建立“握手通道”呢？答案是這樣的：雖然“長連接”在客戶端和服務(wù)端交互的過程中省去了每次都建立“握手通道”的麻煩步驟，但是維持這樣一條“長連接”是需要消耗服務(wù)器資源的，而在大多數(shù)情況下，這種資源的消耗又是不必要的，可以說HTTP標準的制定經(jīng)過了深思熟慮的考量。到我們后邊說到WebSocket協(xié)議數(shù)據(jù)幀時，大家可能就會明白，維持一條“持久連接”服務(wù)端和客戶端需要做的事情太多了。
說完了握手通道，我們再來看HTTP協(xié)議如何升級到WebSocket協(xié)議的。
升級協(xié)議需要客戶端和服務(wù)端交流，服務(wù)端怎么知道要將HTTP協(xié)議升級到WebSocket協(xié)議呢？它一定是接收到了客戶端發(fā)送過來的某種信號。下面是我從谷歌瀏覽器中截取的“客戶端發(fā)起協(xié)議升級請求的報文”，通過分析這段報文，我們能夠得到有關(guān)WebSocket中協(xié)議升級的更多細節(jié)。
首先，客戶端發(fā)起協(xié)議升級請求。采用的是標準的HTTP報文格式，且只支持GET方法。下面是重點請求的首部的意義：其中Connection就是我們前邊提到的，客戶端發(fā)送給服務(wù)端的信號，服務(wù)端接受到信號之后，才會對HTTP協(xié)議進行升級。那么服務(wù)端怎樣確認客戶端發(fā)送過來的請求是否是合法的呢？在客戶端每次發(fā)起協(xié)議升級請求的時候都會產(chǎn)生一個唯一碼：Sec-WebSocket-Key。服務(wù)端拿到這個碼后，通過一個算法進行校驗，然后通過Sec-WebSocket-Accept響應(yīng)給客戶端，客戶端再對Sec-WebSocket-Accept進行校驗來完成驗證。這個算法很簡單：
1.將Sec-WebSocket-Key跟全局唯一的（GUID，[RFC4122]）標識：258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接
2.通過SHA1計算出摘要，并轉(zhuǎn)成base64字符串
258EAFA5-E914-47DA-95CA-C5AB0DC85B11這個字符串又叫“魔串"，至于為什么要使用它作為Websocket握手計算中使用的字符串，這點我們無需關(guān)心，只需要知道它是RFC標準規(guī)定就可以了，官方的解析也只是簡單的說此值不大可能被不明白WebSocket協(xié)議的網(wǎng)絡(luò)終端使用。我們還是用世界上最好的語言來描述一下這個算法吧。
public function dohandshake($sock, $data, $key) { if (preg_match("/Sec-WebSocket-Key: (.*)\r\n/", $data, $match)) { $response = base64_encode(sha1($match[1] . '258EAFA5-E914-47DA-95CA-C5AB0DC85B11', true)); $upgrade = "HTTP/1.1 101 Switching Protocol\r\n" . "Upgrade: websocket\r\n" . "Connection: Upgrade\r\n" . "Sec-WebSocket-Accept: " . $response . "\r\n\r\n"; socket_write($sock, $upgrade, strlen($upgrade)); $this->isHand[$key] = true; } }服務(wù)端響應(yīng)客戶端的頭部信息和HTTP協(xié)議的格式是相同的，所以這里Sec-WebSocket-Accept字段后邊的兩個換行符是少不了的，這和我們使用curl工具模擬get請求是一個道理。這樣展示結(jié)果似乎不太直觀，我們使用命令行CLI來根據(jù)上圖中的Sec-WebSocket-Key和握手算法來計算一下服務(wù)端返回的Sec-WebSocket-Accept是否正確：
從圖中可以看到，通過算法算出來的base64字符串和Sec-WebSocket-Accept是一樣的。那么假如服務(wù)端在握手的過程中返回一個錯誤的Sec-WebSocket-Accept字符串會怎么樣呢？當然是客戶端會報錯，連接會建立失敗，大家最好嘗試一下，例如將全局唯一標識符258EAFA5-E914-47DA-95CA-C5AB0DC85B11改為258EAFA5-E914-47DA-95CA-C5AB0DC85B12。
下圖是我做的一個測試：將小說《飄》的第一章內(nèi)容復(fù)制成文本數(shù)據(jù)，通過客戶端發(fā)送到服務(wù)端，然后服務(wù)端響應(yīng)相同的信息完成了一次通信。
可以看到一篇足足有將近15000字節(jié)的數(shù)據(jù)在客戶端和服務(wù)端完成通信只用了150ms的時間。我們還可以清晰的看到瀏覽器控制臺中frame欄中顯示的客戶端發(fā)送和服務(wù)端響應(yīng)的文本數(shù)據(jù)，你一定驚訝WebSocket通信強大的數(shù)據(jù)傳輸能力。數(shù)據(jù)是否真的像frame中展示的那樣客戶端直接將一大篇文本數(shù)據(jù)發(fā)送到服務(wù)端，服務(wù)端接收到數(shù)據(jù)之后，再將一大篇文本數(shù)據(jù)返回給客戶端呢？這當然是不可能的，我們都知道HTTP協(xié)議是基于TCP實現(xiàn)的，HTTP發(fā)送數(shù)據(jù)也是分包轉(zhuǎn)發(fā)的，就是將大數(shù)據(jù)根據(jù)報文形式分割成一小塊一小塊發(fā)送到服務(wù)端,服務(wù)端接收到客戶端發(fā)送的報文后，再將小塊的數(shù)據(jù)拼接組裝。關(guān)于HTTP的分包策略，大家可以查看相關(guān)資料進行研究，websocket協(xié)議也是通過分片打包數(shù)據(jù)進行轉(zhuǎn)發(fā)的，不過策略上和HTTP的分包不一樣。frame（幀）是websocket發(fā)送數(shù)據(jù)的基本單位，下邊是它的報文格式：
服務(wù)端在接收到客戶端發(fā)送的幀消息的時候，將這些幀進行組裝，它怎么知道何時數(shù)據(jù)組裝完成的呢？這就是報文中左上角FIN(占一個比特)存儲的信息，1表示這是消息的最后一個分片（fragment)如果是0,表示不是消息的最后一個分片。websocket通信中，客戶端發(fā)送數(shù)據(jù)分片是有序的，這一點和HTTP不一樣，HTTP將消息分包之后，是并發(fā)無序的發(fā)送給服務(wù)端的，包信息在數(shù)據(jù)中的位置則在HTTP報文中存儲，而websocket僅僅需要一個FIN比特位就能保證將數(shù)據(jù)完整的發(fā)送到服務(wù)端。
接下來的RSV1,RSV2,RSV3三個比特位的作用又是什么呢？這三個標志位是留給客戶端開發(fā)者和服務(wù)端開發(fā)者開發(fā)過程中協(xié)商進行拓展的，默認是0。拓展如何使用必須在握手的階段就協(xié)商好，其實握手本身也是客戶端和服務(wù)端的協(xié)商。
Websocket是長連接，為了保持客戶端和服務(wù)端的實時雙向通信，需要確?？蛻舳撕头?wù)端之間的TCP通道保持連接沒有斷開。但是對于長時間沒有數(shù)據(jù)往來的連接，如果依舊保持著，可能會浪費服務(wù)端資源。但是不排除有些場景，客戶端和服務(wù)端雖然長時間沒有數(shù)據(jù)往來，仍然需要保持連接，就比如說你幾個月沒有和一個QQ好友聊天了，突然有一天他發(fā)QQ消息告訴你他要結(jié)婚了，你還是能在第一時間收到。那是因為，客戶端和服務(wù)端一直再采用心跳來檢查連接。客戶端和服務(wù)端的心跳連接檢測就像打乒乓球一樣：
等什么時候沒有ping、pong了，那么連接一定是存在問題了。
說了這么多，接下來我使用Go語言來實現(xiàn)一個心跳檢測，Websocket通信實現(xiàn)細節(jié)是一件繁瑣的事情，直接使用開源的類庫是比較不錯的選擇，我使用的是：gorilla/websocket。這個類庫已經(jīng)將websocket的實現(xiàn)細節(jié)（握手，數(shù)據(jù)解碼)封裝的很好啦。下面我就直接貼代碼了:
package mainimport ( "net/http" "time" "github.com/gorilla/websocket")var ( //完成握手操作 upgrade = websocket.Upgrader{ //允許跨域(一般來講,websocket都是獨立部署的) CheckOrigin:func(r *http.Request) bool { return true }, })func wsHandler(w http.ResponseWriter, r *http.Request) { var ( conn *websocket.Conn err error data []byte ) //服務(wù)端對客戶端的http請求(升級為websocket協(xié)議)進行應(yīng)答，應(yīng)答之后，協(xié)議升級為websocket，http建立連接時的tcp三次握手將保持。 if conn, err = upgrade.Upgrade(w, r, nil); err != nil { return } //啟動一個協(xié)程，每隔1s向客戶端發(fā)送一次心跳消息 go func() { var ( err error ) for { if err = conn.WriteMessage(websocket.TextMessage, []byte("heartbeat")); err != nil { return } time.Sleep(1 * time.Second) } }() //得到websocket的長鏈接之后,就可以對客戶端傳遞的數(shù)據(jù)進行操作了 for { //通過websocket長鏈接讀到的數(shù)據(jù)可以是text文本數(shù)據(jù)，也可以是二進制Binary if _, data, err = conn.ReadMessage(); err != nil { goto ERR } if err = conn.WriteMessage(websocket.TextMessage, data); err != nil { goto ERR } }ERR: //出錯之后，關(guān)閉socket連接 conn.Close()}func main() { http.HandleFunc("/ws", wsHandler) http.ListenAndServe("0.0.0.0:7777", nil)}借助go語言很容易搭建協(xié)程的特點，我專門開啟了一個協(xié)程每秒向客戶端發(fā)送一條消息。打開客戶端瀏覽器可以看到，frame中每秒的心跳數(shù)據(jù)一直在跳動，當長鏈接斷開之后，心跳就沒有了，就像人沒有了心跳一樣：
