本文将从基本概念、技术原理、常见易错常识、动手实践等多个方面入手，万字长文，带你一起全方位探索 WebSocket 技术。
阅读完本文，你将了解以下内容：
作者网名：阿宝哥
个人博客：全栈修仙之路
作者Github：semlinker (阿宝哥) · GitHub
常见的轮询方式分为轮询与长轮询，它们的区别如下图所示：
为了更加直观感受轮询与长轮询之间的区别，我们来看一下具体的代码：
这种传统的模式带来很明显的缺点，即浏览器需要不断的向服务器发出请求，然而 HTTP 请求与响应可能会包含较长的头部，其中真正有效的数据可能只是很小的一部分，所以这样会消耗很多带宽资源。
PS：关于短轮询、长轮询技术的前世今身，可以详细读这两篇：《新手入门贴：史上最全Web端即时通讯技术原理详解》、《Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》。
比较新的轮询技术是 Comet。这种技术虽然可以实现双向通信，但仍然需要反复发出请求。而且在 Comet 中普遍采用的 HTTP 长连接也会消耗服务器资源。
在这种情况下，HTML5 定义了 WebSocket 协议，能更好的节省服务器资源和带宽，并且能够更实时地进行通讯。
Websocket 使用 ws 或 wss 的统一资源标志符（URI），其中 wss 表示使用了 TLS 的 Websocket。
如：
WebSocket 与 HTTP 和 HTTPS 使用相同的 TCP 端口，可以绕过大多数防火墙的限制。
默认情况下：
WebSocket 使得客户端和服务器之间的数据交换变得更加简单，允许服务端主动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只需要完成一次握手，两者之间就可以创建持久性的连接，并进行双向数据传输。
XHR Polling与 WebSocket 之间的区别如下图所示：
普遍认为，WebSocket的优点有如下几点：
由于 WebSocket 拥有上述的优点，所以它被广泛地应用在即时通讯/IM、实时音视频、在线教育和游戏等领域。
对于前端开发者来说，要想使用 WebSocket 提供的强大能力，就必须先掌握 WebSocket API，下面带大家一起来认识一下 WebSocket API。
PS：如果你想要更浅显的WebSocket入门教程，可以先读这篇《新手快速入门：WebSocket简明教程》后，再回来继续学习。
在介绍 WebSocket API 之前，我们先来了解一下它的兼容性：
由上图可知：目前主流的 Web 浏览器都支持 WebSocket，所以我们可以在大多数项目中放心地使用它。
在浏览器中要使用 WebSocket 提供的能力，我们就必须先创建 WebSocket 对象，该对象提供了用于创建和管理 WebSocket 连接，以及可以通过该连接发送和接收数据的 API。
使用 WebSocket 构造函数，我们就能轻易地构造一个 WebSocket 对象。
接下来我们将从以下四个方面来介绍 WebSocket API：
接下来我们从 WebSocket 的构造函数入手开始学习。
PS：如果你想要更浅显的WebSocket入门教程，可以先读这篇《新手快速入门：WebSocket简明教程》后，再回来继续学习。
WebSocket 构造函数的语法为：
const myWebSocket = newWebSocket(url [, protocols]);
针对第2）点：这些字符串用于指定子协议，这样单个服务器可以实现多个 WebSocket 子协议。
比如：你可能希望一台服务器能够根据指定的协议（protocol）处理不同类型的交互。如果不指定协议字符串，则假定为空字符串。
使用WebSocket 构造函数时，当尝试连接的端口被阻止时，会抛出 SECURITY_ERR 异常。
PS：有关WebSocket构造函数的更详细说明，可以参见官方API文档。
WebSocket 对象包含以下属性：
每个属性的具体含义如下：
WebSocket 主要方法有两个：
使用 addEventListener() 或将一个事件监听器赋值给 WebSocket 对象的 oneventname 属性，来监听下面的事件。
以下是几个事件：
介绍完 WebSocket API，我们来举一个使用 WebSocket 发送普通文本的示例。
在以上示例中：我们在页面上创建了两个 textarea，分别用于存放 待发送的数据 和 服务器返回的数据。当用户输入完待发送的文本之后，点击 发送 按钮时会把输入的文本发送到服务端，而服务端成功接收到消息之后，会把收到的消息原封不动地回传到客户端。
当然客户端接收到服务端返回的消息之后，会把对应的文本内容保存到 接收的数据 对应的 textarea 文本框中。
为了更加直观地理解上述的数据交互过程，我们使用 Chrome 浏览器的开发者工具来看一下相应的过程。
如下图所示：
以上示例对应的完整代码如下所示：
其实 WebSocket 除了支持发送普通的文本之外，它还支持发送二进制数据，比如 ArrayBuffer 对象、Blob 对象或者 ArrayBufferView 对象。
代码示例如下：
以上代码成功运行后，通过 Chrome 开发者工具，我们可以看到对应的数据交互过程。
如下图所示：
下面以发送 Blob 对象为例，来介绍一下如何发送二进制数据。
Blob（Binary Large Object）表示二进制类型的大对象。在数据库管理系统中，将二进制数据存储为一个单一个体的集合。Blob 通常是影像、声音或多媒体文件。在 JavaScript 中 Blob 类型的对象表示不可变的类似文件对象的原始数据。
在以上示例中，我们在页面上创建了两个 textarea，分别用于存放 待发送的数据 和 服务器返回的数据。
当用户输入完待发送的文本之后，点击 发送 按钮时，我们会先获取输入的文本并把文本包装成 Blob 对象然后发送到服务端，而服务端成功接收到消息之后，会把收到的消息原封不动地回传到客户端。
当浏览器接收到新消息后，如果是文本数据，会自动将其转换成 DOMString 对象，如果是二进制数据或 Blob 对象，会直接将其转交给应用，由应用自身来根据返回的数据类型进行相应的处理。
数据发送代码：
当客户端接收到服务端返回的消息之后，会判断返回的数据类型，如果是 Blob 类型的话，会调用 Blob 对象的 text() 方法，获取 Blob 对象中保存的 UTF-8 格式的内容，然后把对应的文本内容保存到 接收的数据 对应的 textarea 文本框中。
数据接收代码：
同样，我们使用 Chrome 浏览器的开发者工具来看一下相应的过程：
通过上图我们可以很明显地看到，当使用发送 Blob 对象时，Data 栏位的信息显示的是 Binary Message，而对于发送普通文本来说，Data 栏位的信息是直接显示发送的文本消息。
以上示例对应的完整代码如下所示：
可能有一些小伙伴了解完 WebSocket API 之后，觉得还不够过瘾。下面将带大家来实现一个支持发送普通文本的 WebSocket 服务器。
在介绍如何手写 WebSocket 服务器前，我们需要了解一下 WebSocket 连接的生命周期。
从上图可知：在使用 WebSocket 实现全双工通信之前，客户端与服务器之间需要先进行握手（Handshake），在完成握手之后才能开始进行数据的双向通信。
握手是在通信电路创建之后，信息传输开始之前。
握手用于达成参数，如：
握手有助于不同结构的系统或设备在通信信道中连接，而不需要人为设置参数。
既然握手是 WebSocket 连接生命周期的第一个环节，接下来我们就先来分析 WebSocket 的握手协议。
WebSocket 协议属于应用层协议，它依赖于传输层的 TCP 协议。WebSocket 通过 HTTP/1.1 协议的 101 状态码进行握手。为了创建 WebSocket 连接，需要通过浏览器发出请求，之后服务器进行回应，这个过程通常称为 “握手”（Handshaking）。
利用 HTTP 完成握手有几个好处：
下面我们以前面已经演示过的发送普通文本的例子为例，来具体分析一下握手过程。
5.2.1）客户端请求：
备注：已忽略部分 HTTP 请求头。
针对上述请求中的字段说明如下：
针对上述第4）点：把 “Sec-WebSocket-Key” 加上一个特殊字符串 “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，然后计算 SHA-1 摘要，之后进行 Base64 编码，将结果做为 “Sec-WebSocket-Accept” 头的值，返回给客户端。如此操作，可以尽量避免普通 HTTP 请求被误认为 WebSocket 协议。
5.2.2）服务端响应：
HTTP/1.1 101 Web Socket Protocol Handshake ①Connection: Upgrade ②Upgrade: websocket ③Sec-WebSocket-Accept: 52Rg3vW4JQ1yWpkvFlsTsiezlqw= ④
备注：已忽略部分 HTTP 响应头。
针对上述响应中的字段说明如下：
具体代码如下所示：
当服务器接收到升级为 WebSocket 的握手请求时，会先从请求头中获取 “Sec-WebSocket-Key” 的值，然后把该值加上一个特殊字符串 “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，然后计算 SHA-1 摘要，之后进行 Base64 编码，将结果做为 “Sec-WebSocket-Accept” 头的值，返回给客户端。
代码如下：
开发完握手功能之后，我们可以使用前面的示例来测试一下该功能。待服务器启动之后，我们只要对 “发送普通文本” 示例，做简单地调整，即把先前的 URL 地址替换成 ws://localhost:8888，就可以进行功能验证。
感兴趣的小伙们可以试试看，以下是我的本地运行后的结果：
从上图可知：我们实现的握手功能已经可以正常工作了。那么握手有没有可能失败呢？答案是肯定的。比如网络问题、服务器异常或 Sec-WebSocket-Accept 的值不正确。
下面来改一下 “Sec-WebSocket-Accept” 生成规则，比如修改 MAGIC_KEY 的值，然后重新验证一下握手功能。
此时，浏览器的控制台会输出以下异常信息：
WebSocket connection to 'ws://localhost:8888/'failed: Error during WebSocket handshake: Incorrect 'Sec-WebSocket-Accept'header value
如果你的 WebSocket 服务器要支持子协议的话，你可以参考以下代码进行子协议的处理，这里就不继续展开介绍了。
在 WebSocket 协议中，数据是通过一系列数据帧来进行传输的。
为了避免由于网络中介（例如一些拦截代理）或者一些安全问题，客户端必须在它发送到服务器的所有帧中添加掩码。服务端收到没有添加掩码的数据帧以后，必须立即关闭连接。
5.4.1）数据帧格式：
要实现消息通信，我们就必须了解 WebSocket 数据帧的格式：
可能有一些小伙伴看到上面的内容之后，就开始有点 “懵逼” 了。
下面我们来结合实际的数据帧来进一步分析一下：
在上图中：简单分析了 “发送普通文本” 示例对应的数据帧格式。这里我们来进一步介绍一下 Payload length，因为在后面开发数据解析功能的时候，需要用到该知识点。
Payload length 表示以字节为单位的 “有效负载数据” 长度。
它有以下几种情形：
备注：多字节长度量以网络字节顺序表示，有效负载长度是指 “扩展数据” + “应用数据” 的长度。“扩展数据” 的长度可能为 0，那么有效负载长度就是 “应用数据” 的长度。
另外：除非协商过扩展，否则 “扩展数据” 长度为 0 字节。在握手协议中，任何扩展都必须指定 “扩展数据” 的长度，这个长度如何进行计算，以及这个扩展如何使用。如果存在扩展，那么这个 “扩展数据” 包含在总的有效负载长度中。
PS：关于数据帧格式的详细讲解，可以深入读读以下几篇：
5.4.2）掩码算法：
掩码字段是一个由客户端随机选择的 32 位的值。掩码值必须是不可被预测的。因此，掩码必须来自强大的熵源（entropy），并且给定的掩码不能让服务器或者代理能够很容易的预测到后续帧。掩码的不可预测性对于预防恶意应用的作者在网上暴露相关的字节数据至关重要。
掩码不影响数据荷载的长度，对数据进行掩码操作和对数据进行反掩码操作所涉及的步骤是相同的。
掩码、反掩码操作都采用如下算法：
j = i MOD 4transformed-octet-i = original-octet-i XOR masking-key-octet-j
解释一下：
为了让小伙伴们能够更好的理解上面掩码的计算过程，我们来对示例中 “我是阿宝哥” 数据进行掩码操作。
这里 “我是阿宝哥” 对应的 UTF-8 编码如下所示：
E6 88 91 E6 98 AF E9 98 BF E5 AE 9D E5 93 A5
而对应的 Masking-Key 为 0x08f6efb1。
根据上面的算法，我们可以这样进行掩码运算：
以上代码成功运行后，控制台会输出以下结果：
ee 7e 7e 57 90 59 6 29 b7 13 41 2c ed 65 4a
上述结果与 WireShark 中的 Masked payload 对应的值是一致的，具体如下图所示：
在 WebSocket 协议中，数据掩码的作用是增强协议的安全性。但数据掩码并不是为了保护数据本身，因为算法本身是公开的，运算也不复杂。
那么为什么还要引入数据掩码呢？引入数据掩码是为了防止早期版本的协议中存在的代理缓存污染攻击等问题。
了解完 WebSocket 掩码算法和数据掩码的作用之后，我们再来介绍一下数据分片的概念。
5.4.3）数据分片：
WebSocket 的每条消息可能被切分成多个数据帧。当 WebSocket 的接收方收到一个数据帧时，会根据 FIN 的值来判断，是否已经收到消息的最后一个数据帧。
利用 FIN 和 Opcode，我们就可以跨帧发送消息。
操作码告诉了帧应该做什么：
Client: FIN=1, opcode=0x1, msg="hello"Server: (process complete message immediately) Hi.Client: FIN=0, opcode=0x1, msg="and a"Server: (listening, newmessage containing text started)Client: FIN=0, opcode=0x0, msg="happy new"Server: (listening, payload concatenated to previous message)Client: FIN=1, opcode=0x0, msg="year!"Server: (process complete message) Happy newyear to you too!
在以上示例中：客户端向服务器发送了两条消息，第一个消息在单个帧中发送，而第二个消息跨三个帧发送。
其中：第一个消息是一个完整的消息（FIN=1 且 opcode != 0x0)，因此服务器可以根据需要进行处理或响应。而第二个消息是文本消息（opcode=0x1）且 FIN=0，表示消息还没发送完成，还有后续的数据帧。该消息的所有剩余部分都用延续帧（opcode=0x0）发送，消息的最终帧用 FIN=1 标记。
笔者把实现消息通信功能，分解为消息解析与消息响应两个子功能，下面我们分别来介绍如何实现这两个子功能。
5.5.1）消息解析：
利用消息通信基础环节中介绍的相关知识，我实现了一个 parseMessage 函数，用来解析客户端传过来的 WebSocket 数据帧。
出于简单考虑，这里只处理文本帧，具体代码如下所示：
创建完 parseMessage 函数，我们来更新一下之前创建的 WebSocket 服务器：
更新完成之后，我们重新启动服务器，然后继续使用 “发送普通文本” 的示例来测试消息解析功能。
以下发送 “我是阿宝哥” 文本消息后，WebSocket 服务器输出的信息：
通过观察以上的输出信息，我们的 WebSocket 服务器已经可以成功解析客户端发送包含普通文本的数据帧，下一步我们来实现消息响应的功能。
5.5.2）消息响应：
要把数据返回给客户端，我们的 WebSocket 服务器也得按照 WebSocket 数据帧的格式来封装数据。
与前面介绍的 parseMessage 函数一样，我也封装了一个 constructReply 函数用来封装返回的数据。
该函数的具体代码如下：
创建完 constructReply 函数，我们再来更新一下之前创建的 WebSocket 服务器：
到这里，我们的 WebSocket 服务器已经开发完成了，接下来我们来完整验证一下它的功能。
从上图中可知：以上开发的简易版 WebSocket 服务器已经可以正常处理普通文本消息了。
最后我们来看一下完整的代码。
其实服务器向浏览器推送信息，除了使用 WebSocket 技术之外，还可以使用 SSE（Server-Sent Events）。它让服务器可以向客户端流式发送文本消息，比如服务器上生成的实时消息。
为实现这个目标，SSE 设计了两个组件：浏览器中的 EventSource API 和新的 “事件流” 数据格式（text/event-stream）。其中，EventSource 可以让客户端以 DOM 事件的形式接收到服务器推送的通知，而新数据格式则用于交付每一次数据更新。
实际上：SSE 提供的是一个高效、跨浏览器的 XHR 流实现，消息交付只使用一个长 HTTP 连接。然而，与我们自己实现 XHR 流不同，浏览器会帮我们管理连接、 解析消息，从而让我们只关注业务逻辑。篇幅有限，关于 SSE 的更多细节，就不展开介绍了，对 SSE 感兴趣的小伙伴可以自行阅读以下几篇：
WebSocket 是一种与 HTTP 不同的协议。两者都位于 OSI 模型的应用层，并且都依赖于传输层的 TCP 协议。
虽然它们不同，但是 RFC 6455 中规定：WebSocket 被设计为在 HTTP 80 和 443 端口上工作，并支持 HTTP 代理和中介，从而使其与 HTTP 协议兼容。 为了实现兼容性，WebSocket 握手使用 HTTP Upgrade 头，从 HTTP 协议更改为 WebSocket 协议。
当然，WebSocket与HTTP的关系显然不是这三两句话可以说的清，有兴趣的读者可以详读下面这两篇：
长轮询就是：客户端发起一个请求，服务器收到客户端发来的请求后，服务器端不会直接进行响应，而是先将这个请求挂起，然后判断请求的数据是否有更新。如果有更新，则进行响应，如果一直没有数据，则等待一定的时间后才返回。
长轮询的本质还是基于 HTTP 协议，它仍然是一个一问一答（请求 — 响应）的模式。而 WebSocket 在握手成功后，就是全双工的 TCP 通道，数据可以主动从服务端发送到客户端。
要理解WebSocket 与长轮询的区别，需要深刻理解长轮询的技术原理，以下3篇中有关长轮询的技术介绍建议深入阅读：
网络中的接收和发送数据都是使用 Socket 进行实现。但是如果此套接字已经断开，那发送数据和接收数据的时候就一定会有问题。
可是如何判断这个套接字是否还可以使用呢？这个就需要在系统中创建心跳机制。
所谓 “心跳” 就是定时发送一个自定义的结构体（心跳包或心跳帧），让对方知道自己 “在线”，以确保链接的有效性。
而所谓的心跳包就是客户端定时发送简单的信息给服务器端告诉它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息，如果服务端几分钟内没有收到客户端信息则视客户端断开。
在 WebSocket 协议中定义了 心跳 Ping 和 心跳 Pong 的控制帧：
针对第2）点：如果终端收到一个 Ping 帧但是没有发送 Pong 帧来回应之前的 Ping 帧，那么终端可以选择仅为最近处理的 Ping 帧发送 Pong 帧。此外，可以自动发送一个 Pong 帧，这用作单向心跳。
网络上的两个程序通过一个双向的通信连接实现数据的交换，这个连接的一端称为一个 Socket（套接字），因此建立网络通信连接至少要一对端口号。
Socket 本质：是对 TCP/IP 协议栈的封装，它提供了一个针对 TCP 或者 UDP 编程的接口，并不是另一种协议。通过 Socket，你可以使用 TCP/IP 协议。
百度百科上关于Socket的描述是这样：
Socket 的英文原义是“孔”或“插座”：作为 BSD UNIX 的进程通信机制，取后一种意思。通常也称作”套接字“，用于描述IP地址和端口，是一个通信链的句柄，可以用来实现不同虚拟机或不同计算机之间的通信。在Internet 上的主机一般运行了多个服务软件，同时提供几种服务。每种服务都打开一个Socket，并绑定到一个端口上，不同的端口对应于不同的服务。Socket 正如其英文原义那样，像一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供 220 伏交流电， 有的提供 110 伏交流电，有的则提供有线电视节目。 客户软件将插头插到不同编号的插座，就可以得到不同的服务。
关于 Socket，可以总结以下几点：
下图说明了面向连接的协议的套接字 API 的客户端/服务器关系：
[1] 新手快速入门：WebSocket简明教程
[2] WebSocket从入门到精通，半小时就够！
[3] 新手入门贴：史上最全Web端即时通讯技术原理详解
[4] Web端即时通讯技术盘点：短轮询、Comet、Websocket、SSE
[5] SSE技术详解：一种全新的HTML5服务器推送事件技术
[6] Comet技术详解：基于HTTP长连接的Web端实时通信技术
[7] WebSocket详解（四）：刨根问底HTTP与WebSocket的关系(上篇)
[8] WebSocket详解（五）：刨根问底HTTP与WebSocket的关系(下篇)
[9] WebSocket详解（六）：刨根问底WebSocket与Socket的关系
[10] Web端即时通讯实践干货：如何让你的WebSocket断网重连更快速？
[11] 理论联系实际：从零理解WebSocket的通信原理、协议格式、安全性
[12] WebSocket硬核入门：200行代码，教你徒手撸一个WebSocket服务器
[13] 网页端IM通信技术快速入门：短轮询、长轮询、SSE、WebSocket