Delphi 的Websocket Server 控件实现（一、WebSocket 原理）（含源码）

目录

一、WebSocket 原理

1、握手handshaking）

2、数据通信

3、通讯示例

二、WebSocket 通信需要注意点说明

1、关于帧段（碎片）规则说明

2、通信示例

待续...

---

一、WebSocket 原理

关于控件的源码下载见《Delphi 的Websocket Server 控件实现（四、WebSocket Demo程序使用说明）》

WebSocket 标准使用 UTF8编码通信，切记！

关于WebSocket 的原理，主要是RFC 6455标准，该标准的原文参见官方：RFC 6455（2011.11），如果大家不好下载，可以直接下载这个链接：WebSoket_协议(rfc6455).pdf（71页）

WebSocket 是 HTML5 开始提供的一种在单个 TCP 连接上进行全双工通讯的协议。关于WebSocket浏览器端javascript的实现使用请参见《菜鸟教程》的HTML5 WebSocket，说的非常清楚。

WebSocket 是独立的、创建在 TCP 上的协议。

Websocket 通过HTTP/1.1 协议的101状态码进行握手。

为了创建Websocket连接，需要通过浏览器发出请求，之后服务器进行回应，这个过程通常称为“握手”（handshaking）。

握手完成之后，客户端和服务器就建立了持久连接，可以进行通信，除非任何一端主动断开。在通信过程中，客户端发给服务器端的数据是需要掩码计算的，而服务器端发给客户端的不需要。

1、握手handshaking）

客户端主动发起，客户端会给服务器端发送类似如下文本数据：

GET / HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: 127.0.0.1:3002
Origin: http://127.0.0.1:8020
Pragma: no-cache
Cache-Control: no-cache
Sec-WebSocket-Key: Zi5YEXnU4yRo6R4hg1Wsdw==
Sec-WebSocket-Version: 13
Sec-WebSocket-Extensions: permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.138 Safari/537.36

      注意客户端发送的是 GET / HTTP/1.1 打头命令，必须告诉服务器端Upgrade为websocket，Connection为Upgrade，这样服务器端就知道客户端需要进行websocket通信，此时服务器端需要取得Sec-WebSocket-Key中的钥匙串Zi5YEXnU4yRo6R4hg1Wsdw==，通过和“258EAFA5-E914-47DA-95CA-C5AB0DC85B11”连接再SHA-1签名后Base64编码返回给客户端，客户端验证通过就完成了握手流程。

Zi5YEXnU4yRo6R4hg1Wsdw==258EAFA5-E914-47DA-95CA-C5AB0DC85B11，对这个字符串进行SHA-1签名再Base64编码，注意连接两个字符串的时候中间不能有空格。结果为：hUfGucluAOxLIDaafqTtjEZFjMs=，见下面。

服务器返回给客户端的数据如下：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Accept: hUfGucluAOxLIDaafqTtjEZFjMs=

服务器返回101结果，同时继续返回Connection和Upgrade字段，并且返回经过签名的结果：hUfGucluAOxLIDaafqTtjEZFjMs=

2、数据通信

在数据通信过程中，使用的是帧概念，帧数据有结构规范。一个完整的数据帧，可以通过几个小帧段组成，基本的帧结构如下：

FIN：1bit  表示是不是最后一个帧段，1表示是，否则表示不是。

RSV1、RSV2、RSV3：1 bit each  暂时不需要关注，默认是0，都是一位。

Opcode： 4 bits 定义实际帧数据的类型：

           0 : 表示是一个连续的Frame
           1 : 表示是一条文本消息
           2 : 表示是流消息
           3-7 : 保留
           8 : 表示一个连接关闭
           9 : 一个ping
           A : 一个pong
           B-F : 保留  

Mask：1 bit  表示数据是否需要进行反掩码接开，1表示需要，0表示不需要

Payload length：7 bits, 7+16 bits, or 7+64 bits 这个理解上需要转换下。如果此值介于0和125之间，则为消息的长度。如果是126，则以下2个字节（16位无符号整数）是长度。如果是127，则以下8个字节（64位无符号整数）是长度。

Masking-key： 0 or 4 bytes  从客户端发送到服务器端的所有数据都包含这4个字节，此时上面的Mask位设置也必须为1，服务器端需要通过这4个字节对后续数据进行反掩码计算。如果Mask位为0，则不包含这4个字节，表示数据无需进行反掩码运算，服务器端到客户端的数据都是这样的。

Payload data：实际的数据字节流。

3、通讯示例

假如客户端需要给服务器端发送4个字母：SZHN，那么服务器端实际收到的数据为：(129, 132, 91, 168, 122, 85, 8, 242, 50, 27)

转换为HEX就是（$81,$84,$5B,$A8,$7A,$55,$08,$F2,$32,$1B）根据协议解释如下：

129（$81） = 1 0 0 0 0 0 0 1     前面的第一个1表示的是FIN，这是最后一帧数据，最后面的4bit也是1，表示这是一个文本消息。

132（$84）= 1 0 0 0 0 1 0 0     前面的1表示Mask位，这说明随后会有4个字节的Masking-key，需要进行反掩码计算，后面的000100就是4，表示的数据长度为4，因为我们发送的就是SZHN这4个字符。

91， 168，122，85  表示的是Masking-key，需要用这4个字节循环对后续的数据进行xor反掩码计算。

8，242， 50， 27 表示数据，进行反掩码后得到的数据如下：

91 xor 8 = 83 (S)   168 xor 242 = 90 (Z)  122 xor 50 = 72 (H)   85 xor 27 = 78 (N)，接出来的结果正好是SZHN。

二、WebSocket 通信需要注意点说明

1、关于帧段（碎片）规则说明

对于一帧数据(Frame)，可以分成几个帧段（碎片fragmentation）发送，这样的话，规则定义如下：

• 非分段消息由带有FIN（FIN必须设置为1）的单个框架组成和0以外的操作码；
• 分段消息由一个带有FIN位为0并输入一个非0的操作码，后跟零个或多个帧FIN位清除，操作码设置为0，终止于一个FIN位设置为1和0操作码的单帧

举例如下：对于作为三个片段发送的文本消息，第一个片段的操作码为0x1，FIN位为0；第二个片段的操作码为0x0，FIN位为0，
    第三个片段有一个0x0操作码和一个FIN位为1，说明整个数据已经准备好了。

2、通信示例

编码	类型	示例
1	单一非掩码帧	0x81 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello")
2	单一掩码帧	0x81 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 (contains "Hello")
3	帧段（碎片）非掩码帧	0x01 0x03 0x48 0x65 0x6c (contains "Hel") 0x80 0x02 0x6c 0x6f (contains "lo")
4	非掩码ping请求和掩码ping返回	0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello",内容随意) 0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 (contains a body of "Hello", 必须匹配请求)
5	一帧中包含256个非掩码二进制数据	0x82 0x7E 0x0100 [256 bytes of binary data]
6	一帧包含64K非掩码二进制数据	0x82 0x7F 0x0000000000010000 [65536 bytes of binary data]

继续....