1. WebSocket简介 {#1-WebSocket简介} ===============================

WebSocket 是一种全双工通信协议，允许客户端和服务器之间建立持久化的双向通信连接。WebSocket 协议设计的初衷是解决 HTTP 协议在实时交互上的局限性，例如长轮询、Ajax 等方法的高延迟问题。WebSocket 可以在单个 TCP 连接上实现客户端与服务器之间的实时、低延迟的数据传输。

1.1 单工、半双工和双工 {#1-1-单工、半双工和双工}

这三个术语用于描述通信的方向性，主要适用于数据传输和网络通信。它们的定义如下：

1. 单工（Simplex）：单工通信是单向的，数据只能从发送方传送到接收方，而无法反向传输，通信过程不支持回复或反馈。

   • 电视广播：信号从发射台发送到电视，但观众无法向发射台发送信号。

   • 传统的广播电台：信号从发射台发送到收音机，但听众无法向发射台发送信号。

2. 半双工（Half-Duplex）：半双工通信是双向的，但在任意时刻只能有一个方向的数据传输。发送方和接收方可以交替发送和接收数据，但不能同时进行。

   • 对讲机：一个人说话时，另一方需要等待，直到说话者结束才能回复。

3. 双工（Full-Duplex）：双工通信是完全双向的，数据可以同时在两个方向传输。发送方和接收方可以同时发送和接收数据。

   • 电话通话：两人可以同时讲话和听到对方的声音。

   • 网络通信（如以太网）。

因此，关于单工、半双工、双工通信的方向性我们可以做如下总结：

• 单工：单向通信，无法反馈。
• 半双工：双向通信，但不能同时进行。
• 双工：双向通信，可以同时进行。

所以，我们可以根据不同的应用场景，选择合适的通信方式来提高数据传输的效率和用户体验。

1.2 Http的局限性 {#1-2-Http的局限性}

HTTP（超文本传输协议）是一种用于传输数据的协议，但它也有一些局限性，主要包括以下几点：

1. 无状态性

   HTTP 是一种无状态协议，每个请求都是独立的，不会保留客户端的上下文信息。这使得实现用户会话和状态管理变得复杂，需要额外的机制（如 cookies 或 sessions）。

2. 性能问题

   • 延迟：每次请求都需要重新建立连接，尤其是在使用 HTTP/1.1 时，存在多个请求时会造成额外的延迟。
   • 带宽浪费：每次请求都需要发送请求头，增加了网络带宽的消耗。

3. 安全性

   加密不足：传统的 HTTP 传输是明文的，数据在传输过程中容易被窃听和篡改。虽然可以通过 HTTPS（HTTP Secure）来增强安全性，但 HTTP 本身并不提供加密。

4. 不支持双向通信

   HTTP 是请求-响应模型 ，客户端发起请求后，服务器才能响应，不支持实时双向通信。这在需要即时数据传输的应用中（如聊天应用）造成了限制。

5. 请求重定向和缓存管理的复杂性

   在复杂的应用中，HTTP 请求的重定向和缓存管理可能导致性能下降和数据一致性问题，增加了开发和维护的复杂性。

6. 适应性差

   HTTP 的设计初衷是用于静态网页的传输，对于现代动态内容和实时应用（如流媒体、在线游戏等）支持不够灵活。

虽然 HTTP 是互联网通信的基础，但其局限性促使开发者寻求更高效、更安全的替代方案，如 WebSocket、HTTP/2 和 HTTP/3 等。理解这些局限性有助于在设计系统时做出更明智的选择。

2. WebSocket 协议 {#2-WebSocket-协议} =================================

2.1 协议标准 {#2-1-协议标准}

WebSocket 是基于 TCP 的协议 ，定义在 IETF 的 RFC 6455 标准中后由 RFC 7936 补充规范。。WebSocket 的连接从一个标准的 HTTP 请求开始，经过一次协议升级后，建立起一个全双工的 WebSocket 连接。

WebSocket 默认使用以下两个端口：

• 80 端口 ：非加密的 WebSocket 协议，使用 ws:// 开头的 URL。
• 443 端口 ：加密的 WebSocket 协议（通过 TLS/SSL 加密），使用 wss:// 开头的 URL。

WebSocket 的 URL 格式与 HTTP 类似，但有一些特定的细节。以下是 WebSocket URL 的基本结构：

|-----------|-----------------------------------| | 1 | ws://[host]:[port]/[path] |

可以看到 WebSocket 的 URL 一共由四部分构成，下面是关于它们的具体说明：

1. 协议 ：
   • ws://：表示 WebSocket 协议。
   • wss://：表示 WebSocket Secure（加密的 WebSocket），类似于 HTTPS。
2. 主机（host） ：
   • 服务器的域名或 IP 地址，例如 example.com 或 192.168.1.100。
3. 端口（port） （可选）：
   • WebSocket 默认端口是 80（ws）和 443（wss），可以省略。如果使用其他端口，则需要显式指定，例如 :8080。
4. 路径（path） ：
   • 服务器上用于 WebSocket 连接的具体路径，例如 /socket。

下面是几个关于 WebSocket URL 格式的几个示例：

1. 非加密的 WebSocket 连接：

   |-----------|---------------------------------| | 1 | ws://example.com/socket |

2. 加密的 WebSocket 连接：

   |-----------|----------------------------------| | 1 | wss://example.com/socket |

3. 指定端口的连接：

   |-----------|--------------------------------------| | 1 | ws://example.com:8080/socket |

4. 带路径的连接：

   |-----------|---------------------------------------| | 1 | wss://example.com/api/v1/chat |

WebSocket URL 的格式与 HTTP URL 类似，主要区别在于使用的协议前缀（ws 或 wss）。使用时要确保服务器能够处理 WebSocket 连接，并在前端正确配置 URL。

2.2 工作原理 {#2-2-工作原理}

2.2.1 握手阶段 {#2-2-1-握手阶段}

WebSocket 连接从 HTTP 请求开始，客户端通过 HTTP 升级机制请求升级协议：

1. 客户端发起 HTTP 请求，并在请求头中包含特定的 WebSocket 字段以表示希望建立 WebSocket 连接。

   示例Http请求消息（部分）：

   |---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 | GET /chat HTTP/1.1 Host: example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Sec-WebSocket-Version: 13 |

   关键字段说明：

   • Upgrade: websocket：表示希望将协议升级为 WebSocket。

   • Connection: Upgrade：告知服务器此次连接希望协议升级。

   • Sec-WebSocket-Key：客户端生成的随机密钥，用于服务器生成握手应答的 Sec-WebSocket-Accept。

   • Sec-WebSocket-Version：指定 WebSocket 的版本，当前标准版本是 13。

2. 服务器收到请求后，返回 101 状态码，并附带确认的握手信息。

   示例 http响应消息（部分）：

   |-----------------|------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 | HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= |

   关键字段说明：

   • HTTP/1.1 101 Switching Protocols ：状态行，它由三个部分组成：

     1. 协议版本 ：HTTP/1.1 表示使用的 HTTP 版本。
     2. 状态码 ：101 是状态码，表示服务器已接受客户端的请求并正在切换协议。
     3. 状态描述 ：Switching Protocols 是对状态码的描述，说明了服务器的响应内容。

   • Sec-WebSocket-Accept：由 Sec-WebSocket-Key 和特定算法生成的哈希值，用于确认握手的安全性。

2.2.2 数据帧传输 {#2-2-2-数据帧传输}

WebSocket 的数据通过帧 (frame) 进行传输（"帧"是指在客户端和服务器之间传输的数据单元）。每一帧都有固定的格式，包含数据以及控制信息。WebSocket 支持以下几种帧类型：

• 文本帧（Text Frame）：用于传输文本数据，通常是 UTF-8 编码的字符串。
• 二进制帧（Binary Frame）：用于传输二进制数据，如图片、音视频数据等。
• 关闭帧（Close Frame）：用于关闭连接。
• Ping 和 Pong 帧：用于检测连接的活跃性，Ping 由客户端或服务器发送，Pong 由对方响应。

每个 WebSocket 数据帧的格式如下：

|------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | 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 ... | +---------------------------------------------------------------+ |

• FIN : （1bit），表示是否为最后一帧。如果为1，表示这是最后一帧；如果为0，表示后面还有帧。
• RSV1, RSV2, RSV3 ：（各1bit）保留位，用于扩展协议。通常在初始实现中，这些位应设置为0。
• Opcode : （4bit），用于表示帧的类型。
  • 0x0：继续帧
  • 0x1：文本帧
  • 0x2：二进制帧
  • 0x3~0x7：预留给以后的非控制帧
  • 0x8：连接关闭帧
  • 0x9：Ping 帧
  • 0xA：Pong 帧
  • 0xB~0xF：预留给以后的控制帧
• Mask : （1bit），表示是否对数据进行掩码处理。
  • 客户端到服务器的消息必须使用掩码
  • 服务器到客户端的消息不需要使用掩码
• Payload length : （7bit/7+16bit/7+64bit），表示数据的长度。
  • 当它的值在 0 到 125 之间时，表示有效负载的字节数。
  • 当它的值是 126（0x7E）时，表示后面将有 2 字节（16 位）来表示有效负载的真实长度（有效负载长度在 0 到 65535 之间）。
  • 当它的值是 127（0x7F）时，则表示后面会有 8 字节（64 位）来表示有效负载的真实长度。
• Masking Key ：（0或4bytes）
  • 所有从客户端发往服务端的数据帧都已经与一个包含在这一帧中的32 bit的掩码进行了运算。
  • 如果mask标志位（1 bit）为1，那么这个字段存在，如果标志位为0，那么这个字段不存在。
• Payload data ：实际传输的数据，根据Payload length字段的值来确定长度。

2.2.3 保持连接与心跳 {#2-2-3-保持连接与心跳}

WebSocket 在建立连接后会保持连接状态，直到一方显式关闭连接。为了防止连接由于网络问题或闲置超时而断开，WebSocket 支持通过 Ping-Pong 机制 来检测连接的活跃性。客户端或服务器可以发送一个 Ping 帧，接收方必须在合理时间内响应一个 Pong 帧，确保连接仍然正常。

Ping-Pong 机制的示例流程:

1. 客户端发送 Ping 帧 :
   • 客户端发送一个 Ping 帧，Payload Data 可能包含当前时间戳。
   • 帧格式：FIN=1, Opcode=0x9, Mask=1, Payload Data=时间戳
2. 服务器接收并响应 Pong 帧 :
   • 服务器接收到 Ping 帧后，立即发送一个 Pong 帧，Payload Data 与接收到的 Ping 帧的 Payload Data 相同。
   • 帧格式：FIN=1, Opcode=0xA, Mask=0, Payload Data=时间戳
3. 客户端接收 Pong 帧 :
   • 客户端接收到 Pong 帧后，可以确认连接仍然活跃。
   • 客户端可以根据时间戳计算往返时间（RTT），以评估网络延迟。

在使用 WebSocket 协议的 Ping-Pong 机制的时候，有以下事项需要再次强调：

1. 双向检测:

   客户端和服务器都可以发送 Ping 帧，并期望对方发送 Pong 帧。这使得双方都能检测到连接的活跃性。

2. 超时处理:

   如果发送 Ping 帧的一方在一定时间内没有收到 Pong 帧，可以认为连接已经断开或不活跃，并采取相应的措施（如关闭连接或重新连接）。

3. Payload Data:

   Ping 和 Pong 帧的 Payload Data 是可选的，但通常会包含一些简单的数据（如时间戳），以便双方能够进行更详细的检测和分析。

2.2.4 关闭连接 {#2-2-4-关闭连接}

WebSocket 连接关闭时，双方需要发送一个关闭帧（Close Frame）。关闭帧包含一个关闭码和关闭原因，可以用于表明连接关闭的原因。具体来说，关闭帧的格式遵循 WebSocket 协议规范，其中状态码的位置和结构如下：

1. FIN 位: 1 bit
2. RSV 位: 3 bits (保留位，一般用于扩展)
3. Opcode : 4 bits (对于关闭帧，值为 0x8)
4. MASK: 1 bit (指示消息是否被掩码，客户端消息必须掩码)
5. Payload length: 7 bits, 7+16 bits, 或 7+64 bits (指示随后的有效负载的长度)
6. Masking key: 0或4 bytes (如果 MASK 位为 1，则使用，包含用于掩码的密钥)
7. Payload data : (长度通过 Payload length 指定)
   • 关闭状态码 : 在关闭帧的有效负载部分的最开始，紧接在 Payload length 字段后面。这两个字节 （未经掩码处理）表示状态码（Close Code）。
   • 关闭原因: 状态码之后可以跟随一个可选的 UTF-8 字符串，描述关闭的原因。

常见的标准关闭码有：

• 1000：正常关闭。
• 1001：服务器或客户端因特殊原因需要关闭（如服务器关闭）。
• 1002：协议错误。
• 1003：接收到不支持的数据类型。
• 1006：异常关闭，没有收到关闭帧。
• 1007：收到包含不一致数据的帧，导致连接关闭。例如，格式不正确的内容。
• 1009：发送的消息超过了可以接收的大小。
• 1011：服务器遇到错误，无法完成请求。
• 1015：当 WebSocket 连接在 TLS/SSL 握手期间失败时，使用此状态码。

除了上述标准状态码外，使用者也可以定义自定义的关闭状态码，通常建议使用在 1,000 到 1,999 之间的代码（一定要注意避免与标准代码冲突）。

示例关闭帧字节流：

|-----------|--------------------------------------------------------------------------------------------------------| | 1 | | FIN | RSV | Opcode | MASK | Payload length | Close Code (2 bytes) | Close Reason (n bytes) | |

关闭流程非常简单就是发送和接收数据，所以对于应用层的 WebSocket 而言就只有两步：

• 发送: 当一方要关闭连接时，它会构造关闭帧并在 Payload 中写入状态码和可能的关闭原因，然后将其发送给另一方。
• 接收: 接收方在接收到关闭帧后，会读取 Payload，首先获取状态码，然后读取可选的关闭原因，从而知道连接关闭的具体情况。

如果是基于 TCP 的四次挥手进行描述就是以下四步：

1. 发起关闭请求:

   • 一方调用关闭操作

     连接的一方（可以是客户端或服务器）决定关闭连接时，调用相应的 close() 方法。

   • 发送关闭帧

     主动断开连接的一方会创建并发送一个关闭帧（Close Frame），该帧包含关闭状态码和可选的关闭原因。

2. 接收关闭帧:

   • 接收帧

     被动断开连接的一方（接收方）收到关闭帧时，会首先解析该帧的状态码和可选原因。

   • 处理关闭帧

     接收方可以根据关闭状态码进行相应的处理（例如，记录日志，更新连接状态等）。

3. 发送响应的关闭帧 (Pong):

   • 回应关闭请求

     接收方在确认关闭请求后（可能进行清理操作）会发送自己的关闭帧，这通常是一个回应帧。

   • 格式

     该响应关闭帧也会包含一个状态码，通常是 1000（正常关闭），并可能附带关闭原因。

4. 最终关闭连接:

   • 双方完成关闭

     一旦双方都发送并接收了关闭帧，WebSocket 连接将被正式关闭。

   • 清理资源

     关闭连接时，双方可以释放相关资源，如定时器、事件监听器等。

2.2.5 安全性 {#2-2-5-安全性}

WebSocket 使用 wss（WebSocket Secure）协议进行安全通信的方式与使用 ws（WebSocket）协议类似，但需要额外的安全配置。

• WSS: 是通过 TLS/SSL 加密的 WebSocket 协议，类似于 HTTPS 相对于 HTTP 的形式。使用 WSS 可以确保数据在传输过程中得到加密，避免被窃听和篡改。
• 端口: WSS 通常使用 443 端口，而 WS（不安全）使用 80 端口。

在使用 WSS 时，必须提供有效的 SSL/TLS 证书。可以使用：

• 自签名证书: 用于开发和测试，但浏览器可能会显示安全警告。
• 公认的证书: 从受信任的证书颁发机构获取的证书，用于生产环境，以确保通信的安全性。

3. webSocket和Http对比 {#3-webSocket和Http对比} =========================================

3.1 相同点和不同点 {#3-1-相同点和不同点}

相同点 {#相同点}

1. 应用层协议 ：
   • WebSocket 和 HTTP 都属于应用层协议，主要用于数据的传输。
2. 基于 TCP ：
   • 两者都依赖于 TCP 协议进行底层的数据传输，确保数据的可靠性和顺序。
3. 跨平台兼容性 ：
   • WebSocket 和 HTTP 都可以在不同的平台和设备上使用，支持跨浏览器和跨设备的通信。
4. 使用标准的 URL ：
   • WebSocket 和 HTTP 都使用类似的 URL 结构，例如 http:// 和 ws://。

不同点 {#不同点}

| 特性 | HTTP | WebSocket | |----------|----------------------------|---------------------------| | 连接模式 | 短连接 | 长连接 | | 通信方式 | 单向（请求-响应） | 双向（全双工通信） | | 连接建立 | 每次请求建立新连接，之后关闭连接 | 初始通过 HTTP 握手后建立持久连接 | | 延迟 | 每次请求都需要重新建立连接，延迟较高 | 连接一旦建立后，延迟较低，可实时传输数据 | | 数据格式 | 基于文本的请求/响应，通常是 JSON 或 HTML | 数据帧，支持文本和二进制数据 | | 状态保持 | 无状态（每个请求都是独立的） | 有状态（连接保持，允许持续交互） | | 头信息 | 每个请求都带有完整的 HTTP 头信息 | 头信息仅在握手时使用，后续数据传输不需要 | | 适用场景 | 静态网页加载、API 请求等 | 实时聊天、在线游戏、数据流等 | | 安全性 | 依赖于 HTTPS 加密 | 通过 WSS 进行加密，确保数据传输安全 | | 心跳机制 | 无法主动检测连接是否存活 | 支持 Ping/Pong 心跳机制，确保连接活跃性 |

1. 连接模式 ：
   • HTTP：每次请求都是独立的，需要重新建立连接，适合于一次性请求的场景。
   • WebSocket：连接建立后可以保持很长时间，适合需要频繁数据交换的场景。
2. 通信方式 ：
   • HTTP：客户端发起请求，服务器响应，适用于请求-响应模式。
   • WebSocket：客户端和服务器可以随时发送消息，适合双向通信。
3. 延迟 ：
   • HTTP：每次请求都需要经过建立和关闭连接的过程，导致较高的延迟。
   • WebSocket：连接建立后，数据传输几乎是即时的，延迟较低。
4. 数据格式 ：
   • HTTP：通常以文本格式传输，如 JSON、HTML 等。
   • WebSocket：支持更灵活的数据格式，包括二进制数据，适合多种应用场景。
5. 状态保持 ：
   • HTTP：每个请求都是独立的，无状态设计。
   • WebSocket：连接是持久的，可以保持状态，适合需要长时间交互的应用。
6. 心跳机制 ：
   • HTTP：没有内置机制检测连接的存活状态。
   • WebSocket：通过 Ping/Pong 帧来保持连接活跃性，检测连接状态。

WebSocket 和 HTTP 各自有其适用的场景和优势。HTTP 适合传统的请求-响应模式，而 WebSocket 则更适合需要实时、双向交互的应用。在现代 Web 开发中，根据应用的需求选择合适的协议可以大大提高性能和用户体验。

3.2 应用场景 {#3-2-应用场景}

HTTP 的应用场景 {#HTTP-的应用场景}

1. 静态网页加载 ：
   • 用于加载 HTML、CSS、JavaScript 文件等静态资源。
2. RESTful API ：
   • 适合请求-响应模型，常用于获取、创建、更新和删除数据。
3. 文件下载和上传 ：
   • 支持大文件的上传和下载，适合需要处理文件的场景。
4. 搜索引擎 ：
   • 用于搜索查询，返回结果数据。
5. 内容管理系统 ：
   • 用于管理和发布网站内容，支持用户交互。

WebSocket 的应用场景 {#WebSocket-的应用场景}

1. 实时聊天应用 ：
   • 支持用户之间的即时消息传递，如聊天工具和社交平台。
2. 在线游戏 ：
   • 实时数据传输，确保游戏状态和玩家动作的即时更新。
3. 金融交易平台 ：
   • 实时更新股票价格、交易信息和市场动态，适合高频交易。
4. 实时协作工具 ：
   • 适合文档编辑、白板协作等场景，支持多人实时互动。
5. 物联网（IoT）应用 ：
   • 设备之间的实时数据交换和监控，适合智能家居和工业应用。
6. 推送通知 ：
   • 实时推送消息，如新闻更新、社交媒体通知等。

因此我们就可以得到以下结论:

• HTTP 更适合于请求-响应式的交互，适用于大多数常规的数据传输需求。

• WebSocket 则专为实时、双向的通信而设计，适合需要快速响应和持续连接的应用场景。选择合适的协议可以根据具体的应用需求和用户体验进行优化。

在Qt中使用WebSocket

附录 {#附录}

RESTful，通常被称为 REST（Representational State Transfer），是一种软件架构风格，用于设计网络应用程序。它基于HTTP协议，并遵循一组设计原则和约束，以实现可伸缩的、灵活的网络服务。

REST 的设计理念是：

1. 资源 - 网络上的每个实体都是一个资源。资源可以是一个文档、一个人、一个事件等。
2. 表现形式（Representations） - 资源的某个具体状态可以通过不同的表现形式来表示。例如，一个人的资源可以通过文本、图片或其他任何形式来表示。
3. 状态转移（State Transfer） - 客户端通过发送请求到服务端，请求可能会改变服务端的状态（例如，创建新的资源，更新资源状态，读取资源状态等）。

RESTful 应用程序的典型特征包括：

• 使用 HTTP方法（如GET、POST、PUT、DELETE）来操作数据。
• 通过 URL（统一资源定位符）来表示资源的地址。
• 使用 标准数据格式（如JSON或XML）来描述资源的表现形式。
• 分离 客户端和服务器端状态，以便每个请求可以独立完成操作。
• 无状态的设计，每次请求都包含必要的信息，不依赖于之前的请求（这有助于实现高可伸缩性）。
• 超媒体作为自描述的指南，在响应中包含链接，以此作为导航的指南。

RESTful 设计原则通常用于创建现代网络上通信的 Web 服务和 API。由于其无状态性和分层架构，RESTful API 适合处理高并发请求，并且可以通过缓存和代理来改善性能和扩展性。