很多场景下的应用对数据实时更新要求很高。比如股票交易，数字资产交易，还有一些需要动态更新数据的大屏数据可视化应用等等。在html5面世前，动态更新数据的做法大都是使用ajax轮询来实现，但是轮询的效率低，而且非常浪费资源（因为必须不断建立连接）。到目前websocket已经很受大家喜爱，也逐步替代了轮询的做法，使用websocket的场景也越来越多。下面就来详细介绍:
WebSocket简介
WebSocket 是 HTML5 新增的一种在单个 TCP 连接上进行全双工通讯的协议。诞生于2008年，在2011年成为国际标准。现在新版的所有浏览器都已经支持，但不兼容低版本的浏览器。
WebSocket的最大特点是：允许客户端和服务器之间进行全双工通信，以便任一方都可以通过建立的连接将数据推送到另一端，是真正的双向平等对话，属于服务器推送技术的一种。
在RFC6455 中定义了它的通信标准。
为什么需要 WebSocket ？
了解HTTP协议的童鞋应该都知道HTTP协议有以下两个突出的特性：
其一：HTTP协议的通信只能由客户端发起，它无法实现服务器主动向客户端推送消息（单向请求）。
其二：HTTP协议是一种无状态的应用层协议，它采用的是请求/响应模型。每次通信都需要携带验证信息进行身份校验（耗时、耗资源、效率低）。
WebSocket可以说是在HTTP的基础上发明来的，改善了HTTP协议上面的两个特性。WebSocket只需要建立一次HTTP连接，就可以一直保持连接状态（如果两端长时间都没有通信也是会被关闭连接的 - 后面会讲到），此时已经是从HTTP协议升级到了WebSocket协议，后面的通信都是基于websocket协议。这相比于轮询方式的不停建立连接显然效率要大大提高。
WebSocket如何工作？
Web浏览器和服务器都必须支持 WebSocket 协议来建立和维护连接。由于 WebSocket 连接长期存在，与典型的 HTTP 连接不同，对服务器有重要的影响。
基于多线程或多进程的服务器无法适用于 WebSocket，因为它旨在打开连接，尽可能快地处理请求，然后关闭连接。
客户端简单示例：
var ws = new WebSocket("ws://echo.websocket.org");
或者加密协议：
var ws = new WebSocket("wss://echo.websocket.org");
ws.onopen = function(evt) {
console.log("连接建立成功，可以开始通信了...");
ws.send("Hello WebSocket!");
};
ws.onerror = function(evt) {
console.log("连接出错 ...");
};
ws.onmessage = function(evt) {
console.log( "收到服务端消息: " + evt.data);
ws.close();
};
ws.onclose = function(evt) {
console.log("关闭连接 ...");
};
Websocket客户端 API
1、WebSocket 构造函数：
WebSocket 对象作为一个构造函数，用于新建 WebSocket 实例。
var webSocket = new WebSocket('ws://localhost:8080');
执行上面语句之后，客户端就会与服务器进行连接
2、webSocket.readyState
readyState属性返回实例对象的当前状态，共有四种：
CONNECTING：值为0，表示正在连接。
OPEN：值为1，表示连接成功，可以通信了。
CLOSING：值为2，表示连接正在关闭。
CLOSED：值为3，表示连接已经关闭，或者打开连接失败。
3、webSocket.bufferedAmount
bufferedAmount属性，表示还有多少字节的二进制数据没有发送出去。它可以用来判断发送是否结束
var data = new ArrayBuffer(10000000);
webSocket.send(data);
if (webSocket.bufferedAmount === 0) {
// 发送完毕
} else {
// 发送还没结束
}
4、webSocket.onopen
onopen属性，用于指定连接成功后的回调函数
webSocket.onopen = function () {
webSocket.send('Hello Server!');
}
webSocket.addEventListener('open', function (event) {
webSocket.send('Hello Server!');
});
5、webSocket.onclose
onclose属性，用于指定连接关闭后的回调函数
webSocket.onclose = function(event) {
var code = event.code;
var reason = event.reason;
var wasClean = event.wasClean;
// handle close event
};
webSocket.addEventListener("close", function(event) {
var code = event.code;
var reason = event.reason;
var wasClean = event.wasClean;
// handle close event
});
6、webSocket.onmessage
onmessage属性，用于指定收到服务器数据后的回调函数
webSocket.onmessage = function(event) {
var data = event.data;
// 处理数据
};
webSocket.addEventListener("message", function(event) {
var data = event.data;
// 处理数据
});
注意，服务器数据可能是文本，也可能是二进制数据（blob对象或Arraybuffer对象）
webSocket.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 数据
webSocket.binaryType = "blob";
webSocket.onmessage = function(e) {
console.log(e.data.size);
};
// 收到的是 ArrayBuffer 数据
webSocket.binaryType = "arraybuffer";
webSocket.onmessage = function(e) {
console.log(e.data.byteLength);
};
7、webSocket.onerror
onerror属性，用于指定报错时的回调函数
webSocket.onerror = function(event) {
// handle error event
};
webSocket.addEventListener("error", function(event) {
// handle error event
});
8、webSocket.send()
实例对象的send()方法用于向服务器发送数据
发送文本的例子
webSocket.send('your message');
发送 Blob 对象的例子。
var file = document.querySelector('input[type="file"]').files[0];
webSocket.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];
}
webSocket.send(binary.buffer);
9、webSocket.close()
实例对象的close()方法用于向服务器关闭连接
webSocket.close()
服务端如何实现？
WebSocket 在服务端的实现非常丰富。Node.js、Java、C++、Python 等多种语言都有自己的解决方案
常用的 Node 实现有以下三种：
WebSocket小结：
HTTP 和 WebSocket 有什么关系？
Websocket 其实是一个新的应用层协议，跟 HTTP 协议基本没有关系，只是为了兼容现有浏览器的握手规范而已，也就是说它是 HTTP 协议上的一种补充。
首先Websocket是基于HTTP协议的，或者说借用了HTTP的协议来完成一部分握手。
websocket握手阶段：
GET /chat 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==
Sec-WebSocket-Protocol: chat, superchat
Connection: Upgrade：表示要升级协议
Upgrade: websocket：表示要升级到websocket协议
Sec-WebSocket-Version: 13：表示websocket的版本。如果服务端不支持该版本，需要返回一个Sec-WebSocket-Version header，里面包含服务端支持的版本号
Sec-WebSocket-Key：是一个Base64 encode的值，这个是浏览器随机生成的，与后面服务端响应首部的Sec-WebSocket-Accept是配套的，提供基本的防护，比如恶意的连接，或者无意的连接
Sec-WebSocket-Protocol： 是一个用户定义的字符串，用来区分同URL下，不同的服务所需要的协议。
然后服务器会返回下列东西，表示已经接受到请求， 成功建立Websocket啦！
HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Accept: HSmrc0sMlYUkAGmm5OPpG2HaGWk=
Sec-WebSocket-Protocol: chat
这里开始就是HTTP最后负责的区域了，告诉客户，我已经成功切换协议啦~
Sec-WebSocket-Accept：这个则是经过服务器确认，根据客户端请求首部的Sec-WebSocket-Key计算出来的
计算公式为：
1、将Sec-WebSocket-Key跟258EAFA5-E914-47DA-95CA-C5AB0DC85B11拼接。
2、通过SHA1计算出摘要，并转成base64字符串
toBase64( sha1( Sec-WebSocket-Key + 258EAFA5-E914-47DA-95CA-C5AB0DC85B11 ) )
Sec-WebSocket-Protocol：则是表示最终使用的协议。
至此，http已经完成它所有工作了，接下来就是完全按照Websocket协议进行通信了。
Sec-WebSocket-Key/Sec-WebSocket-Accept的主要作用在于提供基础的防护，减少恶意连接、意外连接：
1、避免服务端收到非法的websocket连接（比如http客户端不小心请求连接websocket服务，此时服务端可以直接拒绝连接）
2、确保服务端理解websocket连接。因为ws握手阶段采用的是http协议，因此可能ws连接是被一个http服务器处理并返回的，此时客户端可以通过Sec-WebSocket-Key来确保服务端认识ws协议。（并非百分百保险，比如总是存在那么些无聊的http服务器，光处理Sec-WebSocket-Key，但并没有实现ws协议。。。）
3、用浏览器里发起ajax请求，设置header时，Sec-WebSocket-Key以及其他相关的header是被禁止的。这样可以避免客户端发送ajax请求时，意外请求协议升级（websocket upgrade）
4、可以防止反向代理（不理解ws协议）返回错误的数据。比如反向代理前后收到两次ws连接的升级请求，反向代理把第一次请求的返回给cache住，然后第二次请求到来时直接把cache住的请求给返回（无意义的返回）。
5、Sec-WebSocket-Key主要目的并不是确保数据的安全性，因为Sec-WebSocket-Key、Sec-WebSocket-Accept的转换计算公式是公开的，而且非常简单，最主要的作用是预防一些常见的意外情况（非故意的）。
强调：Sec-WebSocket-Key/Sec-WebSocket-Accept 的换算，只能带来基本的保障，但连接是否安全、数据是否安全、客户端/服务端是否合法的 ws客户端、ws服务端，其实并没有实际性的保证
websocket优点：
1、支持双向通信，实时性更强。
2、不用频繁送HTTP请求，只需要发送一个HTTP请求进行websocket握手，接下来则可以利用该TCP连接通过websocket协议通讯，避免了传输多个HTTP Header的浪费
3、支持传输文本和二进制。
4、websocket数据传输是基于数据帧的，可以分片传输，不需要怕数据太大包容纳不下。
5、支持扩展。ws协议定义了扩展，用户可以扩展协议，或者实现自定义的子协议。（比如支持自定义压缩算法等）
WebSocket客户端、服务端通信的最小单位是帧（frame），由1个或多个帧组成一条完整的消息（message）
websocket出现之前的一些持久连接操作：
1、长轮询：建立连接 -> 传输数据 -> 保持连接 -> 。。。-> 响应 -> 关闭连接
采取的是阻塞模型（一直打电话，没收到就不挂电话），也就是说，客户端发起连接后，如果没消息，就一直不返回Response给客户端。直到有消息才返回，返回完之后，客户端再次建立连接，周而复始。需要有很高的并发，也就是说同时接待客户的能力。（场地大小）服务器hold连接会消耗资源，返回数据顺序无保证，难于管理维护
2、ajax轮询：建立连接 -> 传输数据 -> 响应 -> 关闭连接 -> 定时循环上面的过程
定时向后台发请求，需要服务器有很快的处理速度和资源。（速度）请求中有大半是无用，浪费带宽和服务器资源
3、长连接：建立连接 -> 传输数据 -> 保持连接 -> 传输数据 -> 。。。 -> 关闭连接
http1.0默认进行短连接，通过使用Connection: keep-alive进行长连接，http1.1默认进行持久连接。在一次 TCP 连接中可以完成多个 http 请求，但是对每个请求仍然要单独发 header，keep-alive不会永久保持连接，它有一个保持时间，可以在不同的服务器软件（如Nginx\Apache）中设定这个时间。
启用keep-alive模式肯定更高效，性能更高。因为避免了建立/释放连接的开销
以上持久连接的缺点：
1、被动性 - 只能由客户端发送请求
2、在传统的方式上，要不断的建立和关闭连接，由于http是非状态性的，每次都要重新传输identity info（鉴别信息），来告诉服务端你是谁，解析耗时，耗资源，效率还低
3、http1.1串行单线程处理，响应是有顺序的，只有上一个请求完成后，下一个才能响应。一旦有任务处理超时等，后续任务只能被阻塞(线头阻塞)
4、keep-alive双方并没有建立正真的连接会话，服务端可以在任何一次请求完成后关闭
websocket长时间没有通信会自动断开的原因？
利用nginx代理websocket的时候，发现客户端和服务器握手成功后，如果在60s时间内没有数据交互，连接就会自动断开。
nginx.conf 文件里location 中的proxy_read_timeout 默认60s断开。
保持持久连接的做法：
1、把服务器的默认时间改大 + 发送心跳机制
2、定时检测客户端是否已经断开连接，断开重连
