WebSocket 通信说明与基于 ESP-IDF 的 WebSocket 使用

一、 WebSocket 出现的背景

最开始 客户端（Client） 和 服务器（Server） 通信使用的是 HTTP 协议，HTTP 协议有一个的缺陷为：通信只能由客户端（Client）发起。

在一些场景下，这种单向请求的特点，注定了当 服务器（Server） 有连续的状态变化时， 客户端（Client） 要获知就非常麻烦。 客户端（Client） 只能使用轮询的方式，即每隔一段时间，就发出一个询问，来了解 服务器（Server） 有没有新的信息，最典型的场景就是聊天室。

轮询的方式导致效率很低，非常浪费资源， 客户端（Client） 必须不停地发起连接，或者 HTTP 连接始终打开。为此工程师们一直在思考更好的解决方案，因此 WebSocket 就这样诞生了。

二、WebSocket 的优缺点

WebSocket 优势：

实时性：由于 WebSocket 的持久化连接，它可以实现实时的数据传输，避免了 Web 应用程序需要不断地发送请求以获取最新数据的情况。
双向通信： WebSocket 协议支持双向通信，这意味着 服务器（Server） 可以主动向 客户端（Client） 发送数据，而不需要 客户端（Client） 发送请求。
减少网络负载：由于 WebSocket 的持久化连接，它可以减少 HTTP 请求的数量，从而减少了网络负载。

WebSocket 的劣势：

需要浏览器和 服务器（Server） 都支持： WebSocket 是一种相对新的技术，需要浏览器和服务器都支持。一些旧的浏览器和 服务器（Server） 可能不支持 WebSocket。
需要额外的开销： WebSocket 需要在服务器上维护长时间的连接，这需要额外的开销，包括内存和 CPU。
安全问题：由于 WebSocket 允许 服务器（Server） 主动向 客户端（Client） 发送数据，可能会存在安全问题。 服务器（Server） 必须保证只向合法的 客户端（Client） 发送数据。

三、WebSocket 协议概述

WebSocket 协议是一种基于 TCP 的协议，用于在 客户端（Client） 和 服务器（Server） 之间建立持久连接，并且可以在这个连接上实时地交换数据。WebSocket 协议有自己的握手协议，用于建立连接，也有自己的数据传输格式。

当 客户端（Client） 发送一个 WebSocket 请求时，服务器（Server） 将发送一个协议响应以确认请求。在握手期间， 客户端（Client） 和 服务器（Server） 将协商使用的协议版本、支持的子协议、支持的扩展选项等。一旦握手完成，连接将保持打开状态， 客户端（Client） 和 服务器（Server） 就可以在连接上实时地传递数据。

WebSocket 协议使用的是 双向数据传输，即 客户端（Client） 和 服务器（Server） 都可以在任意时间向对方发送数据，而不需要等待对方的请求。它支持传输 二进制数据 和 文本数据，并可以自由地在它们之间进行转换。

WebSocket 通信过程

一个 WebSocket 连接包含以下四个主要阶段：

1、连接建立阶段（Connection Establishment）

在这个阶段， 客户端（Client） 和 服务器（Server） 之间的 WebSocket 连接被建立。 客户端（Client） 发送一个 WebSocket 握手请求， 服务器（Server） 响应一个握手响应，然后连接就被建立了。握手过程 如下：
WebSocket 为了兼容 HTTP 协议，是在 HTTP 协议的基础之上进行升级得到的。在客户端（Client） 和 服务器（Server） 端建立 HTTP 连接之后，客户端（Client） 会向 服务器（Server） 端发送一个升级到 WebSocket 的协议，如下所示：

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

通过设置 Upgrade 和 Connection 这两个 header，表示准备升级到 WebSocket 了。

除了这里列的属性之外，其他的 HTTP 自带的 header 属性都是可以接受的。

当 服务器（Server） 端收到客户端（Client） 的请求之后，会返回给客户端（Client） 一个响应，告诉客户端（Client） 协议已经从 HTTP 升级到 WebSocket 了。返回的响应可能是这样的：

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

这里的 Sec-WebSocket-Accept 是根据客户端（Client） 请求中的 Sec-WebSocket-Key 来生成的。具体而言是将客户端（Client） 发送的 Sec-WebSocket-Key 和字符串 “258EAFA5-E914-47DA-95CA-C5AB0DC85B11” 进行连接。然后使用 SHA1 算法求得其 Hash 值，最后将 Hash 值进行 base64 编码即可，当 服务器（Server） 端返回 Sec-WebSocket-Accept 之后，客户端（Client） 可以对其进行校验，已完成整个握手过程。

2、连接开放阶段（Connection Open）

在这个阶段，WebSocket 连接已经建立并开放，客户端（Client） 和 服务器（Server） 可以在连接上互相发送数据。

3、连接关闭阶段（Connection Closing）

在这个阶段，一个 WebSocket 连接即将被关闭。它可以被客户端（Client） 或 服务器（Server） 发起，通过发送一个关闭帧来关闭连接。

4、连接关闭完成阶段（Connection Closed）

在这个阶段，WebSocket 连接已经完全关闭。客户端（Client） 和 服务器（Server） 之间的任何交互都将无效。

需要注意的是，WebSocket 连接在任何时候都可能关闭，例如网络故障、 服务器（Server） 崩溃等情况都可能导致连接关闭。因此，需要及时处理 WebSocket 连接关闭的事件，以确保应用程序的可靠性和稳定性。

WebSocket 的消息格式

WebSocket 的消息格式与 HTTP 请求和响应的消息格式有所不同。WebSocket 的消息格式可以是文本或 二进制数据，并且 WebSocket 消息的传输是在一个已经建立的连接上进行的，因此不需要再进行 HTTP 请求和响应的握手操作。

在这里插入图片描述

由图可知，WebSocket 的报文格式可以分为七大部分，分别是 1bit 的 FIN 标志位，3bit 的RSV 保留位，4bit 的 Opcode，1bit 的 Mask 标志位，7/7+16/7+64bit 的 payloadLen，可选字段 masking-key，可选字段 payload。具体解释下：

FIN 标志位：此标志位用于指示当前的帧是消息的最后一个分段。
- WebSocket 支持将长消息切割成若干帧发送，切分后，前边的帧的 FIN 字段均为 0，最后一个帧的 FIN 为 1 。
- 当消息没有分段时，这个帧便包含所有信息，FIN 标志位为1.【1bite】
RSV1~3 ：这是三个保留位,一般情况下为全 0。
- 当 客户端（Client） 、服务端协商采用 WebSocket 扩展时，这三个标志位可以 非 0，且值的含义由扩展进行定义。
- 如果出现 非0 值但并未采用 WebSocket 扩展，连接出错。

Opcode : 4bit 操作码，用于指示帧类型。

Opcode 决定了如何解析后续的数据载荷部分，如果操作码是不认识的，接收端应该断开连接。可选的操作码如下：

%x0：表示一个延续帧。当 Opcode 为 0 时，表示本次数据传输采用了数据分片，当前收到的数据帧为其中一个数据分片。
%x1：表示这是一个文本帧（frame）
%x2：表示这是一个二进制帧（frame）
%x3-7：保留的操作代码，用于后续定义的非控制帧。
%x8：表示连接断开。
%x9：表示这是一个 ping 操作。
%xA：表示这是一个 pong 操作。
%xB-F：保留的操作代码，用于后续定义的控制帧。

其中注意 WebSocket 既可以传输文本数据，也可以传输二进制数据

Mask 标志位：指示帧的 payload 是否需要使用掩码覆盖。
- RFC6455 规定，当且仅当由客户端（Client） 向服务端发送的帧需要覆盖。
- 掩码覆盖的作用：解决 “缓冲区溢出”（忽略）
- 当 Mask 为 1 ，但服务端接收的数据没有进行过掩码操作，服务端需要断开连接
```
payload length:7位/7+16位（64k）/7+64位（超级大），单位是字节
模式区分：
①当7bite的payloadlength<126，此时为模式1
② 7bite的payloadlength=126，16bite生效为模式2
③ 7bite的payloadlength=126，64bite生效为模式3
```
- masking-key 与 mask 值有关，当 mask 为 0 时，没有 masking-key；为 1 时，有 4bit 的 masking-key
payload-data :长度可变。包含扩展数据（x 字节）和应用数据（y 字节）
- 如果通信双方约定使用了 WebSocket 扩展，则扩展数据也存放于此，并声明扩展长度。
- 如果没有约定使用，则扩展数据为 0 字节。

WebSocket 的报文格式中最重要的便是 Opcode、payload length(三种模式)，payload data

四、基于 esp-idf 如何使用 webSocket

如何使用

对于 esp-idf v5.0 以下版本，有对应的 websocket 示例，用户可以直接进行测试。
对于 esp-idf v5.0 以上版本，提供了 esp_websocket_client 组件，直接在对应的示例下面添加组件即可。
```
idf.py add-dependency "espressif/esp_websocket_client^1.2.3"
```

基于 ESP-IDF SDK 使用 Websocket 的案例：

使用 esp-idf v4.2.2 版本， 服务器（Server） 有时会异常断开，模块会收到 服务器（Server） 发过来的 opcode=0x08 关闭帧，这这种情况下设备要如何重新连接？这个机制是怎样的呢？

首先，op_code 为 0x08 是一个断开帧，表示对端主动断开的，我们是不需要在 WEBSOCKET_EVENT_DATA 里去判断 op_code 等于 0x08 的情况。在 WEBSOCKET CLOSED 事件中，内部会进行断开的处理，如果直接在 WEBSOCKET_EVENT_CLOSED 调用 esp_websocket_client_start(client) 接口重新连接 服务器（Server） ，则实际测试下来会进入到 close 事件里面，但是并没有重新连接，日志如下：

2024-09-27 12:10:14.783]# RECV ASCII>
[0;32mI (27116) WEBSOCKET: ====================Received opcode=1==================[0m
[0;33mW (27116) WEBSOCKET: ------> [3, "410212051", {}] <------

[2024-09-27 12:10:21.160]# RECV ASCII>
[0;32mI (33506) uart_events: netStatus:7
[2024-09-27 12:10:22.466]# RECV ASCII>
[0;32mI (34796) WEBSOCKET: ====================Received opcode=8==================[0m
[0;32mI (34796) WEBSOCKET: WEBSOCKET_EVENT_CLOSED[0m
[2024-09-27 12:10:26.185]# RECV ASCII>
[0;31mE (38486) TRANSPORT_WS: Error read response for Upgrade header GET /HBE-123456 HTTP/1.1Connection: UpgradeHost: 0c6eeb3d0d512aa2.octt.openchargealliance.org:21128User-Agent: ESP32 Websocket ClientUpgrade: websocketSec-WebSocket-Version: 13Sec-WebSocket-Key: VMy5tg1Rv1Gr/P7HhLCTVw==Sec-WebSocket-Protocol: ocpp1.6[0m
[0;31mE (38506) WEBSOCKET_CLIENT: Error transport connect[0m
[0;31mE (38516) WEBSOCKET_CLIENT: esp_websocket_client_abort_connection(160): Websocket already stop
[2024-09-27 12:10:29.403]# RECV ASCII>
[0;32mI (41746) uart_events: netStatus:6
[2024-09-27 12:10:37.633]# RECV ASCII>
[0;32mI (49976) uart_events: netStatus:6
[2024-09-27 12:10:45.848]# RECV ASCII>
[0;32mI (58196) uart_events: netStatus:6
[2024-09-27 12:10:51.190]# RECV ASCII>
[0;31mE (63456) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:[0m
[0;31mE (63456) task_wdt:  - IDLE (CPU 0)[0m
[0;31mE (63456) task_wdt: Tasks currently running:[0m
[0;31mE (63456) task_wdt: CPU 0: websocket_task[0m
[0;31mE (63456) task_wdt: CPU 1: IDLE[0m
[0;31mE (63456) task_wdt: Print CPU 0 (current core) backtrace
Backtrace: 0x4013BF6A:0x3FFBE920 0x40082A71:0x3FFBE940 0x4000BFED:0x3FFF1030 0x40093AAD:0x3FFF1040 0x40091698:0x3FFF1060 0x400917A8:0x3FFF10A0 0x400DD000:0x3FFF10C0 0x400938D9:0x3FFF10F0
[0;31mE (63456) task_wdt: Print CPU 1 backtrace[0m
Backtrace: 0x4008BFF1:0x3FFBEF2

再进一步调试发现是因为客户端（Client） 如果收到 0x08 的 opcode ，它不仅仅只是断开之前的连接，还会释放掉之前创建的 handle，所以用户需要在 WEBSOCKET_EVENT_CLOSED 事件里创建好 handle ，然后直接去做重新连接的操作，参考如下代码：

case WEBSOCKET_EVENT_CLOSED:
        ESP_LOGI(TAG, "WEBSOCKET_EVENT_CLOSED");
        esp_websocket_client_config_t websocket_cfg = {};

    shutdown_signal_timer = xTimerCreate("Websocket shutdown timer", NO_DATA_TIMEOUT_SEC * 1000 / portTICK_PERIOD_MS,
                                         pdFALSE, NULL, shutdown_signaler);
    shutdown_sema = xSemaphoreCreateBinary();

    websocket_cfg.task_stack = 8192;
    websocket_cfg.uri = "ws://0c6eeb3d0d512aa2.octt.openchargealliance.org:21128/HBE-123456";
	websocket_cfg.subprotocol="ocpp1.6";

    ESP_LOGI(TAG, "Connecting to %s...", websocket_cfg.uri);

    esp_websocket_client_handle_t client = esp_websocket_client_init(&websocket_cfg);
    esp_websocket_register_events(client, WEBSOCKET_EVENT_ANY, websocket_event_handler, (void *)client);

        esp_websocket_client_start(client);
        break;
    }