深刻探索WebSockets

WebSockets简介

在2008年中期，开发人员Michael Carter和Ian Hickson特别敏锐地感觉到Comet在实施任何真正强大的东西时所带来的痛苦和局限。 经过在IRC和W3C邮件列表上的合做，他们制定了一项计划，在网络上引入现代实时双向通讯的新标准，所以创造了“WebSocket”这个名称。

这个想法进入了W3C HTML草案标准，不久以后，Michael Carter写了一篇文章，将Comet社区介绍给WebSockets。 2010年，谷歌Chrome 4是第一个提供对WebSockets全面支持的浏览器，其余浏览器供应商也在接下来的几年中采用了这种方式。 2011年，RFC 6455 - WebSocket协议 - 发布到IETF网站。

今天，全部主流浏览器都彻底支持WebSockets，甚至包括Internet Explorer 10和11.此外，自2013年以来，iOS和Android上的浏览器都支持WebSockets，这意味着总而言之，WebSocket支持的现代环境很是健康。 大多数“物联网”或IoT也在某些版本的Android上运行，所以从2018年开始，其余类型设备上的WebSocket支持也至关广泛。

那么究竟什么是WebSockets呢？

简而言之，WebSockets是一个构建在设备TCP / IP堆栈之上的传输层。 目的是为Web应用程序开发人员提供本质上尽量接近原始的TCP通讯层，同时添加一些抽象来消除某些差别。 它们还知足了这样一个事实，即网络具备额外的安全考虑因素，必须将其考虑在内以保护消费者和服务提供者。

您可能据说WebSockets同时被称为“传输”和“协议”。前者更准确，由于虽然它们是一种协议，由于必须遵照一套严格的规则来创建通讯并包含所传输的数据，但该标准并无对如何构建实际数据有效载荷采起任何规定。事实上，规范的一部分包括客户端和服务器就一个协议达成一致的规范，传输的数据将经过该协议进行格式化和解释。该标准将这些称为“子协议”，以免术语中含糊不清的问题。子协议的示例是JSON，XML，MQTT，WAMP等。这些不只能够确保数据的结构方式，还能够确保通讯必须开始，继续并最终终止的方式。只要双方都了解协议所包含的内容，任何事情都会发生。 WebSocket仅提供传输层，经过该传输层能够实现该消息传递过程，这就是为何大多数常见的子协议不是基于WebSocket的通讯所独有的。

关于身份验证和受权的快速说明

把WebSockets看做是一个创建在TCP / IP之上的薄层，超出基本握手和消息框架规范的任何东西都须要在每一个应用程序或每一个库的基础上处理。 引用RFC：

此协议未规定服务器在WebSocket握手期间能够对客户端进行身份验证的任何特定方式。 WebSocket服务器可使用通用HTTP服务器可用的任何客户端身份验证机制，例如cookie，HTTP身份验证或TLS身份验证。

简而言之，您仍然可使用的基于HTTP的身份验证方法，或使用MQTT或WAMP等子协议，这两种子协议都提供身份验证和受权方法。

用HTTP作链接

定义WebSocket标准时的一个早期考虑因素是确保它“与网络”很好地协同工做。 这意味着认识到Web一般使用URL而不是IP地址和端口号进行寻址，而且WebSocket链接应该可以使用Web请求相同的基于HTTP的任何其余类型进行初始握手。

这是一个简单的HTTP GET请求中发生的事情。

假设在http://www.example.com/index....。 若是不深刻到HTTP协议自己，就足以知道请求必须从所谓的Request-Line开始，而后是一系列键值对标题行，每一行都告诉服务器一些关于什么的信息。 指望在随后的请求有效负载中跟随头数据，以及它能够从客户端获得的关于它可以理解的响应类型的内容。

请求中的第一个令牌是HTTP方法，它告诉服务器客户端针对引用的URL尝试的操做类型。 当客户端仅请求服务器向其提供由指定URL引用的资源的副本时，使用GET方法。

根据HTTP RFC格式化的请求标头的系统示例以下所示：

GET /index.html HTTP/1.1
Host: www.example.com

收到请求标头后，服务器而后格式化一个以状态行开头的响应标头，而后是一组键值标头对，为客户端提供来自服务器的补充信息，关于服务器的请求。 响应。 “状态行”告诉客户端HTTP状态代码（若是没有问题，一般为200），并提供解释状态代码的简短“缘由”文本描述。 接下来出现键值标题对，而后是请求的实际数据（除非状态代码代表因为某种缘由没法知足请求）。

HTTP/1.1 200 OK
Date: Wed, 1 Aug 2018 16:03:29 GMT
Content-Length: 291
Content-Type: text/html
(additional headers...)
 
(response payload continues here...)

那么你可能会问，这与WebSockets有什么关系呢？

抛弃HTTP以得到更合适的东西

在发出HTTP请求并接收响应时，涉及的实际双向网络通讯经过活动的TCP / IP套接字进行。浏览器中请求的Web URL经过全局DNS系统映射到IP地址，HTTP请求的默认端口为80.这意味着虽然Web URL已输入浏览器，但实际通讯是经过TCP进行的/ IP，使用相似于123.11.85.9:80的IP地址和端口组合。

咱们如今知道，WebSockets也创建在TCP堆栈之上，这意味着咱们所须要的只是客户端和服务器共同赞成保持套接字链接打开并从新利用它以进行持续通讯的方式。若是他们这样作，就能够发送和接收的二进制数据。

要开始从新调整TCP套接字以进行WebSocket通讯，客户端能够包含专门为此类用例发明的标准请求标头：

GET /index.html HTTP/1.1
Host: www.example.com
Connection: Upgrade
Upgrade: websocket

Connection标头告诉服务器客户端但愿协商套接字使用方式的更改。 随附的值Upgrade表示当前经过TCP使用的传输协议应该更改。 如今服务器知道客户端想要经过活动TCP套接字升级当前正在使用的协议，服务器知道要查找相应的升级头，这将告诉它客户端想要使用哪一个传输协议的剩余生命周期 链接。 一旦服务器将websocket视为Upgrade标头的值，它就知道WebSocket握手过程已经开始。

请注意，若是您想了解本文中介绍的更多详细信息，请参阅RFC 6455中概述了握手过程（以及其余全部内容）。

避免有趣的麻烦

除了上面描述的内容以外，WebSocket握手的第一部分涉及证实这其实是一个正确的WebSocket升级握手，而且该过程不是经过客户端或可能经过某种中间欺骗来规避或模拟的。 位于中间的代理服务器。

启动升级到WebSocket链接时，客户端必须包含Sec-WebSocket-Key标头，该标头具备该客户端惟一的值。 这是一个例子：

Sec-WebSocket-Key: BOq0IliaPZlnbMHEBYtdjmKIL38=

若是使用现代浏览器中提供的WebSocket类，上面的内容将自动处理。 您只需在服务器端查找它并生成响应。

响应时，服务器必须将特殊GUID值258EAFA5-E914-47DA-95CA-C5AB0DC85B11附加到密钥，生成结果字符串的SHA-1哈希值，而后将其包含为Sec的base-64编码值。 它包含在响应中的WebSocket-Accept标头：

Sec-WebSocket-Accept: 5fXT1W3UfPusBQv/h6c4hnwTJzk=

在Node.js WebSocket服务器中，咱们能够编写一个函数来生成这个值，以下所示：

const crypto = require('crypto');
 
function generateAcceptValue (acceptKey) {
  return crypto
    .createHash('sha1')
    .update(acceptKey + '258EAFA5-E914-47DA-95CA-C5AB0DC85B11', 'binary')
    .digest('base64');
}

而后咱们只须要调用这个函数，传递Sec-WebSocket-Key头的值做为参数，并在发送响应时将函数返回值设置为Sec-WebSocket-Accept头的值。

要完成握手，请将适当的HTTP响应头写入客户端套接字。 一个简单的响应看起来像这样：

HTTP/1.1 101 Web Socket Protocol Handshake
Upgrade: WebSocket
Connection: Upgrade
Sec-WebSocket-Accept: m9raz0Lr21hfqAitCxWigVwhppA=

到目前为止，咱们尚未完成握手 - 还有不少事情要考虑。

子协议 - 统一语言

客户端和服务器一般须要在给定消息内以及从一个消息到下一个消息的一段时间内，就它们如何格式化，解释和组织数据自己的兼容策略达成一致。 这就是子协议（前面提到过）的用武之地。若是客户端知道它能够处理一个或多个特定的应用程序级协议（例如WAMP，MQTT等），它能够包含它理解的协议列表。 发出初始HTTP请求。 若是它这样作，则服务器须要选择其中一个协议并将其包含在响应头中，不然将使握手失败并终止链接。

子协议请求标头示例：

Sec-WebSocket-Protocol: mqtt, wamp

服务器在响应中发出的示例倒数标题：

Sec-WebSocket-Protocol: wamp

请注意，服务器必须从客户端提供的列表中精确选择一种协议。选择多个将意味着服务器没法可靠或一致地解释后续WebSocket消息中的数据。例如，若是服务器选择了json-ld和json-schema。二者都是基于JSON标准构建的数据格式，而且会有许多边缘状况，其中一个可能被解释为另外一个，从而在处理数据时致使意外错误。虽然不能否认自己不是消息传递协议，但该示例仍然适用。

当客户端和服务器都实现为从一开始就使用通用消息传递协议时，能够在初始请求中省略Sec-WebSocket-Protocol标头，在这种状况下服务器能够忽略此步骤。在实现通用服务，基础结构和工具时，子协议协商是最有用的，在这些服务，基础结构和工具中，一旦创建了WebSocket链接，就没法保证客户端和服务器都能相互理解。

通用协议的标准化名称应在IANA注册中心注册，用于WebSocket子协议名称，在本文撰写时，已经注册了36个名称，包括soap，xmpp，wamp，mqtt等。尽管注册表是将子协议名称映射到其解释的规范来源，但惟一严格的要求是客户端和服务器就其相互选择的子协议实际意味着什么达成一致，不管它是否出如今IANA注册表中。

请注意，若是客户端请求使用子协议但未提供服务器能够支持的任何内容，则服务器必须发送失败响应并关闭链接。

WebSocket扩展

还有一个标题用于定义数据有效负载编码和成帧方式的扩展，但在本文时，只存在一种标准化扩展类型，它提供了一种WebSocket - 等同于消息中的gzip压缩。 扩展可能发挥做用的另外一个例子是多路复用 - 使用单个套接字来交错多个并发通讯流。

WebSocket扩展是一个有点高级的主题，而且超出了本文的范围。 如今，它足以知道它们是什么，以及它们如何适应图片。

客户端 - 在浏览器中使用WebSockets

WebSocket API在WHATWG HTML Living Standard中定义，实际上很是简单易用。 构造WebSocket须要一行代码：

const ws = new WebSocket('ws://example.org');

注意使用ws，你一般有http方案。 您也能够选择使用wss，一般使用https。 这些协议与WebSocket规范一块儿引入，旨在表示HTTP链接，其中包括升级链接以使用WebSockets的请求。

建立WebSocket对象自己并无作不少事情。 链接是异步创建的，所以您须要在发送任何消息以前侦听握手的完成，而且还包括从服务器接收的消息的侦听器：

ws.addEventListener('open', () => {
  // Send a message to the WebSocket server
  ws.send('Hello!');
});
 
ws.addEventListener('message', event => {
  // The `event` object is a typical DOM event object, and the message data sent
  // by the server is stored in the `data` property
  console.log('Received:', event.data);
});

还有错误和关闭事件。 链接终止时WebSockets不会自动恢复 - 这是您须要本身实现的，而且是存在许多客户端库的缘由之一。 虽然WebSocket类简单易用，但它实际上只是一个基本的构建块。 必须单独实现对不一样子协议或消息传递通道等附加功能的支持。

生成和解析WebSocket消息帧

一旦将握手响应发送到客户端，客户端和服务器就可使用他们选择的子协议（若是有的话）开始通讯。

WebSocket消息在名为“frames”的包中传递，这些包以消息头开头，并以“payload”结尾 - 此帧的消息数据。 大型消息可能会将数据分红几帧，在这种状况下，您须要跟踪到目前为止收到的内容，并在数据所有到达后将数据分组。

翻译的很乱，希望对你有点帮助

建立了一个程序员交流微信群，你们进群交流IT技术

若是已过时，能够添加博主微信号15706211347，拉你进群