warmcat/libwebsockets

[](https://libwebsockets.org/git/libwebsockets) [](https://scan.coverity.com/projects/3576) [](https://bestpractices.coreinfrastructure.org/projects/2266) # Libwebsockets ** main 分支上的全新功能 ** - 新增了对 SChannel（Windows 原生 TLS，无需构建 OpenSSL！）、GnuTLS 和 BearSSL 的支持 - 实现了 QUIC + H3 + Webtransport，使用了 aws-lc、wolfssl、boringssl、libressl、gnutls 和 schannel（OpenSSL 仅支持 h1/h2，mbedtls 可通过补丁实现） |LWS 版本|平台|协议|默认 TLS| |---|---|---|---| |<= 4.5|非 FreeRTOS|任意|OpenSSL| |<= 4.5|FreeRTOS|任意|mbedTLS| |5.0+|Windows|任意|schannel| |5.0+|*nix|h1, h2|OpenSSL| |5.0+|*nix|quic/h3|GnuTLS| |5.0+|FreeRTOS|任意|mbedTLS| quic/h3 默认在构建时启用……这 necessitating 需要使用 GnuTLS 而不是 OpenSSL 才能使 quic/h3 工作。 | TLS 库 | 服务器 TLS | 客户端 TLS | QUIC 传输 (TLS 1.3) | WSS / HTTPS | 基于 TLS 的 MQTT | ALPN (HTTP/2) | DTLS (WebRTC) | 会话缓存 | JIT Trust | GenCrypto | | :--- | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | :---: | | **GnuTLS** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **否** | **是** | | **OpenSSL** | **是** | **是** | **否*** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | | **LibreSSL** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **否** | **是** | | **AWS-LC** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **否** | **是** | | **BoringSSL** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **否** | **是** | | **wolfSSL** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **否** | **是** | | **mbedTLS** | **是** | **是** | 需要补丁 | **是** | **是** | **是** | **是** | **是** | **是** | **是** | | **SChannel** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **是** | **否** | **是** | | **BearSSL** | **是** | **是** | **否** | **是** | **是** | **是** | **否** | **是** | **是** | **是** | | **openHiTLS** | **是** | **是** | **否** | **是** | **是** | **是** | 是 (非 SRTP) | **是** | **是** | **是** | \* *注意：1) 上游 OpenSSL 未提供必要的 QUIC TLS API (`SSL_set_quic_method`) 来作为 LWS QUIC 传输的加密引擎。如果您需要 QUIC/HTTP3 支持，我们建议使用 BoringSSL、GnuTLS、WolfSSL 或 OpenSSL 的 `quictls` 分支。* \* *注意：2) openHiTLS 未提供必要的 QUIC TLS API * - 内置 DHT 支持：`-DLWS_WITH_DHT=1` ** v4.5 已发布，您可以在 v4.5-stable 分支上跟进 ** Libwebsockets 是一个易于使用、基于 MIT 许可证的纯 C 库，以注重安全、轻量级、可配置、可扩展和灵活的方式，为 **http/1**、**http/2**、**websockets**、**MQTT** 及其他协议提供客户端和服务器实现。它易于通过 cmake 进行构建和交叉编译，适用于从嵌入式 RTOS 到大规模云端服务的各种任务。 它支持许多轻量级的辅助实现，例如 JSON、CBOR、JOSE、COSE，并且开箱即全面支持 OpenSSL 和 MbedTLS v2 及 v3。 在事件循环共享方面它非常“合群”，支持 libuv、libevent、libev、sdevent、glib 和 uloop，以及自定义事件库。 针对各种场景的 [100 多个独立的最小示例](https://libwebsockets.org/git/libwebsockets/tree/minimal-examples)，采用 CC0 许可证（公共领域），可以直接复制粘贴，让您快速入门。 在各种主题上都有[大量的 README](https://libwebsockets.org/git/libwebsockets/tree/READMEs)。 [我们每次推送都会进行大量的 CI 测试](https://libwebsockets.org/sai/)，目前在 30 个平台上进行 582 次构建。 [您可以查看 lws CI 机架，并了解基于 lws 的 Sai 是如何用于协调所有测试的](https://warmcat.com/2021/08/21/Sai-CI.html)。  ## 新闻 ## lws 中的 HTML + CSS + JPEG + PNG 显示栈 想用 HTML + CSS 来驱动你的 EPD 或 TFT / OLED 显示屏？只有一个 ESP32？ 需要远程的 JPEG、PNG、HTML、RGBA 合成、伽马校正，甚至需要时进行误差扩散？ 因为 heap 不足以分配 framebuffer，需要实时渲染到 line buffer 中？ [看看这里……](https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.html-parser.md) ## 可用的 lws Perl 绑定 感谢 Felipe Gasper，现在 [metacpan 上有可用的 lws Perl 绑定](https://metacpan.org/pod/Net::Libwebsockets)， 它利用了 lws 中最近的通用事件循环支持，让 lws 作为 guest 运行在现有的 perl 事件循环上。 ## Lws 示例正在切换到 Secure Streams  lws 中的 **Secure Streams** 支持是几年前引入的，它是一个比 lws `wsi` 级别 API 更高级的接口，通过将连接策略（如协议和 endpoint 信息）隔离到一个单独的 [JSON policy 文件](./minimal-examples/client/hello_world/example-policy.json) 中来简化连接，并让 [代码只处理 payload](./minimal-examples/clients/hello_world/hello_world-ss.c)；它尽可能地隐藏或移动通信协议的细节到 policy 中，因此即使通信协议发生改变，用户代码也几乎完全相同。 用户代码只需请求通过“streamtype name”创建一个 SS，它就会根据 policy 中同名的详细信息（协议、endpoint 等）进行创建。 像 endpoint 这样的关键 policy 条目可以包含 `${metadata-name}` 字符串替换，以通过 metadata 处理运行时适配。目前支持 h1、h2、ws 和 mqtt。 作为 `wsi` API 之上的一层，SS 提供了一种更高级的方式来访问现有的 wsi 级别功能，这两种 API 都将继续受到支持。 Secure Streams 的生命周期比单个 wsi 更长，因此 SS 可以自行协调重试。基于 SS 的用户代码通常比 wsi 层更小且更易于维护。 在 main 分支中，我已经将旧的示例移至 `./minimal-examples-lowlevel`，并开始将更多用例从那里移植到基于 SS 的示例中。 ### wsi 和 SS 级别 lws 用法比较 |功能|“底层” wsi 方式|Secure Streams 方式| |---|---|---| |创建 context|代码|相同| |Loop 支持，sul 调度器|默认，事件库|相同| |支持通信模式|Client, Server, Raw|相同| |支持协议|h1, h2, ws, mqtt (客户端)|相同| |TLS 支持|mbedtls (包括 v3 和 v4，不支持 QUIC)、openssl (包括 v3)、wolfssl、boringssl、aws-lc、libressl|相同| |可序列化、可代理、可多路复用、可传输|否|是| |自动分配的每连接用户对象|在 lws_protocols 中指定的 pss|在 ss info struct 中指定| |连接用户 API|特定于协议的 lws_protocols 回调 (>100)|SS API (仅限 rx, tx, state 回调)| |发送适配|lws_callback_on_writeable() + WRITEABLE|lws_ss_request_write() + tx() 回调| |发送缓冲区|用户选择 + malloc 处理部分数据|SS 提供，无部分数据| |创建 vhosts|代码|**JSON policy**| |TLS 验证|证书包或代码|**JSON policy**，或证书包| |连接重试 / 退避|代码|**JSON policy**，自动| |持久化|代码|**JSON policy**，自动| |Endpoint 和协议详情|散落在代码中|**JSON policy**| |协议选择，pipeline / stream 共享|代码|**JSON policy**| |ws 子协议选择|代码|**JSON policy**| |ws 二进制 / 文本|代码|**JSON policy**| |特定于协议的 metadata|代码中特定于协议的 API (例如 lws_hdr)|**JSON policy**，代码中的通用 metadata API| |连接有效性规则|struct|**JSON policy**，自动| |作为 Long Poll 流|代码|**JSON policy**| |身份验证|代码|**JSON policy** + 如果 provider 支持则自动轮换，否则为代码| ### 序列化 Secure Streams  Secure Streams API 也是**可序列化**的，完全相同的客户端代码可以像您期望的那样在同一个进程中直接完成连接，或者通过 Unix Domain 或 TCP socket 连接将操作、metadata 和 payload 转发给拥有 policy 的 [SS Proxy](./minimal-examples/ssproxy/ssproxy-socket)，以进行集中处理。例如，这允许来自不同进程的 h2 stream 共享单个连接。  序列化的 SS 还可以通过诸如 UART 等通用传输层进行传输，这里提供了一个[在 RPi Pico 上通过 UART 传输实现 Binance 示例的示例](./minimal-examples/embedded/pico/pico-sspc-binance)，连接到一个[UART 传输的 SS Proxy](./minimal-examples/ssproxy/ssproxy-custom-transport-uart)，其中 Pico 本身没有网络栈、tls、压缩或 wss 栈，但可以像拥有它们一样向 endpoint 发送和接收数据。 可选的 `lws_trasport_mux` 用于在 UART 传输层和 SSPC 层之间进行介入，允许单个管道承载许多独立的 SS 连接。 无论 SS 如何被传输、多路复用和实现，用户 SS 代码都是完全相同的。 ## v4.3 已发布 查看 [更新日志](https://libwebsockets.org/git/libwebsockets/tree/changelog) ## 支持 这是用于轻量级 websocket 客户端和服务器的 libwebsockets C 库。如需支持，请访问 https://libwebsockets.org 您可以从 git 获取该库的最新版本： - https://libwebsockets.org/git 开发的 Doxygen API 文档：https://libwebsockets.org/lws-api-doc-main/html/index.html ### 使用 AI 打补丁 在 2025 年，使用 AI 编写实际代码仍然相当令人担忧，但与此同时，它也为维护 FOSS 代码这项吃力不讨好的孤独工作提供了一种前进的方式。我一直在使用 Google 的 Gemini 2.5 以及现在的 3.0，虽然它在查看代码和我提出的要求并生成合理内容方面表现得非常出色（比一年前或自托管的通用模型好得多），但它在能够完成它所设想的补丁范围方面却常常表现不佳，经常过早停止并将其余部分直接抛弃。 值得称赞的是，它能够处理 lws 中相当复杂的 API，例如 `lws_struct`，以及 JSON 和 sqlite3 的序列化与反序列化，嗯，大多数情况下是可以的。 它对为今天的问题创建新的 struct 和 message 非常感兴趣，而对查看已有的内容并思考如何对其进行改编或统一则不那么感兴趣。简而言之，它完全不在乎可维护性。 它还受困于这样一种情况：对于正在发生的事情以及变更会起到什么作用，它的心智模型非常强大；但当被告知它的补丁没有达到预期效果时，它却表现得非常无力。人类会“捕捉”到其心智模型与现实之间的差异，以便了解模型在哪里出了问题而它们通常会避免添加日志，转而钻进一些非常不可能的兔子洞里耗费数小时。（Gemini 3.0 在这方面有所改善）。 与此同时，它知道可维护性和安全性应该是 desirable 的特性。但它知道这一点的方式与它知道分层补丁是可取的一样，它目前还无法正确处理这些考虑因素，尽管它可以谈论这些概念。 简而言之，在 2025 年，尽管我会继续将它用于某些任务，但它还没有达到让那些无法自己认真完成工作的人也能将其用于 lws 的状态。放行那些可能连你自己都不理解的代码实在太容易了，然后你余生都要处理安全漏洞和其他由此引发的崩溃问题。

标签：C/C++, HTTP, MQTT, QUIC, TLS/SSL, WebSocket, 事务性I/O, 依赖分析, 内核驱动, 客户端加密, 网络协议, 网络库