关于即时通讯:万字长文一篇吃透WebSocket概念原理易错常识动手实践

本文由作者“阿宝哥”分享，原题“你不晓得的 WebSocket”，有订正和改变。

1、引言

本文将从基本概念、技术原理、常见易错常识、入手实际等多个方面动手，万字长文，带你一起全方位摸索 WebSocket 技术。

浏览完本文，你将理解以下内容：

1）理解 WebSocket 的诞生背景、WebSocket 是什么及它的长处；
2）理解 WebSocket 含有哪些 API 及如何应用 WebSocket API 发送一般文本和二进制数据；
3）理解 WebSocket 的握手协定和数据帧格局、掩码算法等相干常识；
4）理解 WebSocket 与 http、长轮询、socket 等的关系，理清常识性的了解谬误；
5）理解如何实现一个反对发送一般文本的 WebSocket 服务器。

学习交换：

• 即时通讯 / 推送技术开发交换 5 群：215477170 [举荐]
• 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
• 开源 IM 框架源码：https://github.com/JackJiang2…

（本文同步公布于：http://www.52im.net/thread-37…）

2、对于作者

作者网名：阿宝哥
集体博客：http://www.semlinker.com/
作者 Github：https://github.com/semlinker/

3、什么是 WebSocket

3.1 WebSocket 诞生背景
晚期，很多网站为了实现推送技术，所用的技术都是轮询（也叫短轮询）。轮询是指由浏览器每隔一段时间向服务器收回 HTTP 申请，而后服务器返回最新的数据给客户端。

常见的轮询形式分为轮询与长轮询，它们的区别如下图所示：

为了更加直观感触轮询与长轮询之间的区别，咱们来看一下具体的代码：

这种传统的模式带来很显著的毛病，即浏览器须要一直的向服务器发出请求，然而 HTTP 申请与响应可能会蕴含较长的头部，其中真正无效的数据可能只是很小的一部分，所以这样会耗费很多带宽资源。

PS：对于短轮询、长轮询技术的前世今身，能够具体读这两篇：《新手入门贴：史上最全 Web 端即时通讯技术原理详解》、《Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》。

比拟新的轮询技术是 Comet。这种技术尽管能够实现双向通信，但依然须要重复发出请求。而且在 Comet 中广泛采纳的 HTTP 长连贯也会耗费服务器资源。

在这种状况下，HTML5 定义了 WebSocket 协定，能更好的节俭服务器资源和带宽，并且可能更实时地进行通信。

Websocket 应用 ws 或 wss 的对立资源标志符（URI），其中 wss 示意应用了 TLS 的 Websocket。

如：

ws://echo.websocket.org
wss://echo.websocket.org

WebSocket 与 HTTP 和 HTTPS 应用雷同的 TCP 端口，能够绕过大多数防火墙的限度。

默认状况下：

• 1）WebSocket 协定应用 80 端口；
• 2）若运行在 TLS 之上时，默认应用 443 端口。

3.2 WebSocket 简介
WebSocket 是一种网络传输协定，可在单个 TCP 连贯上进行全双工通信，位于 OSI 模型的应用层。WebSocket 协定在 2011 年由 IETF 标准化为 RFC 6455，后由 RFC 7936 补充标准。

WebSocket 使得客户端和服务器之间的数据交换变得更加简略，容许服务端被动向客户端推送数据。在 WebSocket API 中，浏览器和服务器只须要实现一次握手，两者之间就能够创立持久性的连贯，并进行双向数据传输。

介绍完轮询和 WebSocket 的相干内容之后，接下来用一张图看一下 XHR Polling（短轮询）与 WebSocket 之间的区别。

XHR Polling 与 WebSocket 之间的区别如下图所示：

3.3 WebSocket 长处
普遍认为，WebSocket 的长处有如下几点：

• 1）较少的管制开销：在连贯创立后，服务器和客户端之间替换数据时，用于协定管制的数据包头部绝对较小；
• 2）更强的实时性：因为协定是全双工的，所以服务器能够随时被动给客户端下发数据。绝对于 HTTP 申请须要期待客户端发动申请服务端能力响应，提早显著更少；
• 3）放弃连贯状态：与 HTTP 不同的是，WebSocket 须要先创立连贯，这就使得其成为一种有状态的协定，之后通信时能够省略局部状态信息；
• 4）更好的二进制反对：WebSocket 定义了二进制帧，绝对 HTTP，能够更轻松地解决二进制内容；
• 5）能够反对扩大：WebSocket 定义了扩大，用户能够扩大协定、实现局部自定义的子协定。

因为 WebSocket 领有上述的长处，所以它被宽泛地利用在即时通讯 /IM、实时音视频、在线教育和游戏等畛域。

对于前端开发者来说，要想应用 WebSocket 提供的弱小能力，就必须先把握 WebSocket API，上面带大家一起来认识一下 WebSocket API。

PS：如果你想要更通俗的 WebSocket 入门教程，能够先读这篇《老手疾速入门：WebSocket 扼要教程》后，再回来持续学习。

4、WebSocket API 学习

4.1 根本状况
在介绍 WebSocket API 之前，咱们先来理解一下它的兼容性：

（图片援用自：https://caniuse.com/#search=W…）

由上图可知：目前支流的 Web 浏览器都反对 WebSocket，所以咱们能够在大多数我的项目中释怀地应用它。

在浏览器中要应用 WebSocket 提供的能力，咱们就必须先创立 WebSocket 对象，该对象提供了用于创立和治理 WebSocket 连贯，以及能够通过该连贯发送和接收数据的 API。

应用 WebSocket 构造函数，咱们就能轻易地结构一个 WebSocket 对象。

接下来咱们将从以下四个方面来介绍 WebSocket API：

1）WebSocket 构造函数；
2）WebSocket 对象的属性；
3）WebSocket 的办法；
4）WebSocket 事件。

接下来咱们从 WebSocket 的构造函数动手开始学习。

PS：如果你想要更通俗的 WebSocket 入门教程，能够先读这篇《老手疾速入门：WebSocket 扼要教程》后，再回来持续学习。

4.2 构造函数
WebSocket 构造函数的语法为：

const myWebSocket = newWebSocket(url [, protocols]);

相干参数阐明如下：

1）url：示意连贯的 URL，这是 WebSocket 服务器将响应的 URL；
2）protocols（可选）：一个协定字符串或者一个蕴含协定字符串的数组。

针对第 2）点：这些字符串用于指定子协定，这样单个服务器能够实现多个 WebSocket 子协定。

比方：你可能心愿一台服务器可能依据指定的协定（protocol）解决不同类型的交互。如果不指定协定字符串，则假设为空字符串。

应用 WebSocket 构造函数时，当尝试连贯的端口被阻止时，会抛出 SECURITY_ERR 异样。

PS：无关 WebSocket 构造函数的更具体阐明，能够参见官网 API 文档。

4.3 属性
WebSocket 对象蕴含以下属性：

每个属性的具体含意如下：

1）binaryType：应用二进制的数据类型连贯；
2）bufferedAmount（只读）：未发送至服务器的字节数；
3）extensions（只读）：服务器抉择的扩大；
4）onclose：用于指定连贯敞开后的回调函数；
5）onerror：用于指定连贯失败后的回调函数；
6）onmessage：用于指定当从服务器承受到信息时的回调函数；
7）onopen：用于指定连贯胜利后的回调函数；
8）protocol（只读）：用于返回服务器端选中的子协定的名字；
9）readyState（只读）：返回以后 WebSocket 的连贯状态，共有 4 种状态：

- CONNECTING — 正在连接中，对应的值为 0；- OPEN — 曾经连贯并且能够通信，对应的值为 1；- CLOSING — 连贯正在敞开，对应的值为 2；- CLOSED — 连贯已敞开或者没有连贯胜利，对应的值为 3

10）url（只读）：返回值为当构造函数创立 WebSocket 实例对象时 URL 的绝对路径。

4.4 办法
WebSocket 次要办法有两个：

1）close(])：该办法用于敞开 WebSocket 连贯，如果连贯曾经敞开，则此办法不执行任何操作；
2）send(data)：该办法将须要通过 WebSocket 链接传输至服务器的数据排入队列，并依据所须要传输的数据的大小来减少 bufferedAmount 的值。若数据无奈传输（比方数据须要缓存而缓冲区已满）时，套接字会自行敞开。

4.5 事件
应用 addEventListener() 或将一个事件监听器赋值给 WebSocket 对象的 oneventname 属性，来监听上面的事件。

以下是几个事件：

1）close：当一个 WebSocket 连贯被敞开时触发，也能够通过 onclose 属性来设置；
2）error：当一个 WebSocket 连贯因谬误而敞开时触发，也能够通过 onerror 属性来设置；
3）message：当通过 WebSocket 收到数据时触发，也能够通过 onmessage 属性来设置；
4）open：当一个 WebSocket 连贯胜利时触发，也能够通过 onopen 属性来设置。

介绍完 WebSocket API，咱们来举一个应用 WebSocket 发送一般文本的示例。

4.6 代码实际：发送一般文本

在以上示例中：咱们在页面上创立了两个 textarea，别离用于寄存 待发送的数据 和 服务器返回的数据。当用户输出完待发送的文本之后，点击 发送 按钮时会把输出的文本发送到服务端，而服务端胜利接管到音讯之后，会把收到的音讯一成不变地回传到客户端。

// const socket = new WebSocket(“ws://echo.websocket.org”);
// const sendMsgContainer = document.querySelector(“#sendMessage”);
援用
function send() {
const message = sendMsgContainer.value;
援用
if(socket.readyState !== WebSocket.OPEN) {

console.log("连贯未建设，还不能发送音讯");

援用

return;

援用
}
援用
if(message) socket.send(message);
援用
}
援用
当然客户端接管到服务端返回的音讯之后，会把对应的文本内容保留到 接管的数据 对应的 textarea 文本框中。
援用
// const socket = new WebSocket(“ws://echo.websocket.org”);
援用
// const receivedMsgContainer = document.querySelector(“#receivedMessage”);
援用
socket.addEventListener(“message”, function(event) {
console.log(“Message from server “, event.data);
援用
receivedMsgContainer.value = event.data;
援用
});

为了更加直观地了解上述的数据交互过程，咱们应用 Chrome 浏览器的开发者工具来看一下相应的过程。

如下图所示：

以上示例对应的残缺代码如下所示：

<!DOCTYPE html>
<html>
援用
<head>
援用

<metacharset="UTF-8"/>

援用

<metaname="viewport"content="width=device-width, initial-scale=1.0"/>

援用

<title>WebSocket 发送一般文本示例 </title>

援用

<style>

援用

  .block {flex: 1;

援用

  }

援用

</style>

援用
</head>
援用
<body>
援用

<h3>WebSocket 发送一般文本示例 </h3>

援用

<divstyle="display: flex;">

援用

  <divclass="block">

援用

    <p> 行将发送的数据：<button> 发送 </button></p>

援用

    <textareaid="sendMessage"rows="5"cols="15"></textarea>

援用

  </div>

援用

  <divclass="block">

援用

    <p> 接管的数据：</p>

援用

    <textareaid="receivedMessage"rows="5"cols="15"></textarea>

援用

  </div>

援用

</div>

援用

<script>

援用

  const sendMsgContainer = document.querySelector("#sendMessage");

援用

  const receivedMsgContainer = document.querySelector("#receivedMessage");

援用

  const socket = new WebSocket("ws://echo.websocket.org");

援用

  // 监听连贯胜利事件

援用

  socket.addEventListener("open", function (event) {console.log("连贯胜利，能够开始通信");

援用

  });

援用

  // 监听音讯

援用

  socket.addEventListener("message", function (event) {console.log("Message from server", event.data);

援用

    receivedMsgContainer.value = event.data;

援用

  });

援用

  function send() {const message = sendMsgContainer.value;

援用

    if (socket.readyState !== WebSocket.OPEN) {console.log("连贯未建设，还不能发送音讯");

援用

      return;

援用

    }

援用

    if (message) socket.send(message);

援用

  }

援用

</script>

援用
</body>
援用
</html>

其实 WebSocket 除了反对发送一般的文本之外，它还反对发送二进制数据，比方 ArrayBuffer 对象、Blob 对象或者 ArrayBufferView 对象。

代码示例如下：

const socket = new WebSocket(“ws://echo.websocket.org”);
援用
socket.onopen = function() {
// 发送 UTF- 8 编码的文本信息
援用
socket.send(“Hello Echo Server!”);
援用
// 发送 UTF- 8 编码的 JSON 数据
援用
socket.send(JSON.stringify({ msg: “ 我是阿宝哥 ”}));
援用
// 发送二进制 ArrayBuffer
援用
const buffer = newArrayBuffer(128);
援用
socket.send(buffer);
援用
// 发送二进制 ArrayBufferView
援用
const intview = new Uint32Array(buffer);
援用
socket.send(intview);
援用
// 发送二进制 Blob
援用
const blob = new Blob([buffer]);
援用
socket.send(blob);
援用
};

以上代码胜利运行后，通过 Chrome 开发者工具，咱们能够看到对应的数据交互过程。

如下图所示：

上面以发送 Blob 对象为例，来介绍一下如何发送二进制数据。

Blob（Binary Large Object）示意二进制类型的大对象。在数据库管理系统中，将二进制数据存储为一个繁多个体的汇合。Blob 通常是影像、声音或多媒体文件。在 JavaScript 中 Blob 类型的对象示意不可变的相似文件对象的原始数据。

对 Blob 感兴趣的小伙伴，能够浏览《你不晓得的 Blob》这篇文章。

4.7 代码实际：发送二进制数据

在以上示例中，咱们在页面上创立了两个 textarea，别离用于寄存 待发送的数据 和 服务器返回的数据。

当用户输出完待发送的文本之后，点击 发送 按钮时，咱们会先获取输出的文本并把文本包装成 Blob 对象而后发送到服务端，而服务端胜利接管到音讯之后，会把收到的音讯一成不变地回传到客户端。

当浏览器接管到新音讯后，如果是文本数据，会主动将其转换成 DOMString 对象，如果是二进制数据或 Blob 对象，会间接将其转交给利用，由利用本身来依据返回的数据类型进行相应的解决。

数据发送代码：

// const socket = new WebSocket(“ws://echo.websocket.org”);
援用
// const sendMsgContainer = document.querySelector(“#sendMessage”);
援用
function send() {
const message = sendMsgContainer.value;
援用
if(socket.readyState !== WebSocket.OPEN) {

console.log("连贯未建设，还不能发送音讯");

援用

return;

援用
}
援用
const blob = newBlob([message], {type: “text/plain”});
援用
if(message) socket.send(blob);
援用
console.log( 未发送至服务器的字节数：${socket.bufferedAmount});
援用
}

当客户端接管到服务端返回的音讯之后，会判断返回的数据类型，如果是 Blob 类型的话，会调用 Blob 对象的 text() 办法，获取 Blob 对象中保留的 UTF-8 格局的内容，而后把对应的文本内容保留到 接管的数据 对应的 textarea 文本框中。

数据接管代码：

// const socket = new WebSocket(“ws://echo.websocket.org”);
援用
// const receivedMsgContainer = document.querySelector(“#receivedMessage”);
援用
socket.addEventListener(“message”, async function(event) {
console.log(“Message from server “, event.data);
援用
const receivedData = event.data;
援用
if(receivedData instanceofBlob) {

receivedMsgContainer.value = await receivedData.text();

援用
} else{

receivedMsgContainer.value = receivedData;

援用
}
援用
});

同样，咱们应用 Chrome 浏览器的开发者工具来看一下相应的过程：

通过上图咱们能够很显著地看到，当应用发送 Blob 对象时，Data 栏位的信息显示的是 Binary Message，而对于发送一般文本来说，Data 栏位的信息是间接显示发送的文本音讯。

以上示例对应的残缺代码如下所示：

<!DOCTYPE html>
援用
<html>
援用
<head>
援用

<meta charset="UTF-8"/>

援用

<meta name="viewport"content="width=device-width, initial-scale=1.0"/>

援用

<title>WebSocket 发送二进制数据示例 </title>

援用

<style>

援用

  .block {flex: 1;

援用

  }

援用

</style>

援用
</head>
援用
<body>
援用

<h3>WebSocket 发送二进制数据示例 </h3>

援用

<div style="display: flex;">

援用

  <div class="block">

援用

    <p> 待发送的数据：<button> 发送 </button></p>

援用

    <textarea id="sendMessage"rows="5"cols="15"></textarea>

援用

  </div>

援用

  <div class="block">

援用

    <p> 接管的数据：</p>

援用

    <textarea id="receivedMessage"rows="5"cols="15"></textarea>

援用

  </div>

援用

</div>

援用

<script>

援用

  const sendMsgContainer = document.querySelector("#sendMessage");

援用

  const receivedMsgContainer = document.querySelector("#receivedMessage");

援用

  const socket = new WebSocket("ws://echo.websocket.org");

援用

  // 监听连贯胜利事件

援用

  socket.addEventListener("open", function(event) {console.log("连贯胜利，能够开始通信");

援用

  });

援用

  // 监听音讯

援用

  socket.addEventListener("message", async function(event) {console.log("Message from server", event.data);

援用

    const receivedData = event.data;

援用

    if(receivedData instanceofBlob) {receivedMsgContainer.value = await receivedData.text();

援用

    } else{receivedMsgContainer.value = receivedData;

援用

    }

援用

  });

援用

  functionsend() {const message = sendMsgContainer.value;

援用

    if(socket.readyState !== WebSocket.OPEN) {console.log("连贯未建设，还不能发送音讯");

援用

      return;

援用

    }

援用

    const blob = newBlob([message], {type: "text/plain"});

援用

    if(message) socket.send(blob);

援用

    console.log(` 未发送至服务器的字节数：${socket.bufferedAmount}`);

援用

  }

援用

</script>

援用
</body>
援用
</html>

可能有一些小伙伴理解完 WebSocket API 之后，感觉还不够过瘾。上面将带大家来实现一个反对发送一般文本的 WebSocket 服务器。

5、手写 WebSocket 服务器

5.1 写在后面
在介绍如何手写 WebSocket 服务器前，咱们须要理解一下 WebSocket 连贯的生命周期。

从上图可知：在应用 WebSocket 实现全双工通信之前，客户端与服务器之间须要先进行握手（Handshake），在实现握手之后能力开始进行数据的双向通信。

握手是在通信电路创立之后，信息传输开始之前。

握手用于达成参数，如：

1）信息传输率
2）字母表
3）奇偶校验
4）中断过程；
5）其余协定个性。

握手有助于不同构造的零碎或设施在通信信道中连贯，而不须要人为设置参数。

既然握手是 WebSocket 连贯生命周期的第一个环节，接下来咱们就先来剖析 WebSocket 的握手协定。

5.2 握手协定
WebSocket 协定属于应用层协定，它依赖于传输层的 TCP 协定。WebSocket 通过 HTTP/1.1 协定的 101 状态码进行握手。为了创立 WebSocket 连贯，须要通过浏览器发出请求，之后服务器进行回应，这个过程通常称为“握手”（Handshaking）。

利用 HTTP 实现握手有几个益处：

1）首先：让 WebSocket 与现有 HTTP 基础设施兼容——使得 WebSocket 服务器能够运行在 80 和 443 端口上，这通常是对客户端惟一凋谢的端口；
2）其次：让咱们能够重用并扩大 HTTP 的 Upgrade 流，为其增加自定义的 WebSocket 首部，以实现协商。

上面咱们以后面曾经演示过的发送一般文本的例子为例，来具体分析一下握手过程。

5.2.1）客户端申请：

GET ws://echo.websocket.org/ HTTP/1.1
援用
Host: echo.websocket.org
援用
Origin: file://
援用
Connection: Upgrade
援用
Upgrade: websocket
援用
Sec-WebSocket-Version: 13
援用
Sec-WebSocket-Key: Zx8rNEkBE4xnwifpuh8DHQ==
援用
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits

备注：已疏忽局部 HTTP 申请头。

针对上述申请中的字段阐明如下：

1）Connection：必须设置 Upgrade，示意客户端心愿连贯降级；
2）Upgrade：字段必须设置 websocket，示意心愿降级到 WebSocket 协定；
3）Sec-WebSocket-Version：示意反对的 WebSocket 版本。RFC6455 要求应用的版本是 13，之前草案的版本均该当弃用；
4）Sec-WebSocket-Key：是随机的字符串，服务器端会用这些数据来结构出一个 SHA-1 的信息摘要；
5）Sec-WebSocket-Extensions：用于协商本次连贯要应用的 WebSocket 扩大：客户端发送反对的扩大，服务器通过返回雷同的首部确认本人反对一个或多个扩大；
6）Origin：字段是可选的，通常用来示意在浏览器中发动此 WebSocket 连贯所在的页面，相似于 Referer。然而，与 Referer 不同的是，Origin 只蕴含了协定和主机名称。

针对上述第 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 响应头。

针对上述响应中的字段阐明如下：

① 101 响应码确认降级到 WebSocket 协定；
② 设置 Connection 头的值为“Upgrade”来批示这是一个降级申请（HTTP 协定提供了一种非凡的机制，这一机制容许将一个已建设的连贯升级成新的、不相容的协定）；
③ Upgrade 头指定一项或多项协定名，按优先级排序，以逗号分隔。这里示意降级为 WebSocket 协定；
④ 签名的键值验证协定反对。

介绍完 WebSocket 的握手协定，接下来将应用 Node.js 来开发咱们的 WebSocket 服务器。

5.3 实现握手性能
要开发一个 WebSocket 服务器，首先咱们须要先实现握手性能。这里我应用 Node.js 内置的 http 模块来创立一个 HTTP 服务器。

具体代码如下所示：

const http = require(“http”);
援用
const port = 8888;
援用
const {generateAcceptValue} = require(“./util”);
援用
const server = http.createServer((req, res) => {
res.writeHead(200, { “Content-Type”: “text/plain; charset=utf-8”});
援用
res.end(“ 大家好，我是阿宝哥。感激你浏览“你不晓得的 WebSocket””);
援用
});
援用
server.on(“upgrade”, function(req, socket) {
if(req.headers[“upgrade”] !== “websocket”) {

socket.end("HTTP/1.1 400 Bad Request");

援用

return;

援用
}
援用
// 读取客户端提供的 Sec-WebSocket-Key
援用
const secWsKey = req.headers[“sec-websocket-key”];
援用
// 应用 SHA- 1 算法生成 Sec-WebSocket-Accept
援用
const hash = generateAcceptValue(secWsKey);
援用
// 设置 HTTP 响应头
援用
const responseHeaders = [
援用

"HTTP/1.1 101 Web Socket Protocol Handshake",

援用

"Upgrade: WebSocket",

援用

"Connection: Upgrade",

援用

`Sec-WebSocket-Accept: ${hash}`,

援用
];
援用
// 返回握手申请的响应信息
援用
socket.write(responseHeaders.join(“\r\n”) + “\r\n\r\n”);
援用
});
援用
server.listen(port, () =>
援用
console.log(Server running at http://localhost:${port})
援用
);

在以上代码中：咱们首先引入了 http 模块，而后通过调用该模块的 createServer() 办法创立一个 HTTP 服务器，接着咱们监听 upgrade 事件，每次服务器响应降级申请时就会触发该事件。因为咱们的服务器只反对降级到 WebSocket 协定，所以如果客户端申请降级的协定非 WebSocket 协定，咱们将会返回“400 Bad Request”。

当服务器接管到降级为 WebSocket 的握手申请时，会先从申请头中获取“Sec-WebSocket-Key”的值，而后把该值加上一个非凡字符串“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”，而后计算 SHA-1 摘要，之后进行 Base64 编码，将后果做为“Sec-WebSocket-Accept”头的值，返回给客户端。

上述的过程看起来如同有点繁琐，其实利用 Node.js 内置的 crypto 模块，几行代码就能够搞定了。

代码如下：

// util.js
援用
const crypto = require(“crypto”);
援用
const MAGIC_KEY = “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”;
援用
function generateAcceptValue(secWsKey) {
return crypto
援用

.createHash("sha1")

援用

.update(secWsKey + MAGIC_KEY, "utf8")

援用

.digest("base64");

援用
}

开发完握手性能之后，咱们能够应用后面的示例来测试一下该性能。待服务器启动之后，咱们只有对“发送一般文本”示例，做简略地调整，即把先前的 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 服务器要反对子协定的话，你能够参考以下代码进行子协定的解决，这里就不持续开展介绍了。

// 从申请头中读取子协定
援用
const protocol = req.headers[“sec-websocket-protocol”];
援用
// 如果蕴含子协定，则解析子协定
援用
const protocols = !protocol ? [] : protocol.split(“,”).map((s) => s.trim());
援用
// 简略起见，咱们仅判断是否含有 JSON 子协定
援用
if(protocols.includes(“json”)) {
responseHeaders.push(Sec-WebSocket-Protocol: json);
援用
}

好的，WebSocket 握手协定相干的内容根本曾经介绍完了。下一步咱们来介绍开发音讯通信性能须要理解的一些基础知识。

5.4 音讯通信根底
在 WebSocket 协定中，数据是通过一系列数据帧来进行传输的。

为了防止因为网络中介（例如一些拦挡代理）或者一些平安问题，客户端必须在它发送到服务器的所有帧中增加掩码。服务端收到没有增加掩码的数据帧当前，必须立刻敞开连贯。

5.4.1）数据帧格局：

要实现音讯通信，咱们就必须理解 WebSocket 数据帧的格局：

可能有一些小伙伴看到下面的内容之后，就开始有点“懵逼”了。

上面咱们来结合实际的数据帧来进一步剖析一下：

在上图中：简略剖析了“发送一般文本”示例对应的数据帧格局。这里咱们来进一步介绍一下 Payload length，因为在前面开发数据解析性能的时候，须要用到该知识点。

Payload length 示意以字节为单位的“无效负载数据”长度。

它有以下几种情景：

1）如果值为 0-125，那么就示意负载数据的长度；
2）如果是 126，那么接下来的 2 个字节解释为 16 位的无符号整形作为负载数据的长度；
3）如果是 127，那么接下来的 8 个字节解释为一个 64 位的无符号整形（最高位的 bit 必须为 0）作为负载数据的长度。

备注：多字节长度量以网络字节程序示意，无效负载长度是指“扩大数据”+“利用数据”的长度。“扩大数据”的长度可能为 0，那么无效负载长度就是“利用数据”的长度。

另外：除非协商过扩大，否则“扩大数据”长度为 0 字节。在握手协定中，任何扩大都必须指定“扩大数据”的长度，这个长度如何进行计算，以及这个扩大如何应用。如果存在扩大，那么这个“扩大数据”蕴含在总的无效负载长度中。

PS：对于数据帧格局的具体解说，能够深刻读读以下几篇：

《WebSocket 从入门到精通，半小时就够！》
《实践联系实际：从零了解 WebSocket 的通信原理、协定格局、安全性》

5.4.2）掩码算法：

掩码字段是一个由客户端随机抉择的 32 位的值。掩码值必须是不可被预测的。因而，掩码必须来自弱小的熵源（entropy），并且给定的掩码不能让服务器或者代理可能很容易的预测到后续帧。掩码的不可预测性对于预防歹意利用的作者在网上裸露相干的字节数据至关重要。

掩码不影响数据荷载的长度，对数据进行掩码操作和对数据进行反掩码操作所波及的步骤是雷同的。

掩码、反掩码操作都采纳如下算法：

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

解释一下：

1）original-octet-i：为原始数据的第 i 字节；
2）transformed-octet-i：为转换后的数据的第 i 字节；
3）masking-key-octet-j：为 mask key 第 j 字节。

为了让小伙伴们可能更好的了解下面掩码的计算过程，咱们来对示例中“我是阿宝哥”数据进行掩码操作。

这里“我是阿宝哥”对应的 UTF-8 编码如下所示：

E6 88 91 E6 98 AF E9 98 BF E5 AE 9D E5 93 A5

而对应的 Masking-Key 为 0x08f6efb1。

依据下面的算法，咱们能够这样进行掩码运算：

let uint8 = new Uint8Array([0xE6, 0x88, 0x91, 0xE6, 0x98, 0xAF, 0xE9, 0x98,0xBF, 0xE5, 0xAE, 0x9D, 0xE5, 0x93, 0xA5]);
援用
let maskingKey = new Uint8Array([0x08, 0xf6, 0xef, 0xb1]);
援用
let maskedUint8 = new Uint8Array(uint8.length);
援用
for(let i = 0, j = 0; i < uint8.length; i++, j = i % 4) {
maskedUint8[i] = uint8[i] ^ maskingKey[j];
援用
}
援用
console.log(Array.from(maskedUint8).map(num=>Number(num).toString(16)).join(‘ ‘));

以上代码胜利运行后，控制台会输入以下后果：

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，咱们就能够跨帧发送音讯。

操作码通知了帧应该做什么：

1）如果是 0x1，有效载荷就是文本；
2）如果是 0x2，有效载荷就是二进制数据；
3）如果是 0x0，则该帧是一个连续帧（这意味着服务器应该将帧的无效负载连贯到从该客户机接管到的最初一个帧）。

为了让大家可能更好地了解上述的内容，咱们来看一个来自 MDN 上的示例：

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 实现音讯通信性能
笔者把实现音讯通信性能，合成为音讯解析与音讯响应两个子性能，上面咱们别离来介绍如何实现这两个子性能。

5.5.1）音讯解析：

利用音讯通信根底环节中介绍的相干常识，我实现了一个 parseMessage 函数，用来解析客户端传过来的 WebSocket 数据帧。

出于简略思考，这里只解决文本帧，具体代码如下所示：

function parseMessage(buffer) {
  // 第一个字节，蕴含了 FIN 位，opcode, 掩码位

  const firstByte = buffer.readUInt8(0);

  // [FIN, RSV, RSV, RSV, OPCODE, OPCODE, OPCODE, OPCODE];

  // 右移 7 位取首位，1 位，示意是否是最初一帧数据

  const isFinalFrame = Boolean((firstByte >>> 7) & 0x01);

  console.log("isFIN:", isFinalFrame);

  // 取出操作码，低四位

  /**

   * %x0：示意一个连续帧。当 Opcode 为 0 时，示意本次数据传输采纳了数据分片，以后收到的数据帧为其中一个数据分片；* %x1：示意这是一个文本帧（text frame）；* %x2：示意这是一个二进制帧（binary frame）；* %x3-7：保留的操作代码，用于后续定义的非管制帧；* %x8：示意连贯断开；* %x9：示意这是一个心跳申请（ping）；* %xA：示意这是一个心跳响应（pong）；* %xB-F：保留的操作代码，用于后续定义的管制帧。*/

  const opcode = firstByte & 0x0f;

  if(opcode === 0x08) {
    // 连贯敞开

    return;

  }

  if(opcode === 0x02) {
    // 二进制帧

    return;

  }

  if(opcode === 0x01) {
    // 目前只解决文本帧

    let offset = 1;

    const secondByte = buffer.readUInt8(offset);

    // MASK: 1 位，示意是否应用了掩码，在发送给服务端的数据帧里必须应用掩码，而服务端返回时不须要掩码

    const useMask = Boolean((secondByte >>> 7) & 0x01);

    console.log("use MASK:", useMask);

    const payloadLen = secondByte & 0x7f; // 低 7 位示意载荷字节长度

    offset += 1;

    // 四个字节的掩码

    let MASK = [];

    // 如果这个值在 0 -125 之间，则前面的 4 个字节（32 位）就应该被间接辨认成掩码；if(payloadLen <= 0x7d) {
      // 载荷长度小于 125

      MASK = buffer.slice(offset, 4 + offset);

      offset += 4;

      console.log("payload length:", payloadLen);

    } elseif(payloadLen === 0x7e) {
      // 如果这个值是 126，则前面两个字节（16 位）内容应该，被辨认成一个 16 位的二进制数示意数据内容大小；console.log("payload length:", buffer.readInt16BE(offset));

      // 长度是 126，则前面两个字节作为 payload length，32 位的掩码

      MASK = buffer.slice(offset + 2, offset + 2 + 4);

      offset += 6;

    } else{
      // 如果这个值是 127，则前面的 8 个字节（64 位）内容应该被辨认成一个 64 位的二进制数示意数据内容大小

      MASK = buffer.slice(offset + 8, offset + 8 + 4);

      offset += 12;

    }

    // 开始读取前面的 payload，与掩码计算，失去原来的字节内容

    const newBuffer = [];

    const dataBuffer = buffer.slice(offset);

    for(let i = 0, j = 0; i < dataBuffer.length; i++, j = i % 4) {const nextBuf = dataBuffer[i];

      newBuffer.push(nextBuf ^ MASK[j]);

    }

    return Buffer.from(newBuffer).toString();}

  return "";

}

创立完 parseMessage 函数，咱们来更新一下之前创立的 WebSocket 服务器：

server.on("upgrade", function(req, socket) {socket.on("data", (buffer) => {const message = parseMessage(buffer);

    if(message) {console.log("Message from client:"+ message);

    } elseif(message === null) {console.log("WebSocket connection closed by the client.");

    }

  });

  if(req.headers["upgrade"] !== "websocket") {socket.end("HTTP/1.1 400 Bad Request");

    return;

  }

  // 省略已有代码

});

更新实现之后，咱们重新启动服务器，而后持续应用“发送一般文本”的示例来测试音讯解析性能。

以下发送“我是阿宝哥”文本音讯后，WebSocket 服务器输入的信息：

Server running at http://localhost:8888

isFIN:  true

use MASK:  true

payload length:  15

Message from client: 我是阿宝哥

通过观察以上的输入信息，咱们的 WebSocket 服务器曾经能够胜利解析客户端发送蕴含一般文本的数据帧，下一步咱们来实现音讯响应的性能。

5.5.2）音讯响应：

要把数据返回给客户端，咱们的 WebSocket 服务器也得依照 WebSocket 数据帧的格局来封装数据。

与后面介绍的 parseMessage 函数一样，我也封装了一个 constructReply 函数用来封装返回的数据。

该函数的具体代码如下：

function constructReply(data) {const json = JSON.stringify(data);

  const jsonByteLength = Buffer.byteLength(json);

  // 目前只反对小于 65535 字节的负载

  const lengthByteCount = jsonByteLength < 126 ? 0 : 2;

  const payloadLength = lengthByteCount === 0 ? jsonByteLength : 126;

  const buffer = Buffer.alloc(2 + lengthByteCount + jsonByteLength);

  // 设置数据帧首字节，设置 opcode 为 1，示意文本帧

  buffer.writeUInt8(0b10000001, 0);

  buffer.writeUInt8(payloadLength, 1);

  // 如果 payloadLength 为 126，则前面两个字节（16 位）内容应该，被辨认成一个 16 位的二进制数示意数据内容大小

  let payloadOffset = 2;

  if(lengthByteCount > 0) {buffer.writeUInt16BE(jsonByteLength, 2);

    payloadOffset += lengthByteCount;

  }

  // 把 JSON 数据写入到 Buffer 缓冲区中

  buffer.write(json, payloadOffset);

  return buffer;

}

创立完 constructReply 函数，咱们再来更新一下之前创立的 WebSocket 服务器：

server.on(“upgrade”, function(req, socket) {
socket.on(“data”, (buffer) => {

const message = parseMessage(buffer);

if(message) {console.log("Message from client:"+ message);

  // 新增以下 👇 代码

  socket.write(constructReply({ message}));

} elseif(message === null) {console.log("WebSocket connection closed by the client.");

}

});

});

到这里，咱们的 WebSocket 服务器曾经开发实现了，接下来咱们来残缺验证一下它的性能。

从上图中可知：以上开发的简易版 WebSocket 服务器曾经能够失常解决一般文本音讯了。

最初咱们来看一下残缺的代码。

custom-websocket-server.js 文件：

const http = require("http");

const port = 8888;

const {generateAcceptValue, parseMessage, constructReply} = require("./util");

const server = http.createServer((req, res) => {res.writeHead(200, { "Content-Type": "text/plain; charset=utf-8"});

  res.end("大家好，我是阿宝哥。感激你浏览“你不晓得的 WebSocket”");

});

server.on("upgrade", function(req, socket) {socket.on("data", (buffer) => {const message = parseMessage(buffer);

    if(message) {console.log("Message from client:"+ message);

      socket.write(constructReply({ message}));

    } else if(message === null) {console.log("WebSocket connection closed by the client.");

    }

  });

  if(req.headers["upgrade"] !== "websocket") {socket.end("HTTP/1.1 400 Bad Request");

    return;

  }

  // 读取客户端提供的 Sec-WebSocket-Key

  const secWsKey = req.headers["sec-websocket-key"];

  // 应用 SHA- 1 算法生成 Sec-WebSocket-Accept

  const hash = generateAcceptValue(secWsKey);

  // 设置 HTTP 响应头

  const responseHeaders = [

    "HTTP/1.1 101 Web Socket Protocol Handshake",

    "Upgrade: WebSocket",

    "Connection: Upgrade",

    `Sec-WebSocket-Accept: ${hash}`,

  ];

  // 返回握手申请的响应信息

  socket.write(responseHeaders.join("\r\n") + "\r\n\r\n");

});

server.listen(port, () =>

  console.log(`Server running at http://localhost:${port}`)

);

util.js 文件：

const crypto = require(“crypto”);
援用
const MAGIC_KEY = “258EAFA5-E914-47DA-95CA-C5AB0DC85B11”;
援用
function generateAcceptValue(secWsKey) {
return crypto
援用

.createHash("sha1")

援用

.update(secWsKey + MAGIC_KEY, "utf8")

援用

.digest("base64");

援用
}
援用
function parseMessage(buffer) {
// 第一个字节，蕴含了 FIN 位，opcode, 掩码位
援用
const firstByte = buffer.readUInt8(0);
援用
// [FIN, RSV, RSV, RSV, OPCODE, OPCODE, OPCODE, OPCODE];
援用
// 右移 7 位取首位，1 位，示意是否是最初一帧数据
援用
const isFinalFrame = Boolean((firstByte >>> 7) & 0x01);
援用
console.log(“isFIN: “, isFinalFrame);
援用
// 取出操作码，低四位
援用
/**
援用

• %x0：示意一个连续帧。当 Opcode 为 0 时，示意本次数据传输采纳了数据分片，以后收到的数据帧为其中一个数据分片；

援用

• %x1：示意这是一个文本帧（text frame）；

援用

• %x2：示意这是一个二进制帧（binary frame）；

援用

• %x3-7：保留的操作代码，用于后续定义的非管制帧；

援用

• %x8：示意连贯断开；

援用

• %x9：示意这是一个心跳申请（ping）；

援用

• %xA：示意这是一个心跳响应（pong）；

援用

• %xB-F：保留的操作代码，用于后续定义的管制帧。

援用
*/
援用
const opcode = firstByte & 0x0f;
援用
if(opcode === 0x08) {

// 连贯敞开

援用

return;

援用
}
援用
if(opcode === 0x02) {

// 二进制帧

援用

return;

援用
}
援用
if(opcode === 0x01) {

// 目前只解决文本帧

援用

let offset = 1;

援用

const secondByte = buffer.readUInt8(offset);

援用

// MASK: 1 位，示意是否应用了掩码，在发送给服务端的数据帧里必须应用掩码，而服务端返回时不须要掩码

援用

const useMask = Boolean((secondByte >>> 7) & 0x01);

援用

console.log("use MASK:", useMask);

援用

const payloadLen = secondByte & 0x7f; // 低 7 位示意载荷字节长度

援用

offset += 1;

援用

// 四个字节的掩码

援用

let MASK = [];

援用

// 如果这个值在 0 -125 之间，则前面的 4 个字节（32 位）就应该被间接辨认成掩码；

援用

if(payloadLen <= 0x7d) {// 载荷长度小于 125

援用

  MASK = buffer.slice(offset, 4 + offset);

援用

  offset += 4;

援用

  console.log("payload length:", payloadLen);

援用

} else if(payloadLen === 0x7e) {// 如果这个值是 126，则前面两个字节（16 位）内容应该，被辨认成一个 16 位的二进制数示意数据内容大小；

援用

  console.log("payload length:", buffer.readInt16BE(offset));

援用

  // 长度是 126，则前面两个字节作为 payload length，32 位的掩码

援用

  MASK = buffer.slice(offset + 2, offset + 2 + 4);

援用

  offset += 6;

援用

} else{// 如果这个值是 127，则前面的 8 个字节（64 位）内容应该被辨认成一个 64 位的二进制数示意数据内容大小

援用

  MASK = buffer.slice(offset + 8, offset + 8 + 4);

援用

  offset += 12;

援用

}

援用

// 开始读取前面的 payload，与掩码计算，失去原来的字节内容

援用

const newBuffer = [];

援用

const dataBuffer = buffer.slice(offset);

援用

for(let i = 0, j = 0; i < dataBuffer.length; i++, j = i % 4) {const nextBuf = dataBuffer[i];

援用

  newBuffer.push(nextBuf ^ MASK[j]);

援用

}

援用

return Buffer.from(newBuffer).toString();

援用
}
援用
return “”;
援用
}
援用
function constructReply(data) {
const json = JSON.stringify(data);
援用
const jsonByteLength = Buffer.byteLength(json);
援用
// 目前只反对小于 65535 字节的负载
援用
const lengthByteCount = jsonByteLength < 126 ? 0 : 2;
援用
const payloadLength = lengthByteCount === 0 ? jsonByteLength : 126;
援用
const buffer = Buffer.alloc(2 + lengthByteCount + jsonByteLength);
援用
// 设置数据帧首字节，设置 opcode 为 1，示意文本帧
援用
buffer.writeUInt8(0b10000001, 0);
援用
buffer.writeUInt8(payloadLength, 1);
援用
// 如果 payloadLength 为 126，则前面两个字节（16 位）内容应该，被辨认成一个 16 位的二进制数示意数据内容大小
援用
let payloadOffset = 2;
援用
if(lengthByteCount > 0) {

buffer.writeUInt16BE(jsonByteLength, 2);

援用

payloadOffset += lengthByteCount;

援用
}
援用
// 把 JSON 数据写入到 Buffer 缓冲区中
援用
buffer.write(json, payloadOffset);
援用
return buffer;
援用
}
援用
module.exports = {
generateAcceptValue,
援用
parseMessage,
援用
constructReply,
援用
};

其实服务器向浏览器推送信息，除了应用 WebSocket 技术之外，还能够应用 SSE（Server-Sent Events）。它让服务器能够向客户端流式发送文本音讯，比方服务器上生成的实时音讯。

为实现这个指标，SSE 设计了两个组件：浏览器中的 EventSource API 和新的“事件流”数据格式（text/event-stream）。其中，EventSource 能够让客户端以 DOM 事件的模式接管到服务器推送的告诉，而新数据格式则用于交付每一次数据更新。

实际上：SSE 提供的是一个高效、跨浏览器的 XHR 流实现，音讯交付只应用一个长 HTTP 连贯。然而，与咱们本人实现 XHR 流不同，浏览器会帮咱们治理连贯、解析音讯，从而让咱们只关注业务逻辑。篇幅无限，对于 SSE 的更多细节，就不开展介绍了，对 SSE 感兴趣的小伙伴能够自行浏览以下几篇：

《Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《SSE 技术详解：一种全新的 HTML5 服务器推送事件技术》
《应用 WebSocket 和 SSE 技术实现 Web 端音讯推送》
《详解 Web 端通信形式的演进：从 Ajax、JSONP 到 SSE、Websocket》
《网页端 IM 通信技术疾速入门：短轮询、长轮询、SSE、WebSocket》
《搞懂古代 Web 端即时通讯技术一文就够：WebSocket、socket.io、SSE》

6、WebSocket 学习过程中的易错常识

6.1 WebSocket 与 HTTP 有什么关系？
WebSocket 是一种与 HTTP 不同的协定。两者都位于 OSI 模型的应用层，并且都依赖于传输层的 TCP 协定。

尽管它们不同，然而 RFC 6455 中规定：WebSocket 被设计为在 HTTP 80 和 443 端口上工作，并反对 HTTP 代理和中介，从而使其与 HTTP 协定兼容。为了实现兼容性，WebSocket 握手应用 HTTP Upgrade 头，从 HTTP 协定更改为 WebSocket 协定。

既然曾经提到了 OSI（Open System Interconnection Model）模型，这里分享一张很活泼、很形象形容 OSI 模型的示意图（如下图所示）。

（图片援用自：https://www.networkingsphere….）

当然，WebSocket 与 HTTP 的关系显然不是这三两句话能够说的清，有趣味的读者能够详读上面这两篇：

《WebSocket 详解（四）：刨根问底 HTTP 与 WebSocket 的关系(上篇)》
《WebSocket 详解（五）：刨根问底 HTTP 与 WebSocket 的关系(下篇)》

6.2 WebSocket 与长轮询有什么区别？
长轮询就是：客户端发动一个申请，服务器收到客户端发来的申请后，服务器端不会间接进行响应，而是先将这个申请挂起，而后判断申请的数据是否有更新。如果有更新，则进行响应，如果始终没有数据，则期待肯定的工夫后才返回。

长轮询的实质还是基于 HTTP 协定，它依然是一个一问一答（申请 — 响应）的模式。而 WebSocket 在握手胜利后，就是全双工的 TCP 通道，数据能够被动从服务端发送到客户端。

要了解 WebSocket 与长轮询的区别，须要深刻理解长轮询的技术原理，以下 3 篇中无关长轮询的技术介绍倡议深刻浏览：

《Comet 技术详解：基于 HTTP 长连贯的 Web 端实时通信技术》
《新手入门贴：史上最全 Web 端即时通讯技术原理详解》
《Web 端即时通讯技术盘点：短轮询、Comet、Websocket、SSE》
《网页端 IM 通信技术疾速入门：短轮询、长轮询、SSE、WebSocket》
6.3 什么是 WebSocket 心跳？
网络中的接管和发送数据都是应用 Socket 进行实现。然而如果此套接字曾经断开，那发送数据和接收数据的时候就肯定会有问题。

可是如何判断这个套接字是否还能够应用呢？这个就须要在零碎中创立心跳机制。

所谓“心跳”就是定时发送一个自定义的构造体（心跳包或心跳帧），让对方晓得本人“在线”，以确保链接的有效性。

而所谓的心跳包就是客户端定时发送简略的信息给服务器端通知它我还在而已。代码就是每隔几分钟发送一个固定信息给服务端，服务端收到后回复一个固定信息，如果服务端几分钟内没有收到客户端信息则视客户端断开。

在 WebSocket 协定中定义了 心跳 Ping 和 心跳 Pong 的管制帧：

1）心跳 Ping 帧蕴含的操作码是 0x9：如果收到了一个心跳 Ping 帧，那么终端必须发送一个心跳 Pong 帧作为回应，除非曾经收到了一个敞开帧。否则终端应该尽快回复 Pong 帧；
2）心跳 Pong 帧蕴含的操作码是 0xA：作为回应发送的 Pong 帧必须残缺携带 Ping 帧中传递过去的“利用数据”字段。
针对第 2）点：如果终端收到一个 Ping 帧然而没有发送 Pong 帧来回应之前的 Ping 帧，那么终端能够抉择仅为最近解决的 Ping 帧发送 Pong 帧。此外，能够主动发送一个 Pong 帧，这用作单向心跳。

PS：这里有篇 WebSocket 心跳方面的 IM 实战总结文章，有趣味能够浏览《Web 端即时通讯实际干货：如何让你的 WebSocket 断网重连更疾速？》。

6.4 Socket 是什么？
网络上的两个程序通过一个双向的通信连贯实现数据的替换，这个连贯的一端称为一个 Socket（套接字），因而建设网络通信连贯至多要一对端口号。

Socket 实质：是对 TCP/IP 协定栈的封装，它提供了一个针对 TCP 或者 UDP 编程的接口，并不是另一种协定。通过 Socket，你能够应用 TCP/IP 协定。

百度百科上对于 Socket 的形容是这样：

Socket 的英文原义是“孔”或“插座”：作为 BSD UNIX 的过程通信机制，取后一种意思。通常也称作”套接字“，用于形容 IP 地址和端口，是一个通信链的句柄，能够用来实现不同虚拟机或不同计算机之间的通信。
援用
在 Internet 上的主机个别运行了多个服务软件，同时提供几种服务。每种服务都关上一个 Socket，并绑定到一个端口上，不同的端口对应于不同的服务。Socket 正如其英文原义那样，像一个多孔插座。一台主机犹如布满各种插座的房间，每个插座有一个编号，有的插座提供 220 伏交流电，有的提供 110 伏交流电，有的则提供有线电视节目。客户软件将插头插到不同编号的插座，就能够失去不同的服务。

对于 Socket，能够总结以下几点：

1）它能够实现底层通信，简直所有的应用层都是通过 socket 进行通信的；
2）对 TCP/IP 协定进行封装，便于应用层协定调用，属于二者之间的两头形象层；
3）TCP/IP 协定族中，传输层存在两种通用协定: TCP、UDP，两种协定不同，因为不同参数的 socket 实现过程也不一样。

下图阐明了面向连贯的协定的套接字 API 的客户端 / 服务器关系：

PS：要说 WebSocket 和 Socket 的关系，这篇《WebSocket 详解（六）：刨根问底 WebSocket 与 Socket 的关系》有专门进行具体分享，倡议浏览。

7、参考资料

[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
[14] 搞懂古代 Web 端即时通讯技术一文就够：WebSocket、socket.io、SSE

本文已同步公布于“即时通讯技术圈”公众号。
同步公布链接是：http://www.52im.net/thread-37…