Websocket详细讲解

因为websocket的内容比较多，所以准备分解将基础篇主要讨论一下websocket的概念，websocket和http协议的区别，客户端的websocket以及服务端的websocket，中间穿插着一些实例，最后以一个基本的实例还结束基础篇。扩展篇讨论一下nodejs中socket及其应用。下面我们就来进入正式话题

一、websocket的介绍
1.1 websocket概念
websocket是HTML5中新引进的一种协议，它是一种协议就像(HTTP,FTP在tcp/ip协议栈中属于应用层)而不是简单的一个函数。它本身及基于TCP协议的一种新的协议。

1.2 websocket的产生
websocket是基于web的实时性而产生的，说到这里就不得不要追溯一下web的历史了，在2005年(也就是ajax还没诞生)以前，我们如果想要在一个页面显示显示不同的内容，或者说页面内跳转，只能是通过点击然后路由跳转，在ajax诞生之后，网页开始变得动态了。但是所有的HTTP通信还都是由客户端控制的，这就要需要长连接，定期轮询或者流操作，来和服务器沟通来更新数据。下面来介绍一下这三种操作
☞定期轮询(ajax轮询)：浏览器在特定的时间给服务器发送请求，查看服务器是否有信息数据。情况类似下图：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KinQ8xR1-1613790190754)(http://www.woshinannan741.com/wp-content/uploads/2016/05/E3Q23MMEMAGLKXXO2V9X.png)]
☞长连接：其实和上面的原理差不多，是对ajax轮询进行了改进和提高。客户端和服务端建立连接之后，一直保持通信(阻塞模式)，如果服务器没有新消息就一直保持通信，知道服务器有新的消息，然后返回给客户端，客户端与服务器断开连接，此时客户端可以继续和服务器进行连接。情况类似图2：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cdnlrEql-1613790190756)(http://www.woshinannan741.com/wp-content/uploads/2016/05/D4GEAHDNES32LWAO2NN1.png)]
☞流操作：常就是在客户端的页面使用一个隐藏的窗口向服务端发出一个长连接的请求。服务器端接到这个请求后作出回应并不断更新连接状态以保证客户端和服务 器端的连接不过期。通过这种机制可以将服务器端的信息源源不断地推向客户端。[1]情况类似图三：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-cGTsRCGy-1613790190759)(http://www.woshinannan741.com/wp-content/uploads/2016/05/48P8A9YB5REGO11B1N.png)]
当然每一种新技术的兴起，都会引领一种潮流，就像05年ajax产生的前端大改革，正式那群有思想的人驱动了历史的改革，但是前浪终究会被拍在沙滩上，就像当今的ajax快被websocket替代了一样。
结合上面的解释我们来分析一下这三种方式缺点：
☛ajax轮询：这种方式带来了没必要的网络传输，是一种最低效的实时方案
☛长期轮询：虽然减少了无效的客户端和服务端的交互，但是数据更新频繁的时候效率并没有明显的增加
☛流操作：这种方式就不言而喻了，对服务器的资源是巨大的考验呀
这几种还是有一个共同的特点就是客户端是主动的，服务器是被动的这也不能说是个确定，但是在通信这方面如果服务器有资源就通知客户端这种模式还是为上上策呀，这就催生可websocket的产生：WebSocket通过浏览器提供的API真正实现了具备像C/S架构下的桌面系统的实时通讯能 力。其原理是使用JavaScript调用浏览器的API发出一个WebSocket请求至服务器，经过三次握手，和服务器建立了TCP通讯，因为它本质 上是一个TCP连接，所以数据传输的稳定性强和数据传输量比较小。[2]

1.3 websocket解决的问题
1.3.1 解决的持久性连接
JavaScript调用浏览器的API发出一个WebSocket请求至服务器，经过三次握手，和服务器建立了TCP通讯，因为它本质 上是一个TCP连接.
为什么要建立持久性连接呢？
这是因为HTTP协议是无状态的，简单来说就是穿了裤子就不认人了(连接断开之后就在也不知道刚才的客户端是谁了)。
websocket这就避免了HTTP的非状态性，服务端会一直知道你的信息，直到你关闭请求。

1.3.2 解决耗时和浪费资源
自从有了websocket现在的情况就变为了下图所示的情况：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-PVgoH9Jw-1613790190761)(http://www.woshinannan741.com/wp-content/uploads/2016/05/O2P@E8OB4P@O3QAO@DY2TP.png)]
只要经过一次HTTP请求当服务器的数据更新的时候，消息就能推送到了客户端，这个过程我们通常是通过回调函数是实现的。

1.3.3 服务器反客为主
当服务器充http进化为websocket时，服务端就可以主动推送信息给客户端啦。
这就实现了服务器的反客为主，客户端通过回调就能实时的捕捉到服务器传来的信息。
这样就解决了，客户端向服务器请求数据的时候收到503(服务器为找到)的返回码，也就是解决了下图的问题：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TGdofxl1-1613790190762)(http://www.woshinannan741.com/wp-content/uploads/2016/05/4VQNLI3I157OJ98GN1NVF.png)]

1.4 WebSocket 协议
上面BB了一大堆历史性的问题，下面来正式说一下websocket这个协议
WebSocket 协议本质上是一个基于 TCP 的协议。为了建立一个 WebSocket 连接，客户端浏览器首先要向服务器发起一个 HTTP 请求，这个请求和通常的 HTTP 请求不同，包含了一些附加头信息，其中附加头信息”Upgrade: WebSocket”表明这是一个申请协议升级的 HTTP 请求，服务器端解析这些附加的头信息然后产生应答信息返回给客户端，客户端和服务器端的 WebSocket 连接就建立起来了，双方就可以通过这个连接通道自由的传递信息，并且这个连接会持续存在直到客户端或者服务器端的某一方主动的关闭连接。

客户端发到服务器的内容：

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多了几个陌生的字段，我们来看http协议的的报文：

GET /socket.io/1/xhr-polling/oiO9akCJzXsaVw2GxyoO?t=1464277248268 HTTP/1.1\r\n
Host: s3-im-notify.csdn.net\r\n
Connection: keep-alive\r\n

当然一些太没有必要的字段就没有贴出免得占文章篇幅。
我看来看websocket多出的几个字段：
Upgrade: websocket表示这是一个特殊的 HTTP 请求，请求的目的就是要将客户端和服务器端的通讯协议从 HTTP 协议升级到 WebSocket 协议.
Sec-WebSocket-Key: 是一个Base64 encode的值，这个是浏览器随机生成,告诉服务器，我来验证一下你，是不是能和我进行websocket通信
Sec_WebSocket-Protocol:是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议
Sec-WebSocket-Version:告诉服务器所使用的协议版本
我们来看一下服务器给客户端返回的：

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
Sec-WebSocket-Protocol: chat

这里主要介绍一下Sec-WebSocket-Accept这个字段：经过服务器确认，并且加密过后的 Sec-WebSocket-Key。用来证明客户端和服务器之间能进行通信了。
这个会在后面深入讨论

1.5 websocket和http协议的关系
在1.4中已经介绍了http和websocket，
他们之间的关系可以用下图表示：
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ycSiThJO-1613790190763)(http://www.woshinannan741.com/wp-content/uploads/2016/05/1LW834AKTJ2D_ORF2.png)]
————————————————

在上一篇文章当中介绍了一下websocket是什么和产生原因以及和http协议的区别，我们今天来讨论一下websocket中的客户端和服务端程序。

1.websocket中的API
我们看一下就websocket JavaScript定义的接口：

[Constructor(in DOMString url, optional in DOMString protocol)]
interface WebSocket {
readonly attribute DOMString URL;
// ready state
const unsigned short CONNECTING = 0;
const unsigned short OPEN = 1;
const unsigned short CLOSED = 2;
readonly attribute unsigned short readyState;
readonly attribute unsigned long bufferedAmount;

// networking
attribute Function onopen;
attribute Function onmessage;
attribute Function onclose;
boolean send(in DOMString data);
void close();
};
WebSocket implements EventTarget;

既然是一个协议就是要有客户端和服务端，服务端每种语言有自己的API
websocket的作用已经完全可以代替ajax，客户端API和ajax十分相似下面我们来具体的介绍一下：

onopen，表示和服务器建立链接，建立连接之后才能进入下面的步骤，这个对应于ajaxopen方法
send，想用户服务器发送数据，对应于ajax的send方法
onmessage，建立连接之后，客户端收到服务器发来的数据，这个而对应ajax的responseText
onerror，当连接出现错误的时候，接收错误信息，这个ajax里面没有
onclose,监听消息的关闭，当连接结束的时候出发，这个ajax里面没有
close,主动关闭socket连接
再来介绍一下ready state表示的四种状态(ajax中是五种)
CONNECTING (0)：表示还没建立连接；
OPEN (1)： 已经建立连接，可以进行通讯；
CLOSING (2)：通过关闭握手，正在关闭连接；
CLOSED (3)：连接已经关闭或无法打开；
2.客户端的websocket
2.1 websocket实例
介绍完了API我们就要用这些API去做一些事情，下面我们通过一个实例来应用一下这些方法

var serverAddr = 'ws://localhost:3000';
// 创建一个Socket实例
var socket = new WebSocket(serverAddr);

// 打开Socket
socket.onopen = function(event) {

// 发送一个初始化消息
socket.send('I am the client and I\'m listening!');

// 监听消息
socket.onmessage = function(event) {
console.log('Client received a message',event);
};

// 监听Socket的关闭
socket.onclose = function(event) {
console.log('Client notified socket has closed',event);
};

// 关闭Socket....
//socket.close()
};
ar connection = new WebSocket('ws://html5rocks.websocket.org/echo', ['soap', 'xmpp']);
//第二个参数可接受可选子协议，它既可以是字符串，也可以是字符串数组。每个字符串都应代表一个子协议名称，而服务器只能接受数组中通过的一个子协议。访问 WebSocket 对象的 protocol 属性可确定接受的子协议。
1
2
通过上面的例子我们就在客户端建立了一个和服务器建立连接的程序，这种方法比ajax的好处我们也在前面说过了。下面我们来做一下对比顺便复习一下

序号 步骤 websocket ajax
1 创建对象 new WebSocket(serverUrl) $1600
2 和服务器建立连接 onopen open
2 向服务器发送数据 send send
3 监听服务器的信息 onmessage readyState，status
产生异常的应对机制 onerror 无，在jquery框架中有
监听连接关闭 onclose 没有，因为不是长连接
能否主动关闭 close 没有必要主动发起
在来看一下ready state的对比图：

状态值 websocket ajax
0 还没建立连接 还没建立连接
1 已经建立连接，可以进行通讯 请求已经建立，但是还没有发送
2 通过关闭握手，正在关闭连接 请求已发送，正在处理中
3 连接已经关闭或无法打开 请求在处理中；通常响应中已有部分数据可用了，但是服务器还没有完成响应的生成
4 无 响应已完成；您可以获取并使用服务器的响应了。
第一个对比中前面序号是ajax运行的四个步骤，但是少了第四步骤，第四个步骤是显示到相应的位置，在这里灭有过多去说，通过第二个对比我们可以看出在状态值中websocket和ajax有很大的区别，这还是因为http写一个websocket协议的不同。如果对这个几个步骤不清楚的可以看我的另一篇博文ajax全接触

2.1 socket.io
Socket.IO使用检测功能来判断是否建立WebSocket连接，或者是AJAX long-polling连接，或Flash等。可快速创建实时的应用程序。Socket.IO还提供了一个NodeJS API,
来看一个实例：

<script src="socket.io\node_modules\socket.io-client\socket.io.js"> </script>
<script>

var socket = io('http://localhost:3000');
socket.on('news', function (data) {
console.log(data);
socket.emit('my other event', { my: 'data' });
});
</script>

Socket.IO简化了WebSocket API，统一了返回运输的API。传输包括：

WebSocket
Flash Socket
AJAX long-polling
AJAX multipart streaming
IFrame
JSONP polling
你还可以设置任意的Socket.IO构造器的第二个选项，选项包括：
port - 待连接的端口
transports - 一个数组，包含不同的传输类型
transportOptions - 传输的参数使用的对象，带附加属性

Socket.IO还提供了由本地WebSocket API提供的普通连接、断开连接、消息事件。Socket还提供了封装每个事件类型的方法。
后续有机会我们继续讨论。

服务器的websocket
握手协议已经由客户端代码解决了，我们这里主要说服务器的程序，服务器程序我们在这里主要是用的nodejs使用其他语言的可以参考一下逻辑，因为nodejs的语法 和JavaScript一样都能 看懂。除了nodejs目前还有很多例如：

Kaazing WebSocket Gateway(一个 Java 实现的 WebSocket Server)
mod_pywebsocket(一个 Python 实现的 WebSocket Server)
Netty(一个 Java 实现的网络框架其中包括了对 WebSocket 的支持)
WebSocket4Net(一个.net的服务器端实现)
下一个考虑的问题：怎么握手呢？
还几个上一篇文章中客户端和服务端的协议栈图么，
其中客户端有一个：Sec-WebSocket-Key字段，服务器有一个：Sec-WebSocket-Accept字段，
服务器的Sec-WebSocket-Accept是由客户端的Sec-WebSocket-Key计算出来的，上一篇文章说Sec-WebSocket-Key是客户端随机产生的其实是不准确的，上一篇文章只是让大家了解这个字段，现在我们来看一下Sec-WebSocket-Key及产生过程：

取出Sec-WebSocket-Key(随机产生)，与一个magic string “258EAFA5-E914-47DA-95CA-C5AB0DC85B11” 连接成一个新的key串
将新的key串SHA1编码，生成一个由多组两位16进制数构成的加密串
把加密串进行base64编码生成最终的key，这个key就是Sec-WebSocket-Key
在考虑一个：怎么才算握手成功呢？
为了表示服务器同意和客户端进行Socket连接， 服务器端需要使用客户端发送的这个Key进行校验 ，然后返回一个校验过的字符串给客户端，客户端验证通过后才能正式建立Socket连接。
当握手成功之后会执行open方法。
这个过程可能以后会详细的解释。

我们再来看一下服务端的程序[1]：

var app = require('http').createServer(handler);
var io = require('socket.io')(app);
var fs = require('fs');
//监听端口
app.listen(3000);
//响应状态
function handler (req, res) {
//读取文件
fs.readFile(__dirname + '/index.html',
//读取异常，输出错误
function (err, data) {
if (err) {
res.writeHead(500);
return res.end('Error loading index.html');
}
//设置返回码
res.writeHead(200);
//结束时，输出返回信息
res.end(data);
});
}
//l建立连接
io.on('connection', function (socket) {
//返回数据
socket.emit('news', { hello: 'world' });
socket.on('my other event', function (data) {
console.log(data);
});
});

 

WebSocket 出现前

构建网络应用的过程中，我们经常需要与服务器进行持续的通讯以保持双方信息的同步。通常这种持久通讯在不刷新页面的情况下进行，消耗一定的内存资源常驻后台，并且对于用户不可见。在 WebSocket 出现之前，我们有以下解决方案：

传统轮询(Traditional Polling)

当前Web应用中较常见的一种持续通信方式，通常采取 setInterval 或者 setTimeout 实现。例如如果我们想要定时获取并刷新页面上的数据，可以结合Ajax写出如下实现：

setInterval(function() {
    $.get("/path/to/server", function(data, status) {
        console.log(data);
    });
}, 10000);

上面的程序会每隔10秒向服务器请求一次数据，并在数据到达后存储。这个实现方法通常可以满足简单的需求，然而同时也存在着很大的缺陷：在网络情况不稳定的情况下，服务器从接收请求、发送请求到客户端接收请求的总时间有可能超过10秒，而请求是以10秒间隔发送的，这样会导致接收的数据到达先后顺序与发送顺序不一致。于是出现了采用 setTimeout 的轮询方式：

function poll() {
    setTimeout(function() {
        $.get("/path/to/server", function(data, status) {
            console.log(data);
            // 发起下一次请求
            poll();
        });
    }, 10000);
}

程序首先设置10秒后发起请求，当数据返回后再隔10秒发起第二次请求，以此类推。这样的话虽然无法保证两次请求之间的时间间隔为固定值，但是可以保证到达数据的顺序。

长轮询(Long Polling)

上面两种传统的轮询方式都存在一个严重缺陷：程序在每次请求时都会新建一个HTTP请求，然而并不是每次都能返回所需的新数据。当同时发起的请求达到一定数目时，会对服务器造成较大负担。这时我们可以采用长轮询方式解决这个问题。

长轮询与以下将要提到的服务器发送事件和WebSocket不能仅仅依靠客户端JavaScript实现，我们同时需要服务器支持并实现相应的技术。

长轮询的基本思想是在每次客户端发出请求后，服务器检查上次返回的数据与此次请求时的数据之间是否有更新，如果有更新则返回新数据并结束此次连接，否则服务器 hold 住此次连接，直到有新数据时再返回相应。而这种长时间的保持连接可以通过设置一个较大的 HTTP timeout` 实现。下面是一个简单的长连接示例：

服务器（PHP）：

<?php
    // 示例数据为data.txt
    $filename= dirname(__FILE__)."/data.txt";
    // 从请求参数中获取上次请求到的数据的时间戳
    $lastmodif = isset( $_GET["timestamp"])? $_GET["timestamp"]: 0 ;
    // 将文件的最后一次修改时间作为当前数据的时间戳
    $currentmodif = filemtime($filename);

    // 当上次请求到的数据的时间戳*不旧于*当前文件的时间戳，使用循环"hold"住当前连接，并不断获取文件的修改时间
    while ($currentmodif <= $lastmodif) {
        // 每次刷新文件信息的时间间隔为10秒
        usleep(10000);
        // 清除文件信息缓存，保证每次获取的修改时间都是最新的修改时间
        clearstatcache();
        $currentmodif = filemtime($filename);
    }

    // 返回数据和最新的时间戳，结束此次连接
    $response = array();
    $response["msg"] =Date("h:i:s")." ".file_get_contents($filename);
    $response["timestamp"]= $currentmodif;
    echo json_encode($response);
?>

客户端：

function longPoll (timestamp) {
    var _timestamp;
    $.get("/path/to/server?timestamp=" + timestamp)
    .done(function(res) {
        try {
            var data = JSON.parse(res);
            console.log(data.msg);
            _timestamp = data.timestamp;
        } catch (e) {}
    })
    .always(function() {
        setTimeout(function() {
            longPoll(_timestamp || Date.now()/1000);
        }, 10000);
    });
}

长轮询可以有效地解决传统轮询带来的带宽浪费，但是每次连接的保持是以消耗服务器资源为代价的。尤其对于Apache+PHP 服务器，由于有默认的 worker threads 数目的限制，当长连接较多时，服务器便无法对新请求进行相应。

服务器发送事件(Server-Sent Event)

服务器发送事件（以下简称SSE）是HTML 5规范的一个组成部分，可以实现服务器到客户端的单向数据通信。通过 SSE ，客户端可以自动获取数据更新，而不用重复发送HTTP请求。一旦连接建立，“事件”便会自动被推送到客户端。服务器端SSE通过 事件流(Event Stream) 的格式产生并推送事件。事件流对应的 MIME类型 为 text/event-stream ，包含四个字段：event、data、id和retry。event表示事件类型，data表示消息内容，id用于设置客户端 EventSource 对象的 last event ID string 内部属性，retry指定了重新连接的时间。

服务器（PHP）：

<?php
    header("Content-Type: text/event-stream");
    header("Cache-Control: no-cache");
    // 每隔1秒发送一次服务器的当前时间
    while (1) {
        $time = date("r");
        echo "event: ping\n";
        echo "data: The server time is: {$time}\n\n";
        ob_flush();
        flush();
        sleep(1);
    }
?>

客户端中，SSE借由 EventSource 对象实现。EventSource 包含五个外部属性：onerror, onmessage, onopen, readyState、url，以及两个内部属性：reconnection time与 last event ID string。在onerror属性中我们可以对错误捕获和处理，而 onmessage 则对应着服务器事件的接收和处理。另外也可以使用 addEventListener 方法来监听服务器发送事件，根据event字段区分处理。

客户端：

var eventSource = new EventSource("/path/to/server");
eventSource.onmessage = function (e) {
    console.log(e.event, e.data);
}
// 或者
eventSource.addEventListener("ping", function(e) {
    console.log(e.event, e.data);
}, false);

SSE相较于轮询具有较好的实时性，使用方法也非常简便。然而SSE只支持服务器到客户端单向的事件推送，而且所有版本的IE（包括到目前为止的Microsoft Edge）都不支持SSE。如果需要强行支持IE和部分移动端浏览器，可以尝试 EventSource Polyfill（本质上仍然是轮询）。SSE的浏览器支持情况如下图所示：

对比

>>>>>>>>>>>>	传统轮询	长轮询	服务器发送事件	WebSocket
浏览器支持	几乎所有现代浏览器	几乎所有现代浏览器	Firefox 6+ Chrome 6+ Safari 5+ Opera 10.1+	IE 10+ Edge Firefox 4+ Chrome 4+ Safari 5+ Opera 11.5+
服务器负载	较少的CPU资源，较多的内存资源和带宽资源	与传统轮询相似，但是占用带宽较少	与长轮询相似，除非每次发送请求后服务器不需要断开连接	无需循环等待（长轮询），CPU和内存资源不以客户端数量衡量，而是以客户端事件数衡量。四种方式里性能最佳。
客户端负载	占用较多的内存资源与请求数。	与传统轮询相似。	浏览器中原生实现，占用资源很小。	同Server-Sent Event。
延迟	非实时，延迟取决于请求间隔。	同传统轮询。	非实时，默认3秒延迟，延迟可自定义。	实时。
实现复杂度	非常简单。	需要服务器配合，客户端实现非常简单。	需要服务器配合，而客户端实现甚至比前两种更简单。	需要Socket程序实现和额外端口，客户端实现简单。

WebSocket 是什么

WebSocket 协议在2008年诞生，2011年成为国际标准。所有浏览器都已经支持了。

WebSocket同样是HTML 5规范的组成部分之一，现标准版本为 RFC 6455。WebSocket 相较于上述几种连接方式，实现原理较为复杂，用一句话概括就是：客户端向 WebSocket 服务器通知（notify）一个带有所有 接收者ID（recipients IDs） 的事件（event），服务器接收后立即通知所有活跃的（active）客户端，只有ID在接收者ID序列中的客户端才会处理这个事件。由于 WebSocket 本身是基于TCP协议的，所以在服务器端我们可以采用构建 TCP Socket 服务器的方式来构建 WebSocket 服务器。

这个 WebSocket 是一种全新的协议。它将 TCP 的 Socket（套接字）应用在了web page上，从而使通信双方建立起一个保持在活动状态连接通道，并且属于全双工（双方同时进行双向通信）。

其实是这样的，WebSocket 协议是借用 HTTP协议 的 101 switch protocol 来达到协议转换的，从HTTP协议切换成WebSocket通信协议。

它的最大特点就是，服务器可以主动向客户端推送信息，客户端也可以主动向服务器发送信息，是真正的双向平等对话，属于服务器推送技术的一种。其他特点包括：

• 建立在 TCP 协议之上，服务器端的实现比较容易。
• 与 HTTP 协议有着良好的兼容性。默认端口也是 80 和 443 ，并且握手阶段采用 HTTP 协议，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。
• 数据格式比较轻量，性能开销小，通信高效。
• 可以发送文本，也可以发送二进制数据。
• 没有同源限制，客户端可以与任意服务器通信。
• 协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

协议

WebSocket协议被设计来取代现有的使用HTTP作为传输层的双向通信技术，并受益于现有的基础设施（代理、过滤、身份验证）。

概述

本协议有两部分：握手和数据传输。

来自客户端的握手看起来像如下形式：

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

来自客户端的首行遵照 Request-Line 格式。 来自服务器的首行遵照 Status-Line 格式。

Request-Line 和 Status-Line 制品定义在 RFC2616。

一旦客户端和服务器都发送了它们的握手，且如果握手成功，接着开始数据传输部分。 这是一个每一端都可以的双向通信信道，彼此独立，随意发生数据。

一个成功握手之后，客户端和服务器来回地传输数据，在本规范中提到的概念单位为“消息”。 在线路上，一个消息是由一个或多个帧的组成。 WebSocket 的消息并不一定对应于一个特定的网络层帧，可以作为一个可以被一个中间件合并或分解的片段消息。

一个帧有一个相应的类型。 属于相同消息的每一帧包含相同类型的数据。 从广义上讲，有文本数据类型（它被解释为 UTF-8 RFC3629文本）、二进制数据类型（它的解释是留给应用）、和控制帧类型（它是不准备包含用于应用的数据，而是协议级的信号，例如应关闭连接的信号）。这个版本的协议定义了六个帧类型并保留10以备将来使用。

握手

客户端：申请协议升级

首先，客户端发起协议升级请求。可以看到，采用的是标准的 HTTP 报文格式，且只支持GET方法。

GET / HTTP/1.1
Host: localhost:8080
Origin: http://127.0.0.1:3000
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Version: 13
Sec-WebSocket-Key: w4v7O6xFTi36lq3RNcgctw==

重点请求首部意义如下：

• Connection: Upgrade：表示要升级协议
• Upgrade: websocket：表示要升级到 websocket 协议。
• Sec-WebSocket-Version: 13：表示 websocket 的版本。如果服务端不支持该版本，需要返回一个 Sec-WebSocket-Versionheader ，里面包含服务端支持的版本号。
• Sec-WebSocket-Key：与后面服务端响应首部的 Sec-WebSocket-Accept 是配套的，提供基本的防护，比如恶意的连接，或者无意的连接。

服务端：响应协议升级

服务端返回内容如下，状态代码101表示协议切换。到此完成协议升级，后续的数据交互都按照新的协议来。

HTTP/1.1 101 Switching Protocols
Connection:Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: Oy4NRAQ13jhfONC7bP8dTKb4PTU=

Sec-WebSocket-Accept

Sec-WebSocket-Accept 根据客户端请求首部的 Sec-WebSocket-Key 计算出来。

计算公式为：

将 Sec-WebSocket-Key 跟 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 拼接。

通过 SHA1 计算出摘要，并转成 base64 字符串。

伪代码如下：

>toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 )  )

数据帧

WebSocket 客户端、服务端通信的最小单位是 帧（frame），由 1 个或多个帧组成一条完整的 消息（message）。

• 发送端：将消息切割成多个帧，并发送给服务端；
• 接收端：接收消息帧，并将关联的帧重新组装成完整的消息；

数据帧格式概览

用于数据传输部分的报文格式是通过本节中详细描述的 ABNF 来描述。

下面给出了 WebSocket 数据帧的统一格式。熟悉 TCP/IP 协议的同学对这样的图应该不陌生。

从左到右，单位是比特。比如 FIN、RSV1各占据 1 比特，opcode占据 4 比特。

内容包括了标识、操作代码、掩码、数据、数据长度等。

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-------+-+-------------+-------------------------------+
 |F|R|R|R| opcode|M| Payload len |    Extended payload length    |
 |I|S|S|S|  (4)  |A|     (7)     |             (16/64)           |
 |N|V|V|V|       |S|             |   (if payload len==126/127)   |
 | |1|2|3|       |K|             |                               |
 +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - +
 |     Extended payload length continued, if payload len == 127  |
 + - - - - - - - - - - - - - - - +-------------------------------+
 |                               |Masking-key, if MASK set to 1  |
 +-------------------------------+-------------------------------+
 | Masking-key (continued)       |          Payload Data         |
 +-------------------------------- - - - - - - - - - - - - - - - +
 :                     Payload Data continued ...                :
 + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
 |                     Payload Data continued ...                |
 +---------------------------------------------------------------+

数据帧格式详解

针对前面的格式概览图，这里逐个字段进行讲解，如有不清楚之处，可参考协议规范，或留言交流。

FIN：1 个比特。

如果是 1，表示这是 消息（message）的最后一个分片（fragment），如果是 0，表示不是是 消息（message）的最后一个 分片（fragment）。

RSV1, RSV2, RSV3：各占 1 个比特。

一般情况下全为 0。当客户端、服务端协商采用 WebSocket 扩展时，这三个标志位可以非 0，且值的含义由扩展进行定义。如果出现非零的值，且并没有采用 WebSocket 扩展，连接出错。

Opcode: 4 个比特。

操作代码，Opcode 的值决定了应该如何解析后续的 数据载荷（data payload）。如果操作代码是不认识的，那么接收端应该 断开连接（fail the connection）。可选的操作代码如下：

• %x0：表示一个延续帧。当 Opcode 为 0 时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。
• %x1：表示这是一个文本帧（frame）
• %x2：表示这是一个二进制帧（frame）
• %x3-7：保留的操作代码，用于后续定义的非控制帧。
• %x8：表示连接断开。
• %x8：表示这是一个 ping 操作。
• %xA：表示这是一个 pong 操作。
• %xB-F：保留的操作代码，用于后续定义的控制帧。

Mask: 1 个比特。

表示是否要对数据载荷进行掩码操作。从客户端向服务端发送数据时，需要对数据进行掩码操作；从服务端向客户端发送数据时，不需要对数据进行掩码操作。

如果服务端接收到的数据没有进行过掩码操作，服务端需要断开连接。

如果 Mask 是 1，那么在 Masking-key 中会定义一个 掩码键（masking key），并用这个掩码键来对数据载荷进行反掩码。所有客户端发送到服务端的数据帧，Mask 都是 1。

Payload length：数据载荷的长度

单位是字节。为 7 位，或 7+16 位，或 1+64 位。

假设数 Payload length === x，如果

• x 为 0~126：数据的长度为 x 字节。
• x 为 126：后续 2 个字节代表一个 16 位的无符号整数，该无符号整数的值为数据的长度。
• x 为 127：后续 8 个字节代表一个 64 位的无符号整数（最高位为 0），该无符号整数的值为数据的长度。

此外，如果 payload length 占用了多个字节的话，payload length 的二进制表达采用 网络序（big endian，重要的位在前）。

Masking-key：0 或 4 字节（32 位）

所有从客户端传送到服务端的数据帧，数据载荷都进行了掩码操作，Mask 为 1，且携带了 4 字节的 Masking-key。如果 Mask 为 0，则没有 Masking-key。

备注：载荷数据的长度，不包括 mask key 的长度。

Payload data：(x+y) 字节

载荷数据：包括了扩展数据、应用数据。其中，扩展数据 x 字节，应用数据 y 字节。

扩展数据：如果没有协商使用扩展的话，扩展数据数据为 0 字节。所有的扩展都必须声明扩展数据的长度，或者可以如何计算出扩展数据的长度。此外，扩展如何使用必须在握手阶段就协商好。如果扩展数据存在，那么载荷数据长度必须将扩展数据的长度包含在内。

应用数据：任意的应用数据，在扩展数据之后（如果存在扩展数据），占据了数据帧剩余的位置。载荷数据长度 减去 扩展数据长度，就得到应用数据的长度。

掩码算法

掩码键（Masking-key）是由客户端挑选出来的 32 位的随机数。掩码操作不会影响数据载荷的长度。掩码、反掩码操作都采用如下算法：

首先，假设：

• original-octet-i：为原始数据的第 i 字节。
• transformed-octet-i：为转换后的数据的第 i 字节。
• j：为i mod 4的结果。
• masking-key-octet-j：为 mask key 第 j 字节。

算法描述为： original-octet-i 与 masking-key-octet-j 异或后，得到 transformed-octet-i。

j  = i MOD 4
transformed-octet-i = original-octet-i XOR masking-key-octet-j

数据传递

一旦 WebSocket 客户端、服务端建立连接后，后续的操作都是基于数据帧的传递。

WebSocket 根据 opcode 来区分操作的类型。比如0x8表示断开连接，0x0-0x2 表示数据交互。

数据分片

WebSocket 的每条消息可能被切分成多个数据帧。当 WebSocket 的接收方收到一个数据帧时，会根据FIN的值来判断，是否已经收到消息的最后一个数据帧。

FIN=1 表示当前数据帧为消息的最后一个数据帧，此时接收方已经收到完整的消息，可以对消息进行处理。FIN=0，则接收方还需要继续监听接收其余的数据帧。

此外，opcode 在数据交换的场景下，表示的是数据的类型。0x01表示文本，0x02表示二进制。而0x00比较特殊，表示延续帧（continuation frame），顾名思义，就是完整消息对应的数据帧还没接收完。

连接保持 + 心跳

WebSocket 为了保持客户端、服务端的实时双向通信，需要确保客户端、服务端之间的 TCP 通道保持连接没有断开。然而，对于长时间没有数据往来的连接，如果依旧长时间保持着，可能会浪费包括的连接资源。

但不排除有些场景，客户端、服务端虽然长时间没有数据往来，但仍需要保持连接。这个时候，可以采用心跳来实现。

• 发送方 ->接收方：ping
• 接收方 ->发送方：pong

ping、pong 的操作，对应的是 WebSocket 的两个控制帧，opcode分别是 0x9、0xA。

关闭连接

一旦发送或接收到一个Close控制帧，这就是说，_WebSocket 关闭阶段握手已启动，且 WebSocket 连接处于 CLOSING 状态。

当底层TCP连接已关闭，这就是说 WebSocket连接已关闭 且 WebSocket 连接处于 CLOSED 状态。 如果 TCP 连接在 WebSocket 关闭阶段已经完成后被关闭，WebSocket连接被说成已经 完全地 关闭了。

如果WebSocket连接不能被建立，这就是说，WebSocket连接关闭，但不是 完全的 。

状态码

当关闭一个已经建立的连接（例如，当在打开阶段握手已经完成后发送一个关闭帧），端点可以表明关闭的原因。 由端点解释这个原因，并且端点应该给这个原因采取动作，本规范是没有定义的。 本规范定义了一组预定义的状态码，并指定哪些范围可以被扩展、框架和最终应用使用。 状态码和任何相关的文本消息是关闭帧的可选的组件。

当发送关闭帧时端点可以使用如下预定义的状态码。

状态码	名称	描述
0–999		保留段, 未使用.
1000	CLOSE_NORMAL	正常关闭; 无论为何目的而创建, 该链接都已成功完成任务.
1001	CLOSE_GOING_AWAY	终端离开, 可能因为服务端错误, 也可能因为浏览器正从打开连接的页面跳转离开.
1002	CLOSE_PROTOCOL_ERROR	由于协议错误而中断连接.
1003	CLOSE_UNSUPPORTED	由于接收到不允许的数据类型而断开连接 (如仅接收文本数据的终端接收到了二进制数据).
1004		保留. 其意义可能会在未来定义.
1005	CLOSE_NO_STATUS	保留.  表示没有收到预期的状态码.
1006	CLOSE_ABNORMAL	保留. 用于期望收到状态码时连接非正常关闭 (也就是说, 没有发送关闭帧).
1007	Unsupported Data	由于收到了格式不符的数据而断开连接 (如文本消息中包含了非 UTF-8 数据).
1008	Policy Violation	由于收到不符合约定的数据而断开连接. 这是一个通用状态码, 用于不适合使用 1003 和 1009 状态码的场景.
1009	CLOSE_TOO_LARGE	由于收到过大的数据帧而断开连接.
1010	Missing Extension	客户端期望服务器商定一个或多个拓展, 但服务器没有处理, 因此客户端断开连接.
1011	Internal Error	客户端由于遇到没有预料的情况阻止其完成请求, 因此服务端断开连接.
1012	Service Restart	服务器由于重启而断开连接.
1013	Try Again Later	服务器由于临时原因断开连接, 如服务器过载因此断开一部分客户端连接.
1014		由 WebSocket 标准保留以便未来使用.
1015	TLS Handshake	保留. 表示连接由于无法完成 TLS 握手而关闭 (例如无法验证服务器证书).
1016–1999		由 WebSocket 标准保留以便未来使用.
2000–2999		由 WebSocket 拓展保留使用.
3000–3999		可以由库或框架使用.不应由应用使用. 可以在 IANA 注册, 先到先得.
4000–4999		可以由应用使用.

客户端的 API

WebSocket 构造函数

WebSocket 对象提供了用于创建和管理 WebSocket 连接，以及可以通过该连接发送和接收数据的 API。

WebSocket 构造器方法接受一个必须的参数和一个可选的参数：

WebSocket WebSocket(in DOMString url, in optional DOMString protocols);
WebSocket WebSocket(in DOMString url,in optional DOMString[] protocols);

参数

• url

表示要连接的URL。这个URL应该为响应WebSocket的地址。

• protocols 可选

可以是一个单个的协议名字字符串或者包含多个协议名字字符串的数组。这些字符串用来表示子协议，这样做可以让一个服务器实现多种 WebSocket子协议（例如你可能希望通过制定不同的协议来处理不同类型的交互）。如果没有制定这个参数，它会默认设为一个空字符串。

构造器方法可能抛出以下异常：SECURITY_ERR 试图连接的端口被屏蔽。

var ws = new WebSocket('ws://localhost:8080');

执行上面语句之后，客户端就会与服务器进行连接。

属性

属性名	类型	描述
binaryType	DOMString	一个字符串表示被传输二进制的内容的类型。取值应当是"blob"或者"arraybuffer"。"blob"表示使用DOM Blob 对象，而"arraybuffer"表示使用 ArrayBuffer 对象。
bufferedAmount	unsigned long	调用 send()) 方法将多字节数据加入到队列中等待传输，但是还未发出。该值会在所有队列数据被发送后重置为 0。而当连接关闭时不会设为0。如果持续调用send()，这个值会持续增长。只读。
extensions	DOMString	服务器选定的扩展。目前这个属性只是一个空字符串，或者是一个包含所有扩展的列表。
onclose	EventListener	用于监听连接关闭事件监听器。当 WebSocket 对象的readyState 状态变为 CLOSED 时会触发该事件。这个监听器会接收一个叫close的 CloseEvent 对象。
onerror	EventListener	当错误发生时用于监听error事件的事件监听器。会接受一个名为“error”的event对象。
onmessage	EventListener	一个用于消息事件的事件监听器，这一事件当有消息到达的时候该事件会触发。这个Listener会被传入一个名为"message"的 MessageEvent 对象。
onopen	EventListener	一个用于连接打开事件的事件监听器。当readyState的值变为 OPEN 的时候会触发该事件。该事件表明这个连接已经准备好接受和发送数据。这个监听器会接受一个名为"open"的事件对象。
protocol	DOMString	一个表明服务器选定的子协议名字的字符串。这个属性的取值会被取值为构造器传入的protocols参数。
readyState	unsigned short	连接的当前状态。取值是 Ready state constants 之一。 只读。
url	DOMString	传入构造器的URL。它必须是一个绝对地址的URL。只读。

webSocket.onopen

实例对象的 onopen 属性，用于指定连接成功后的回调函数。

ws.onopen = function () {
  ws.send('Hello Server!');
}

如果要指定多个回调函数，可以使用addEventListener方法。

ws.addEventListener('open', function (event) {
  ws.send('Hello Server!');
});

webSocket.onclose

实例对象的 onclose 属性，用于指定连接关闭后的回调函数。

ws.onclose = function(event) {
  var code = event.code;
  var reason = event.reason;
  var wasClean = event.wasClean;
  // handle close event
};

ws.addEventListener("close", function(event) {
  var code = event.code;
  var reason = event.reason;
  var wasClean = event.wasClean;
  // handle close event
});

webSocket.onmessage

实例对象的 onmessage 属性，用于指定收到服务器数据后的回调函数。

ws.onmessage = function(event) {
  var data = event.data;
  // 处理数据
};

ws.addEventListener("message", function(event) {
  var data = event.data;
  // 处理数据
});

注意，服务器数据可能是文本，也可能是 二进制数据（blob对象或Arraybuffer对象）。

ws.onmessage = function(event){
  if(typeof event.data === String) {
    console.log("Received data string");
  }

  if(event.data instanceof ArrayBuffer){
    var buffer = event.data;
    console.log("Received arraybuffer");
  }
}

除了动态判断收到的数据类型，也可以使用 binaryType 属性，显式指定收到的二进制数据类型。

// 收到的是 blob 数据
ws.binaryType = "blob";
ws.onmessage = function(e) {
  console.log(e.data.size);
};

// 收到的是 ArrayBuffer 数据
ws.binaryType = "arraybuffer";
ws.onmessage = function(e) {
  console.log(e.data.byteLength);
};

常量

Ready state 常量

这些常量是 readyState 属性的取值，可以用来描述 WebSocket 连接的状态。

常量	值	描述
CONNECTING	0	连接还没开启。
OPEN	1	连接已开启并准备好进行通信。
CLOSING	2	连接正在关闭的过程中。
CLOSED	3	连接已经关闭，或者连接无法建立。

方法

close()

关闭 WebSocket 连接或停止正在进行的连接请求。如果连接的状态已经是 closed，这个方法不会有任何效果

void close(in optional unsigned short code, in optional DOMString reason);

code 可选

一个数字值表示关闭连接的状态号，表示连接被关闭的原因。如果这个参数没有被指定，默认的取值是1000 （表示正常连接关闭）。 请看 CloseEvent 页面的 list of status codes来看默认的取值。

reason 可选

一个可读的字符串，表示连接被关闭的原因。这个字符串必须是不长于123字节的UTF-8 文本（不是字符）。

可能抛出的异常

• INVALID_ACCESS_ERR：选定了无效的code。
• SYNTAX_ERR：reason 字符串太长或者含有 unpaired surrogates。

send()

通过 WebSocket 连接向服务器发送数据。

void send(in DOMString data);
void send(in ArrayBuffer data);
void send(in Blob data); 

data：要发送到服务器的数据。

可能抛出的异常：

• INVALID_STATE_ERR：当前连接的状态不是OPEN。
• SYNTAX_ERR：数据是一个包含 unpaired surrogates 的字符串。

发送文本的例子。

ws.send('your message');

发送 Blob 对象的例子。

var file = document
  .querySelector('input[type="file"]')
  .files[0];
ws.send(file);

发送 ArrayBuffer 对象的例子。

// Sending canvas ImageData as ArrayBuffer
var img = canvas_context.getImageData(0, 0, 400, 320);
var binary = new Uint8Array(img.data.length);
for (var i = 0; i < img.data.length; i++) {
  binary[i] = img.data[i];
}
ws.send(binary.buffer);

服务端的实现

WebSocket 服务器的实现，可以查看维基百科的列表。

常用的 Node 实现有以下三种。

• Socket.IO
• µWebSockets
• WebSocket-Node

问答

和TCP、HTTP协议的关系

WebSocket 是基于 TCP 的独立的协议。它与 HTTP 唯一的关系是它的握手是由 HTTP 服务器解释为一个 Upgrade 请求。

WebSocket协议试图在现有的 HTTP 基础设施上下文中解决现有的双向HTTP技术目标；同样，它被设计工作在HTTP端口80和443，也支持HTTP代理和中间件，

HTTP服务器需要发送一个“Upgrade”请求，即101 Switching Protocol到HTTP服务器，然后由服务器进行协议转换。

Sec-WebSocket-Key/Accept 的作用

前面提到了，Sec-WebSocket-Key/Sec-WebSocket-Accept 在主要作用在于提供基础的防护，减少恶意连接、意外连接。

作用大致归纳如下：

避免服务端收到非法的 websocket 连接（比如 http 客户端不小心请求连接 websocket 服务，此时服务端可以直接拒绝连接）

确保服务端理解 websocket 连接。因为 ws 握手阶段采用的是 http 协议，因此可能 ws 连接是被一个 http 服务器处理并返回的，此时客户端可以通过 Sec-WebSocket-Key 来确保服务端认识 ws 协议。（并非百分百保险，比如总是存在那么些无聊的 http 服务器，光处理 Sec-WebSocket-Key，但并没有实现 ws 协议。。。）

用浏览器里发起 ajax 请求，设置 header 时，Sec-WebSocket-Key 以及其他相关的 header 是被禁止的。这样可以避免客户端发送 ajax 请求时，意外请求协议升级（websocket upgrade）

可以防止反向代理（不理解 ws 协议）返回错误的数据。比如反向代理前后收到两次 ws 连接的升级请求，反向代理把第一次请求的返回给 cache 住，然后第二次请求到来时直接把 cache 住的请求给返回（无意义的返回）。

Sec-WebSocket-Key 主要目的并不是确保数据的安全性，因为 Sec-WebSocket-Key、Sec-WebSocket-Accept 的转换计算公式是公开的，而且非常简单，最主要的作用是预防一些常见的意外情况（非故意的）。

数据掩码的作用

WebSocket 协议中，数据掩码的作用是增强协议的安全性。但数据掩码并不是为了保护数据本身，因为算法本身是公开的，运算也不复杂。除了加密通道本身，似乎没有太多有效的保护通信安全的办法。

那么为什么还要引入掩码计算呢，除了增加计算机器的运算量外似乎并没有太多的收益（这也是不少同学疑惑的点）。

答案还是两个字：安全。但并不是为了防止数据泄密，而是为了防止早期版本的协议中存在的代理缓存污染攻击（proxy cache poisoning attacks）等问题