编写 WebSocket 服务器

首先，服务器必须使用标准的 TCP 套接字来监听传入的套接字连接。根据你的平台，这可能已经为你处理。例如，假设你的服务器正在监听 example.com，端口 8000，并且你的套接字服务器响应/chat上的 GET 请求。 .

握手是 WebSockets 中的“Web”。这是从 HTTP 到 WS 的桥梁。在握手过程中，有关连接的详细信息正在初始化中，如果条件不利，任何一方可以在完成之前退出。服务器必须小心了解客户要求的一切，否则会产生安全问题。

即使你正在构建服务器，客户端仍然必须启动 WebSocket 握手过程。所以你必须知道如何解释客户的请求。客户端将发送一个相当标准的 HTTP 请求，看起来像这样（HTTP 版本必须是 1.1 或更高，方法必须是GET）：

GET /chat HTTP/1.1
Host: example.com:8000
Upgrade: websocket
Connection: Upgrade
Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
Sec-WebSocket-Version: 13

客户可以在这里请求扩展和/或子协议；详情请见杂项。当然，你也可以在这里加上你所需要的一般请求头如User-Agent， Referer， Cookie或者认证头。WebSocket 没有作要求，忽略它们也是安全的。在大多数情况下，反向代理已经做了这些处理。

如果任何请求头信息不被理解或者具有不正确的值，则服务器应该发送“400 Bad Request”并立即关闭套接字。像往常一样，它也可能会给出 HTTP 响应正文中握手失败的原因，但可能永远不会显示消息（浏览器不显示它）。如果服务器不理解该版本的 WebSocket，则应该发送一个Sec-WebSocket-Version头，其中包含它理解的版本。（本指南解释了最新的 v13）。下面我们来看看奇妙的请求头Sec-WebSocket-Key。

当服务器收到握手请求时，它应该发回一个特殊的响应，表明协议将从 HTTP 变为 WebSocket。看起来像这样（记住每个请求头以 \r\n结尾，并在最后一个之后放置一个额外的 \r\n）：

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

另外，服务器可以在这时候决定插件或子协议，详情参见杂项。 Sec-WebSocket-Accept 参数很有趣，它需要服务器通过客户端发送的Sec-WebSocket-Key 计算出来。怎样计算呢，把客户发送的 Sec-WebSocket-Key 和 "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" (这个叫做 "魔法值") 连接起来，把结果用SHA-1编码，再用base64编码一次，就可以了。

所以如果 Sec-WebSocket-Key 是“dGhlIHNhbXBsZSBub25jZQ==”，Sec-WebSocket-Accept 将是“s3pPLMBiTxaQ9kYGzzhZRbK+xOo=”。一旦服务器发送这个请求头，握手就完成了，你可以开始交换数据！

这并不直接与 WebSocket 协议相关，但是在这里值得一提的是：你的服务器将不得不跟踪客户的套接字，所以你不会再和已经完成握手的客户握手。同一个客户端 IP 地址可以尝试连接多次（但是如果客户端尝试过多的连接，服务器可以拒绝它们以免遭拒绝服务攻击）。

客户端或服务端都可以在任何时间点发送数据——这就是 WebSocket 的魅力。然而，从这些被称为“帧”的数据中提取信息就不是十分愉快的体验了。尽管所有的帧都遵从相同的格式规范，从客户端发送到服务端的数据都被 异或加密（用一个 32 位的 key）格式化。详情请参见规范的第 5 节。

每个数据帧（从客户端到服务器，反之亦然）遵循相同的格式：

Frame format:

      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 ...                |
     +---------------------------------------------------------------+

掩码明确告知我们消息是否经过格式化。从客户端来的消息必须经过格式化，所以你的服务器必须要求这个掩码是 1（事实上，规范 5.1 节规定了如果客户端发送了没有格式化的消息，你的服务器应该断开连接）

当向客户端发送帧时，不要对其进行掩码，也不要设置掩码位。稍后我们将解释屏蔽。注意：即使使用安全套接字，也必须屏蔽消息。RSV1-3 可以忽略，它们是用于扩展的。

操作码字段定义了如何解释有效负载数据:0x0 表示延续，0x1 表示文本 (总是用 UTF-8 编码)，0x2 表示二进制，以及其他所谓的“控制代码”，稍后将对此进行讨论。在这个版本的 WebSockets 中，0x3 到 0x7 和 0xB 到 0xF 没有任何意义。

FIN 位告诉我们这是不是系列的最后一条消息。如果是 0，那么服务器将继续侦听消息的更多部分;否则，服务器应该考虑传递的消息。不仅仅是这样。

要读取有效负载数据，你必须知道何时停止读取。这就是为什么有效载荷长度很重要。不幸的是，这有点复杂。要阅读它，请遵循以下步骤：

1. 读取 9-15(包括) 位并将其解析为无符号整型。如果长度小于等于 125，那么就是长度;你就完成了。如果是 126，到第二步。如果是 127，到步骤 3。
2. 读取下面的 16 位，并将其解释为无符号整型。你就完成了。
3. 读取接下来的 64 位，并将其解释为无符号整型 (最重要的位必须为 0)。

如果设置了掩码位 (对于客户机到服务器的消息应该是这样)，则读取接下来的 4 个字节 (32 位);这是掩蔽键。一旦有效负载长度和掩蔽键被解码，你就可以继续从套接字读取字节数。让我们调用已编码的数据和密钥掩码。要获得解码，可以通过编码的八位元 (字节，即文本数据的字符) 和 XOR 八位元 (i 模 4) 掩码的第四个八位元进行循环。在伪代码中 (恰好是有效的 JavaScript):

var DECODED = "";
for (var i = 0; i < ENCODED.length; i++) {
  DECODED[i] = ENCODED[i] ^ MASK[i % 4];
}

现在，你可以根据应用程序了解解码意味着什么。

FIN 和操作码字段一起工作，以发送分裂为独立帧的消息。这称为消息碎片。片段只能在操作码 0x0 到 0x2 上可用。

回想一下，操作码告诉了帧应该做什么。如果是 0x1，有效载荷就是文本。如果是 0x2，有效载荷就是二进制数据。但是，如果是 0x0，则该帧是一个延续帧。这意味着服务器应该将帧的有效负载连接到从该客户机接收到的最后一个帧。下面是一个粗略的示意图，其中服务器对发送文本消息的客户机做出反应。第一个消息在单个帧中发送，而第二个消息跨三个帧发送。FIN 和操作码的详细信息只显示给客户：

Client: FIN=1, opcode=0x1, msg="hello"
Server: (process complete message immediately) Hi.
Client: FIN=0, opcode=0x1, msg="and a"
Server: (listening, new message 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 new year to you too!

注意，第一个框架包含一个完整的消息 (具有 FIN=1 和 opcode!=0x0)，因此服务器可以根据需要进行处理或响应。客户机发送的第二帧具有文本有效负载 (opcode=0x1)，但是整个消息还没有到达 (FIN=0)。该消息的所有剩余部分都用延续帧 (opcode=0x0) 发送，消息的最终帧用 FIN=1 标记。Section 5.4 of the spec描述了消息帧。

在经过握手之后的任意时刻里，无论客户端还是服务端都可以选择发送一个 ping 给另一方。当 ping 消息收到的时候，接受的一方必须尽快回复一个 pong 消息。例如，可以使用这种方式来确保客户端还是连接状态。

一个 ping 或者 pong 都只是一个常规的帧，只是这个帧是一个控制帧。Ping 消息的 opcode 字段值为 0x9，pong 消息的 opcode 值为 0xA 。当你获取到一个 ping 消息的时候，回复一个跟 ping 消息有相同载荷数据的 pong 消息 (对于 ping 和 pong，最大载荷长度位 125)。你也有可能在没有发送 ping 消息的情况下，获取一个 pong 消息，当这种情况发生的时候忽略它。

客户端或服务器端都可以通过发送一个带有指定控制序列的控制帧以开始关闭连接握手（参见章节 5.5.1）。对端收到这个控制帧会回复一个关闭帧，关闭发起端关闭连接。任何在关闭连接后接收到的数据都会被丢弃。

WebSocket 扩展和子协议是在握手过程中通过头信息进行协商的。有时候，扩展和子协议看起来太相似而不可能是不同的东西，但是有一个明显的区别。扩展控制 WebSocket 框架并修改有效负载，而子协议构造 WebSocket 有效负载，从不修改任何东西。扩展是可选的和通用的 (比如压缩);子协议是强制性的和本地化的 (就像聊天和 MMORPG 游戏一样)。

Think of an extension as compressing a file before e-mailing it to someone. Whatever you do, you're sending the same data in different forms. The recipient will eventually be able to get the same data as your local copy, but it is sent differently. That's what an extension does. WebSockets defines a protocol and a simple way to send data, but an extension such as compression could allow sending the same data but in a shorter format.

可以把子协议理解成一个自定义XML schema或文件类型声明。你仍然使用 XML 和它的语法，但是还要额外受限于你声明的格式。

WebSocket 子协议就是像这样的东西。它们不作任何假设实现，只是确立框架。就像一个文件类型或概要。与文件类型或概要类似，通信双方都需要同意子协议；于文件类型或概要不同的是，子协议在服务端实现，而不能由客户端参考第三方。

如果客户端需要指定子协议，需要发送如下消息头作为握手信息的一部分：

GET /chat HTTP/1.1
...
Sec-WebSocket-Protocol: soap, wamp

等价于：

...
Sec-WebSocket-Protocol: soap
Sec-WebSocket-Protocol: wamp

现在，服务端需要选择一个客户端建议且服务端支持的子协议。如果有多于一个的话使用客户端发送的第一个。如果我们的服务端可以支持soap和wamp，则在握手回复时，它会发送：

Sec-WebSocket-Protocol: soap

如果你希望你的服务器遵守某些子协议，那么很自然地，你需要服务器上的额外代码。假设我们使用的是子协议 JSON。在这个子协议中，所有数据都以 JSON 的形式传递。如果客户端请求这个协议，而服务器想要使用它，服务器将需要一个 JSON 解析器。实际上，这是库的一部分，但是服务器需要传递数据。

• WebSocket handshake library in C++
• Tutorial: Websocket server in C#
• Writing WebSocket client applications
• Tutorial: Websocket server in VB.NET