当前位置：首页 > news >正文

Libwebsockets：从嵌入式到云端的C语言全能网络库实战指南

news 2026/5/8 18:19:29

1. 项目概述：Libwebsockets，一个为嵌入式与云端而生的全能网络库

如果你在C语言项目中需要处理网络通信，无论是为资源受限的微控制器（MCU）构建一个Web配置界面，还是在云端服务器上实现高性能的WebSocket消息推送，选型总是一个令人头疼的问题。是东拼西凑几个单一功能的库，还是引入一个庞大臃肿的框架？几年前，我也面临同样的困境，直到我深入使用了Libwebsockets（常简称为lws）。它不是一个仅仅处理WebSocket的库，而是一个以WebSocket为核心，深度整合了HTTP/1、HTTP/2、MQTT等多种协议的安全、轻量级、可塑性极强的C语言网络通信基石。它的设计哲学深深吸引了我：用最精简的API，提供最强大的能力，同时保持对从实时操作系统（RTOS）到大型Linux服务器的全平台兼容。简单来说，lws让你能用一套代码、一种思维模型，去应对从物联网设备到互联网服务的所有网络层挑战。

这个库的“轻量”并非功能阉割，而是指其核心依赖少、内存占用可控、代码结构清晰。它自身实现了协议处理的核心状态机，对于TLS，它优雅地适配了OpenSSL、MbedTLS（包括v2和v3）、WolfSSL等多种后端，你甚至可以在Windows上利用系统自带的Schannel而无需额外依赖OpenSSL。更值得一提的是其“事件循环无关性”，lws可以轻松嵌入到libuv、libevent、libev、glib等主流事件循环中，也能在无外部事件库的裸机环境下运行自己的事件循环。这种高度的灵活性，使得集成lws到现有项目中异常平滑，你不需要为了用它而重构整个应用架构。

2. 核心架构与设计哲学解析

2.1 为什么是“上下文”（Context）与“虚拟主机”（Vhost）？

初次接触lws，其核心对象struct lws_context和struct lws_vhost可能会让人困惑。这正是理解其设计的关键。你可以把Context（上下文）想象成整个库的“宇宙”或“运行时环境”。它持有全局资源：事件循环、线程池、日志系统、TLS证书缓存等。一个进程通常只需要一个Context，它是一切网络活动的基石。

而Vhost（虚拟主机）则是这个宇宙中的“独立星球”。每个Vhost绑定到特定的端口、协议集合和TLS配置。为什么需要Vhost？设想一个场景：你的服务器需要在8080端口提供普通的HTTP服务，同时在8443端口提供基于TLS的WebSocket服务，并且两者的协议回调函数、证书可能完全不同。在lws中，你无需启动两个独立的服务器进程，只需在同一个Context下创建两个Vhost即可。这种设计实现了资源（如线程、内存池）的共享与配置的隔离，是构建多功能、高密度服务的基础。

// 简化的创建流程概念 struct lws_context_creation_info info; memset(&info, 0, sizeof(info)); info.port = 8080; info.protocols = my_protocols; info.gid = -1; info.uid = -1; struct lws_context *context = lws_create_context(&info); if (!context) { /* 处理错误 */ } // 在已有Context上创建第二个Vhost（绑定到8443端口，使用TLS） struct lws_context_creation_info vhost_info = info; // 继承基础配置 vhost_info.port = 8443; vhost_info.ssl_cert_filepath = “/path/to/cert.pem”; vhost_info.ssl_private_key_filepath = “/path/to/key.pem”; struct lws_vhost *secure_vhost = lws_create_vhost(context, &vhost_info);

这种“Context + Vhost”的层级模型，使得lws既能服务于简单的单协议客户端，也能支撑起复杂的、多协议、多端口的服务器应用，架构清晰且扩展性强。

2.2 协议回调机制：事件驱动的灵魂

lws是一个彻底的事件驱动库。它不像传统Socket编程那样需要你主动去read/write，而是通过你注册的协议回调函数来通知你事件的发生。每个Vhost可以关联一组协议（struct lws_protocols），每个协议结构体中都包含了一系列回调函数指针，例如LWS_CALLBACK_ESTABLISHED（连接建立）、LWS_CALLBACK_RECEIVE（收到数据）、LWS_CALLBACK_SERVER_WRITEABLE（可发送数据）。

这个机制的精妙之处在于其通用性。无论是HTTP请求、WebSocket帧还是MQTT报文，对于你的业务逻辑而言，都是在特定的回调事件中被通知，并操作一个统一的连接对象struct lws *wsi。lws在底层帮你处理了繁琐的协议握手、分帧、心跳保活等细节。你的回调函数只需要关心：“现在连接建立了，我该初始化什么？”、“现在收到了一段数据，我该怎么处理？”、“现在通知我可以写了，我要发送什么？”。

实操心得：理解并适应这种回调思维是用好lws的第一步。它迫使你将业务逻辑组织成一系列对事件的反应，这天然契合高性能、高并发的网络编程模型。初期可能会觉得不如同步调用直观，但一旦掌握，代码结构会非常清晰，并且能轻松处理成千上万的并发连接。

3. 从编译到第一个示例：快速上手实战

3.1 跨平台编译：CMake的威力

lws使用CMake作为构建系统，这是其跨平台能力的保障。无论是Linux、macOS、Windows，还是FreeRTOS、Zephyr等嵌入式RTOS，编译流程都高度一致。

基础编译步骤（以Ubuntu/Linux为例）：

# 1. 克隆代码 git clone https://libwebsockets.org/repo/libwebsockets cd libwebsockets # 2. 创建构建目录并配置 mkdir build cd build cmake .. -DLWS_WITH_MINIMAL_EXAMPLES=ON -DLWS_WITHOUT_TESTAPPS=ON # 3. 编译 make -j$(nproc) # 4. 安装（可选，通常开发时直接链接build目录下的库即可） sudo make install

关键CMake选项解析：

-DLWS_WITH_MINIMAL_EXAMPLES=ON：强烈建议开启。这会编译minimal-examples目录下的上百个示例，它们是学习lws的最佳素材，每个都聚焦一个特定功能，代码极其精简。
-DLWS_WITH_SSL=ON（默认）：启用TLS支持，需要系统已安装OpenSSL或MbedTLS。
-DLWS_WITHOUT_TESTAPPS=ON：关闭一些内部测试应用，减少编译目标。
-DLWS_WITH_LIBUV=ON：如果你想使用libuv作为事件循环后端。
-DLWS_WITH_MBEDTLS=ON：使用MbedTLS替代OpenSSL，这在嵌入式环境中更常见。

嵌入式交叉编译示例（以ARM Cortex-M系列为例）：

# 假设你的交叉编译工具链前缀是 `arm-none-eabi-` mkdir build-arm cd build-arm cmake .. \ -DCMAKE_TOOLCHAIN_FILE=../contrib/cross-arm-none-eabi.cmake \ -DLWS_WITH_MBEDTLS=ON \ -DLWS_WITHOUT_DAEMONIZE=ON \ -DLWS_WITHOUT_TESTAPPS=ON \ -DLWS_IPV6=OFF \ -DLWS_WITH_MINIMAL_EXAMPLES=ON make

这里通过指定CMAKE_TOOLCHAIN_FILE来切换工具链，并关闭了一些非必需功能（如守护进程、IPv6）以缩减体积。

3.2 剖析最小WebSocket服务器示例

让我们看一个最简单的WebSocket Echo服务器（基于minimal-examples/ws-server/minimal-ws-server），它直观展示了lws的核心工作流程。

核心代码结构：

// 1. 定义协议回调函数 static int callback_echo(struct lws *wsi, enum lws_callback_reasons reason, void *user, void *in, size_t len) { switch (reason) { case LWS_CALLBACK_ESTABLISHED: lwsl_user(“连接建立\n”); break; case LWS_CALLBACK_RECEIVE: // 收到WebSocket消息 // 将收到的数据原样发回 lws_write(wsi, (unsigned char *)in, len, LWS_WRITE_TEXT); break; case LWS_CALLBACK_CLOSED: lwsl_user(“连接关闭\n”); break; default: break; } return 0; } // 2. 协议列表，告诉lws我们支持哪些协议 static struct lws_protocols protocols[] = { { “echo”, // 协议名称，客户端连接时需要指定 callback_echo, // 该协议对应的回调函数 0, // 每个连接分配的额外内存大小（per_session_data_size） 0, // 最大帧大小（0表示使用默认值） }, { NULL, NULL, 0, 0 } // 数组必须以空结构体结尾 }; int main(void) { struct lws_context_creation_info info; struct lws_context *context; const char *p; int n = 0; memset(&info, 0, sizeof(info)); info.port = 7681; // 监听端口 info.protocols = protocols; // 注册我们的协议 info.gid = -1; info.uid = -1; // 3. 创建上下文 context = lws_create_context(&info); if (!context) { lwsl_err(“创建lws上下文失败\n”); return 1; } lwsl_user(“服务器启动在端口 7681...\n”); // 4. 事件循环 while (n >= 0) { n = lws_service(context, 0); // 处理等待的事件，超时时间为0（非阻塞） // 这里可以插入你自己的后台任务 } // 5. 清理 lws_context_destroy(context); return 0; }

关键点解析：

回调函数：callback_echo是业务逻辑的核心。LWS_CALLBACK_RECEIVE事件触发时，in指针指向接收到的数据，len是其长度。我们直接用lws_write写回。注意lws_write的最后一个参数LWS_WRITE_TEXT，它指明发送的是文本帧。如果是二进制数据，应使用LWS_WRITE_BINARY。
协议注册：protocols数组定义了服务器“对外宣称”支持的WebSocket子协议。客户端在握手时可以通过Sec-WebSocket-Protocol头来选择使用哪个协议（这里只有“echo”）。这常用于区分同一端口上不同业务逻辑的连接。
事件循环：lws_service(context, timeout_ms)是核心驱动函数。它会检查所有活跃连接上的事件（如可读、可写、定时器到期），并调用相应的回调函数。timeout参数为0表示非阻塞调用，立即返回，这允许你在循环中穿插其他任务。如果设置为大于0的值，它会阻塞直到有事件或超时。
日志：lwsl_user和lwsl_err是lws提供的日志宏，输出到标准错误。你可以通过lws_set_log_level来控制日志级别。

注意事项：这个最小示例使用了lws内置的简单事件循环（lws_service）。在生产环境中，特别是需要集成到已有应用（如GUI程序、游戏主循环）时，你更可能需要使用“外部”事件循环集成（如libuv），这时你需要使用lws_service_fd等API来将lws的socket描述符纳入你自己的事件监控机制中。

4. 进阶特性深度探索：Secure Streams与序列化

4.1 Secure Streams：声明式网络编程范式

如果你觉得上述基于wsi（WebSocket Interface，即连接对象）的回调编程模型仍然繁琐，lws在v4.x版本后强力推行的Secure Streams（SS）API将是你的福音。它代表了一种更高层次的、声明式的网络编程思想。

核心理念：将“做什么”（连接策略）与“怎么做”（业务逻辑）分离。

连接策略：定义在JSON格式的策略文件中。包括目标地址（endpoint）、使用的协议（HTTP/1.1, HTTP/2, WebSocket, MQTT）、TLS设置、重试策略、认证信息等。
业务逻辑：在C代码中，你只需要通过一个“流类型名”（streamtype name）来请求创建一个流（Stream），然后处理这个流的生命周期回调（如rx收数据、tx发数据、状态变化）。

一个SS客户端的极简示例：假设策略文件policy.json中有如下定义：

{ “release”: “1.0”, “retry”: [ { “backoff”: [1, 2, 4, 8], “conceal”: 5 } ], “streams”: [ { “s”: “my_echo_stream”, // 流类型名 “endpoint”: “wss://echo.websocket.org”, “protocol”: “ws” } ] }

你的C代码会像这样：

// 定义流的回调 static int my_echo_stream_rx(void *userobj, const uint8_t *buf, size_t len, int flags) { // 收到服务器回显的数据 write(STDOUT_FILENO, buf, len); return 0; } static int my_echo_stream_state(void *userobj, void *sh, int state, int af) { if (state == LWSSSCS_CREATING) { // 流创建成功，可以发送数据了 lws_ss_request_write(sh); // 请求一次写操作 } return 0; } static int my_echo_stream_tx(void *userobj, lws_ss_tx_ordinal_t ord, uint8_t *buf, size_t *len, int *flags) { // 当被允许发送时，填充要发送的数据 const char *msg = “Hello, Secure Streams!”; memcpy(buf, msg, strlen(msg)); *len = strlen(msg); *flags = 0; return 0; } // 创建流 lws_ss_info_t ssi = { .streamtype = “my_echo_stream”, // 与策略文件中的“s”对应 .rx = my_echo_stream_rx, .state = my_echo_stream_state, .tx = my_echo_stream_tx, }; lws_ss_handle_t *h; lws_ss_create(context, 0, &ssi, NULL, &h, NULL, NULL);

可以看到，代码中完全没有出现协议细节、端点URL、重试逻辑。所有这些都移到了策略文件中。这意味着：

业务代码极度简化且稳定：协议切换（如从WS切换到MQTT）可能只需要修改策略文件，代码无需改动。
策略集中管理：安全策略、网络拓扑可以统一配置和更新，特别适合大型项目或产品化部署。
易于测试和模拟：通过替换策略文件，可以轻松将连接指向测试服务器或模拟器。

4.2 序列化与代理：架构解耦的利器

Secure Streams更革命性的特性是序列化。上述的SS API调用（创建流、发送数据、接收回调）可以被序列化成一种简单的线格式（wire format），并通过任何传输层（如Unix Domain Socket、TCP Socket、甚至UART）发送到另一个进程——SS Proxy——中去执行。

架构价值：

进程隔离与资源共享：多个客户端进程可以连接到同一个SS Proxy。Proxy持有统一的策略文件并管理所有实际网络连接。例如，多个进程的HTTP/2请求可以通过Proxy复用到同一个HTTP/2连接上，大幅减少连接开销和TLS握手成本。
赋能资源受限设备：设想一个只有UART接口的微控制器（如Raspberry Pi Pico）。它本身没有TCP/IP栈，无法进行TLS加密。但它可以通过UART发送序列化的SS指令给一个运行在Linux主机上的SS Proxy，由Proxy代为完成所有复杂的网络通信，并将结果返回。对于Pico上的应用来说，它就像直接连接到了互联网一样。lws官方就提供了这样的 Pico UART示例。
统一的安全边界：所有出站网络连接都由中心化的Proxy控制，便于实施统一的安全审计、流量监控和访问控制。

工作模式对比表：

模式	描述	适用场景
直接模式	SS API调用直接在本进程内由lws库处理，创建真实的网络连接。	独立的客户端或服务器应用，功能自包含。
序列化模式	SS API调用被序列化，通过传输层（如socket）发送给远程的SS Proxy进程执行。	多进程需要共享连接、资源受限设备、需要集中式网络策略管理的环境。
混合模式	部分流使用直接模式，部分使用序列化模式，由策略文件配置决定。	复杂的应用，部分连接需要本地直连（如本地服务发现），部分需要经过代理。

实操心得：对于新产品或重构项目，我强烈建议从Secure Streams API开始设计。它的学习曲线可能比直接使用wsi API略高，但它带来的架构清晰度、可维护性和未来的扩展性（如无缝支持代理模式）是巨大的。对于已有大量wsi代码的项目，可以逐步迁移，两者API在同一个上下文中可以共存。

5. 生产环境部署与性能调优指南

5.1 内存管理与连接限制

在嵌入式环境或高并发服务器上，精细控制内存至关重要。

关键配置参数（在struct lws_context_creation_info中设置）：

max_http_header_pool：预分配的HTTP头缓冲区数量。每个活跃的HTTP请求会占用一个。设置过小会导致头部分配失败，过大浪费内存。根据并发连接数估算。
max_fds：lws内部管理的文件描述符（连接）最大数量。这是限制最大并发连接数的关键参数。它必须大于你预期的最大并发连接数。在Linux上，也受系统级ulimit -n限制。
pt_serv_buf_size：每个服务线程（如果使用多线程）的缓冲区大小。用于临时存储协议数据。
options：通过位掩码设置各种选项，例如：
- LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT：全局初始化SSL（通常需要）。
- LWS_SERVER_OPTION_HTTP_HEADERS_SECURITY_BEST_PRACTICES_ENFORCE：自动添加安全相关的HTTP头（如CSP, HSTS）。
- LWS_SERVER_OPTION_DISABLE_IPV6：禁用IPv6以节省资源。

估算内存占用示例：假设配置max_fds=1000，每个连接除了系统本身的socket开销，lws内部struct lws对象大约占几百字节到1KB（取决于编译选项）。此外还有缓冲区内存。对于1000个并发WS长连接，在64位系统上，lws自身内存占用可能在几十MB量级。务必在你的目标平台上进行压力测试以获取准确数据。

5.2 多线程与事件循环集成

lws完美支持多线程，核心模式是一个监听线程 + N个服务线程。

监听线程：负责在监听socket上接受新连接。接受后，它会根据负载均衡策略（如轮询）将新的连接wsi分配给某个服务线程。
服务线程：每个服务线程运行独立的事件循环（lws_service或集成到libuv等），处理分配给它的所有连接上的I/O事件和回调。

配置多线程：

struct lws_context_creation_info info; memset(&info, 0, sizeof(info)); // ... 其他配置 info.count_threads = 4; // 创建4个服务线程（不包括监听线程） info.port = CONTEXT_PORT_NO_LISTEN; // 如果本Context只做客户端，可以设为这个 // 如果需要服务器，则设置监听端口，并确保 info.options 包含 LWS_SERVER_OPTION...

使用多线程能充分利用多核CPU，显著提升吞吐量。但要注意，同一个连接的所有回调都在同一个服务线程中被调用，这简化了连接状态的线程安全性设计。你需要确保在回调函数中访问的、属于该连接的数据不需要额外的锁。但跨连接共享的全局数据仍需妥善加锁。

集成外部事件循环（以libuv为例）：

编译时开启-DLWS_WITH_LIBUV=ON。
创建Context时，不再调用lws_service，而是由libuv的事件循环驱动。
lws提供了lws_uv_initloop等API，将lws的socket和定时器集成到libuv的uv_loop_t中。
你的主程序只需启动uv_run。

这种方式让你可以在一个事件循环中同时处理网络I/O、文件I/O、信号等所有异步操作，是构建复杂异步应用的理想选择。

5.3 TLS/SSL配置与优化

安全是网络通信的基石。lws在TLS配置上提供了极大的灵活性。

证书加载：

服务器证书：通过info.ssl_cert_filepath和info.ssl_private_key_filepath指定PEM格式的证书和私钥文件路径。
CA证书包：用于验证客户端证书（双向认证）或验证服务器证书（客户端模式）。通过info.ssl_ca_filepath指定。在嵌入式系统中，你可能需要将一个精简的CA证书包编译进固件。

密码套件与性能：现代CPU通常对AES-GCM有硬件加速支持。在MbedTLS或OpenSSL中，可以优先选择包含AES-GCM的密码套件以获得更好的性能。可以通过info.ssl_cipher_list来指定优先的密码套件列表，例如：“ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384”。

会话恢复与票据：为了减少重复的TLS握手开销，可以启用会话恢复或会话票据。

info.options |= LWS_SERVER_OPTION_DO_SSL_GLOBAL_INIT; info.ssl_options_set |= SSL_OP_NO_TICKET; // 或者使用票据，取决于安全和性能权衡 // MbedTLS有对应的配置选项

在频繁短连接的场景下（如API请求），启用会话恢复能显著降低延迟和CPU消耗。

6. 常见问题排查与调试技巧实录

即使有了完善的库，在实际开发中依然会遇到各种问题。以下是我在多年使用lws中积累的一些常见问题排查经验。

6.1 连接建立失败

症状：客户端无法连接到服务器，或握手失败。

检查端口和防火墙：这是最常见的原因。用netstat -tlnp或ss -tlnp确认服务器进程是否在预期端口上监听。
查看lws日志：在创建Context前，调用lws_set_log_level(LLL_USER | LLL_ERR | LLL_WARN | LLL_NOTICE | LLL_INFO, NULL);提高日志级别。连接过程中的错误（如证书错误、协议不支持）会打印出来。
协议名称不匹配：WebSocket握手时，客户端请求的子协议（Sec-WebSocket-Protocol）必须在服务器protocols数组中有定义。检查名称是否完全一致（包括大小写）。
TLS证书问题：
- 自签名证书：客户端需要禁用证书验证（不推荐生产环境）或信任该自签名CA。
- 证书链不完整：服务器证书必须包含完整的中间证书链。可以使用openssl s_client -connect yourserver:443 -showcerts来检查。
- 域名不匹配：证书的Common Name (CN)或Subject Alternative Name (SAN)必须与客户端连接使用的域名匹配。

6.2 数据传输问题

症状：连接能建立，但收不到数据或发送失败。

发送逻辑错误：在lws中，你不能随意调用lws_write。必须在收到LWS_CALLBACK_SERVER_WRITEABLE（服务器端）或LWS_CALLBACK_CLIENT_WRITEABLE（客户端）回调时才能发送。通常的模式是：当你有数据要发送时，先调用lws_callback_on_writable(wsi)来请求一个可写回调，然后在可写回调中执行lws_write。
发送缓冲区不足：lws_write可能因为缓冲区满而无法发送所有数据。其返回值是实际发送的字节数。对于非阻塞发送，你需要处理部分发送的情况，将剩余数据缓存起来，等待下一次可写回调。Secure Streams API帮你自动处理了这部分逻辑，这也是SS的优势之一。
接收回调未触发：确保在LWS_CALLBACK_RECEIVE回调中，你没有返回非零值（除非有意终止连接）。返回0表示成功处理，库会继续接收后续数据。
网络字节序与分包：WebSocket和TCP都是流式协议，对方发送的一大段数据，可能在LWS_CALLBACK_RECEIVE中被分成多次回调送达。你的应用层协议必须能处理粘包和拆包问题。通常需要在协议头中包含长度字段。

6.3 内存泄漏与性能瓶颈

症状：运行一段时间后内存持续增长，或并发数上去后响应变慢。

使用Valgrind或AddressSanitizer：在开发阶段，使用这些工具运行你的测试程序，检查lws库本身及你的回调函数中是否存在内存错误。
检查回调函数中的分配：如果你在回调函数（如LWS_CALLBACK_ESTABLISHED）中malloc了内存，必须在连接关闭的回调（LWS_CALLBACK_CLOSED或LWS_CALLBACK_WSI_DESTROY）中free掉。lws提供的user指针（在struct lws_protocols中设置的per_session_data_size）是管理连接私有数据的更安全方式，它会随连接自动创建和销毁。
调整max_fds和超时：max_fds设置过大会预分配过多内存，过小会导致无法接受新连接。连接超时（keepalive_timeout）设置过大会导致大量空闲连接占用资源。需要根据实际业务模型调整。
Profile性能：使用perf或gprof工具分析，热点通常会在TLS加解密、业务逻辑处理或日志输出上。确保生产环境关闭了调试日志（LLL_DEBUG,LLL_PARSER等）。

6.4 嵌入式环境特殊问题

症状：在MCU上运行异常，如崩溃、重启或网络不稳定。

堆栈大小：lws的内部处理和你的回调函数需要一定的栈空间。在RTOS（如FreeRTOS）中，确保创建服务线程的任务有足够的栈大小（通常至少需要几KB）。
内存分配器：嵌入式系统可能使用自定义的malloc/free。lws允许你通过info.allocator字段设置自定义的内存分配器，确保其线程安全（如果使用多线程）。
系统时钟：lws内部使用gettimeofday或类似函数获取时间，用于超时和重连计算。确保你的嵌入式系统有正确的时间源（如RTC或NTP同步）。
非阻塞Socket：lws假设所有socket都是非阻塞的。在某些简陋的嵌入式网络栈中，需要确认这一点。

问题速查表：

现象	可能原因	排查步骤
编译失败，找不到SSL	未安装OpenSSL/MbedTLS开发包	`apt-get install libssl-dev`或`-DLWS_WITH_SSL=OFF`
服务器启动失败，端口占用	端口已被其他进程使用	`netstat -tlnp \| grep <端口号>`，杀死占用进程或换端口
客户端连接被拒绝	防火墙阻止、服务器未监听、IP/端口错误	检查服务器日志、防火墙规则、客户端连接地址
WebSocket握手失败 (400/426)	请求头不符合规范，或尝试在HTTP端口进行WS连接	检查客户端发送的握手请求头；确认服务器配置了WS协议
能连接，但立刻断开	协议回调函数返回了非零值	检查所有协议回调，确保在成功处理时返回0
内存缓慢增长	连接关闭后资源未释放，回调中内存泄漏	使用内存检测工具；检查`LWS_CALLBACK_CLOSED`中的清理逻辑
高并发下性能差	`max_fds`不足，事件循环阻塞，业务逻辑过重	调整`max_fds`；检查`lws_service`超时参数；优化业务代码或启用多线程
嵌入式设备随机重启	堆栈溢出，内存分配失败	增加任务栈大小；检查内存分配器；启用看门狗并延长喂狗间隔