首先我們看一下websocket的出現(xiàn)背景，我們知道http系列協(xié)議是建立在tcp上的，理論上，他是可以可以雙向通信的。但是http1.1之前，服務(wù)器沒有實(shí)現(xiàn)推送的功能。每次都是客戶端請求，服務(wù)器響應(yīng)。下面看一下http協(xié)議關(guān)于請求處理的發(fā)展。

1. http1.0的時(shí)候，一個(gè)http請求的生命周期是客戶端發(fā)起請求，服務(wù)器響應(yīng)，斷開連接。但是我們知道tcp協(xié)議的缺點(diǎn)就是，三次握手需要時(shí)間，再加上慢開始等特性，每一個(gè)http請求都這樣的話，效率就很低。

2. http1.1的時(shí)候，默認(rèn)開啟了長連接（客戶端請求中設(shè)置了keep-alive頭），服務(wù)器處理一個(gè)請求后，不會(huì)立刻關(guān)閉連接，而是會(huì)等待一定的時(shí)間。如果沒有請求才關(guān)閉連接。這樣瀏覽器不僅可以在一個(gè)tcp連接中，不斷地發(fā)送請求（服務(wù)器也會(huì)限制一個(gè)連接上可以處理的請求閾值），甚至可以一次發(fā)很多個(gè)請求。這就是http1.1的管道化（pipeline）技術(shù)。但是他也有個(gè)問題，因?yàn)閷τ诨趆ttp協(xié)議的客戶端來說，雖然他可以發(fā)很多請求出去，但是當(dāng)一個(gè)請求對于的回包回來時(shí)，他卻無法分辨是屬于哪個(gè)請求的。所以回包只能按請求順序返回，這就引來了另一個(gè)問題-線頭阻塞(Head-of-Link Blocking)。并且http1.1雖然支持長連接，但是他不支持服務(wù)端推送（push）的能力。如果服務(wù)器有數(shù)據(jù)要給客戶端，也只能等著客戶端來?。╬ull）。

3. 來到了http2.0，不僅實(shí)現(xiàn)了服務(wù)器推送，還使用了幀（iframe），流（stream）等技術(shù)解決了線頭阻塞的問題，http2.0在一個(gè)tcp連接中，可以同時(shí)發(fā)送多個(gè)http請求，每個(gè)請求是一個(gè)流，一個(gè)流可以分成很多幀，有了標(biāo)記號(hào)，服務(wù)器可以隨便發(fā)送回包，客戶端收到后，根據(jù)標(biāo)記，重新組裝就可以。

   以上是http協(xié)議的關(guān)于請求的一些發(fā)展，而websocket就服務(wù)端推送提供了另外一種解決方案。他本質(zhì)上是在tcp協(xié)議上封裝的另一種應(yīng)用層協(xié)議（websocket協(xié)議）。因?yàn)樗腔趖cp的，所以服務(wù)端推送自然不是什么難題。但是在實(shí)現(xiàn)上，他并不是直接連接一個(gè)tcp連接，然后在上面?zhèn)鬏敾趙ebsocket協(xié)議的數(shù)據(jù)包。他涉及到一個(gè)協(xié)議升級(jí)（交換）的過程。我們看看這個(gè)過程。

1 客戶端發(fā)送協(xié)議升級(jí)的請求。在http請求加上下面的http頭

Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits
Sec-WebSocket-Key: k1kbxGRqGIBD5Y/LdIFwGQ==
Sec-WebSocket-Version: 13
Upgrade: websocket

2 服務(wù)器如果支持websocket協(xié)議的話，會(huì)返回101狀態(tài)碼表示同意協(xié)議升級(jí)，并且支持各種配置（如果服務(wù)器不支持某些功能或版本，或告訴客戶端，客戶端可以再次發(fā)送協(xié)議升級(jí)的請求）。服務(wù)會(huì)返回形如下面的http頭（可以參考websocket協(xié)議)。

Connection: Upgrade
Sec-WebSocket-Accept: y73KZR4t+hqD6KKYbkx2tULfBsQ=
Upgrade: websocket

3 這樣就完成了協(xié)議的升級(jí)，后續(xù)的數(shù)據(jù)通信，就是基于tcp連接之上，使用websocket協(xié)議封裝的數(shù)據(jù)包。

下面我們通過wireshark來了解這個(gè)過程。首先我們啟動(dòng)一個(gè)服務(wù)器（ip：192.168.8.226）。

var http = require('http');
var fs = require('fs');
const WebSocket = require('ws');
// 如果在瀏覽器控制臺(tái)進(jìn)行測試，可以不起http服務(wù)器
const server = http.createServer(options,function(req,res){
    res.end(fs.readFileSync(`${__dirname}/websocket.html`));
}).listen(11111);

const wss = new WebSocket.Server({ server }); 
wss.on('connection', function connection(ws) {
  ws.on('message', function(message) {
    ws.send(message);
  });

  ws.send('get it');
});

我們可以直接在瀏覽器控制臺(tái)進(jìn)行測試

var ws = new WebSocket("ws://192.168.8.226:11111");
// 連接上后執(zhí)行
ws.send(11)

這時(shí)候，我們看看wireshark的包。

 

 

 

 

 

 

 

 

 

 

我們再來看看安全版本的websocket。我們啟動(dòng)一個(gè)https服務(wù)器。

var https = require('https');
var fs = require('fs');
const WebSocket = require('ws');

var options = {
    key: fs.readFileSync('./server-key.pem'),
    ca: [fs.readFileSync('./ca-cert.pem')],
    cert: fs.readFileSync('./server-cert.pem')
};

const server = https.createServer(options,function(req,res){
    res.end(fs.readFileSync(`${__dirname}/websocket.html`));
}).listen(11111);

const wss = new WebSocket.Server({ server });

wss.on('connection', function connection(ws) {
  ws.on('message', function(message) {
    ws.send(message);
  });
});

然后在瀏覽器控制臺(tái)執(zhí)行。

var ws = new WebSocket("wss://192.168.8.226:11111");
ws.sned(11);

然后來看看wireshark。

 

經(jīng)過一系列的分析，我們對websocket協(xié)議應(yīng)該有了更多的了解，最后再說一個(gè)關(guān)于websocket的點(diǎn)。我們發(fā)現(xiàn)如果在websocket連接上，一直不通信的話，websocket連接所維持的時(shí)間是依賴tcp實(shí)現(xiàn)的。因?yàn)槲覀儼l(fā)現(xiàn)tcp層會(huì)一直發(fā)送探測包。達(dá)到閾值之后，連接就會(huì)被斷開。所以我們想維持websocket連接的話，需要自己去發(fā)送心跳包，比如ping，pong。

總結(jié)：本文分析了websocket的基本原理，但不涉及協(xié)議的內(nèi)容，如需了解協(xié)議的內(nèi)容，可以參考rfc文檔。