CLIWebSocket后端【免费下载链接】websocketdTurn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.项目地址https://gitcode.com/gh_mirrors/we/websocketd点击查看免费下载导读websocketd 的核心设计是像 inetd 一样工作但面向 WebSocket——每个 WebSocket 连接都会孵化fork一个独立的子进程客户端的消息通过 STDIN 流入进程进程的 STDOUT 通过 WebSocket 流回客户端。这篇指南以仓库中的 进程管理 QA 测试计划PROC-001 至 PROC-022为骨架逐项剖析子进程的启动、stdin/stdout/stderr 管道、优雅终止信号序列、--maxforks资源限制、脚本目录路由等机制并结合 libwebsocketd 目录下的 Go 源码给出实现级证据。读完你将掌握 websocketd 进程模型的全貌并能用可复现的测试用例验证各项行为、定位线上问题。一、核心进程模型每个连接一个独立子进程1.1 模型概述websocketd 不采用一个服务进程复用多个连接的常驻模型而是为每一次 WebSocket 连接启动一个全新的子进程。连接断开时子进程被终止。这个模型带来两个直接收益进程间天然隔离一个脚本崩溃、挂起或耗尽资源不会影响其他连接实现极简任何从 stdin 读、向 stdout 写的程序无需任何改动即可变成 WebSocket 后端对应项目描述 Turn any program that uses STDIN/STDOUT into a WebSocket server。1.2 验证PROC-001 每个连接获得独立进程测试计划中的 PROC-001 用一段打印自身 PID 的脚本验证该模型#!/bin/bash echo $$ while IFS read -r line; do echo $line; done执行步骤启动服务websocketd --port8080 ./pid.sh客户端 A 连接记录收到的 PID客户端 B 连接记录收到的 PID期望结果两个 PID 不同。每次 WebSocket 连接都会孵化一个新的子进程。从源码看这一行为由 libwebsocketd/handler.go 中的accept()落实每次 WebSocket 升级成功后都会调用launchCmd()启动新进程并把进程 PID 关联到日志作用域log.Associate(pid, ...)随后为这个进程单独构建一个ProcessEndpoint与WebSocketEndpoint最后通过PipeEndpoints把两者双向对接。底层启动函数launchCmd定义在 libwebsocketd/launcher.go它调用 Go 标准库exec.Command通过cmd.StdoutPipe()、cmd.StderrPipe()、cmd.StdinPipe()分别建立三根管道然后cmd.Start()拉起进程返回持有stdin/stdout/stderr三个管道的LaunchedProcess结构。对应的单元测试见 libwebsocketd/launcher_test.go其中 pipes are functional 用例直接验证了向 stdin 写入test input\n、从 stdout 读回test input\n的完整回路。二、STDIN 与 STDOUT双向消息管道2.1 STDINWebSocket 消息流向进程PROC-002前置以cat为后端命令启动 websocketd。步骤连接 websocketd通过 WebSocket 发送 test input观察进程响应期望结果进程在其 stdin 上收到test input\n并原样回显。这里的细节在于换行符从 libwebsocketd/websocket_endpoint.go 的readFrames()可以看到文本模式下每条收到的消息在写入管道前会被追加一个\np append(p, \n)这正是为了贴合面向行的 stdin 交互约定。数据最终经ProcessEndpoint.Send()写入子进程的 stdinlibwebsocketd/process_endpoint.go。2.2 STDOUT进程输出流向 WebSocketPROC-003前置创建启动即输出的脚本#!/bin/bash echo welcome echo ready while IFS read -r line; do echo $line; done步骤启动websocketd --port8080 ./welcome.sh用 wscat 连接不发送任何内容期望结果客户端在连接后立即收到 welcome 和 ready两条独立的 WebSocket 消息。这正是行即消息协议的直接体现ProcessEndpoint.readTextOutput()用bufio.Reader.ReadBytes(\n)按行读取 stdout每读到一个换行符就把该行经trimEOL去掉行尾的\n或\r\n作为一条完整消息推送到输出通道再经 WebSocket 发送给客户端。所以一行 stdout 一条 WebSocket 消息进程无需感知 WebSocket 的存在。2.3 消息分帧语义小结方向载体分帧规则源码位置WebSocket → 进程STDIN每条文本消息追加\n后写入websocket_endpoint.go进程 → WebSocket文本模式STDOUT按\n分行每行一条消息process_endpoint.go进程 → WebSocket二进制模式STDOUT原始字节流按读缓冲10MB切块发送process_endpoint.go--binary模式绕过行分帧源码中readBinaryOutput()直接读取原始字节但不能与--passstderr同时使用见下文 PROC-022校验逻辑在 config.go 的validateBinaryPassStderr。三、STDERR 的两种命运进日志或打标签转发3.1 默认行为STDERR 只进日志PROC-004前置创建同时写 stdout 和 stderr 的脚本#!/bin/bash echo stdout message echo stderr message 2步骤启动websocketd --port8080 --logleveldebug ./both.sh用 wscat 连接观察客户端消息与服务端日志期望结果客户端只收到 stdout messagestderr message 出现在 websocketd 的日志输出中不会通过 WebSocket 发给客户端。源码依据默认情况下ProcessEndpoint.StartReading()会启动logStderr()goroutine把 stderr 管道逐行读取并写入服务端日志pe.log.Error(stderr, ...)而输出通道只接收 stdout 的数据。3.2 进阶行为--passstderr 标记转发PROC-022步骤启动websocketd --port8080 --passstderr ./script-writing-to-both.sh连接并收集消息去掉--passstderr重复一次再尝试websocketd --port8080 --binary --passstderr cat期望结果开启--passstderr后STDOUT 与 STDERR 的行都会以JSON 消息到达客户端分别打上{stream:stdout,...}与{stream:stderr,...}标签无论是否开启该选项STDERR 都仍然写入服务端日志不带该选项时客户端只收到未打标签的 STDOUT与旧版本行为一致第 4 步会在启动时报错错误信息同时点名--binary与--passstderr—— 两者互斥。实现细节libwebsocketd/process_endpoint.go开启后StartReading()改为同时启动readStdoutTagged()与readStderrTagged()两个 goroutine两者把行封装进taggedMessage{Stream, Data}结构后用json.Marshal序列化readStderrTagged()中依然先执行pe.log.Error(stderr, ...)保证服务端日志不受影响两个读取器通过sync.WaitGroup汇合只有两者都结束时才关闭输出通道。对应的回归测试见 libwebsocketd/process_endpoint_test.goTestPassStderrTagging验证两条带标签消息的完整收发与通道关闭时机TestPassStderrTagMessageEscaping验证引号、反斜杠、换行等字符能被正确 JSON 转义。四、优雅终止升级式信号序列与 --closems4.1 默认终止序列PROC-005前置创建捕获信号的脚本#!/bin/bash trap echo GOT SIGINT /tmp/ws-signals.log INT trap echo GOT SIGTERM /tmp/ws-signals.log TERM echo ready while true; do sleep 0.1; done步骤启动websocketd --port8080 ./trap.sh连接等待 ready断开 WebSocket 客户端等待 1 秒检查 /tmp/ws-signals.log期望结果进程收到逐步升级的终止信号。默认时序为100ms 时 SIGINT、250ms 时 SIGTERM、500ms 时 SIGKILL进程最终被完全终止。注计划中记录进程挂起曾是缺陷已由 commit 3f89f2eissue #159修复。4.2 升级序列的源码实现libwebsocketd/process_endpoint.go 中Terminate()完整实现了这一策略关闭 STDIN优雅提示等待 100ms closetime → SIGINT等待 250ms closetime → SIGTERM等待 500ms closetime → SIGKILL等待 1000ms每一步之间都用selecttime.After等待进程通过cmd.Wait()退出一旦某个信号让进程退出就立即返回不再升级。整个序列以先给进程充分的清理机会最后用不可捕获的 SIGKILL 兜底为原则。此外Terminate()开头会close(pe.done)关闭完成通道解除可能阻塞在输出通道发送上的读取 goroutine——这正是 libwebsocketd/process_endpoint_test.go 中TestTerminateUnblocksParkedReader与TestTerminateUnblocksParkedReader_PassStderr两个用例所防护的 goroutine 泄漏回归场景。4.3 --closems自定义宽限期PROC-006步骤启动websocketd --port8080 --closems3000 ./trap.sh连接等待 ready断开连接并计时信号投递期望结果信号按--closems延迟。SIGINT 在 3000ms、SIGTERM 在 7500ms、SIGKILL 在 15000ms。进程获得更充足的清理时间。推导关系可对照 4.2 的公式closetime closems因此各阶段时刻为1003000、2503000、5003000…… 再加上最后 1000ms 的 SIGKILL 观察窗口。参数在 handler.go 的accept()中注入if cms : wsh.server.Config.CloseMs; cms ! 0 { process.closetime ... }。4.4 --closems0立即击杀PROC-007步骤启动websocketd --port8080 --closems0 ./trap.sh连接后立即断开确认进程被立即终止期望结果进程以最小延迟被终止。此时信号序列退化为纯默认节奏100ms/250ms/500ms进程几乎没有额外的清理窗口。五、--maxforks并发进程数上限5.1 上限强制PROC-008前置创建长运行脚本#!/bin/bash echo connected while true; do sleep 1; done步骤启动websocketd --port8080 --maxforks2 ./long.sh客户端 A 连接成功收到 connected客户端 B 连接成功收到 connected客户端 C 连接期望结果客户端 C 收到HTTP 429Too Many RequestsWebSocket 升级被拒绝A、B 继续正常工作。注计划中标注与 issue #366 相关——客户端无法区分fork 数达上限与服务器错误。实现上--maxforks是一个有缓冲的信号量通道libwebsocketd/http.goNewWebsocketdServer中make(chan byte, maxforks)升级请求进入serveWebSocket后先调用noteForkCreated()非阻塞写入失败即返回ErrForkNotAllowed成功后defer noteForkCompleted()保证连接结束时归还信号量。CGI 路径同样受该上限约束。默认值为 1024config.go中的defaultMaxForks注释明确说明这是防失控的兜底值而非容量规划——每个 fork 都是一个完整子进程无限上限会被恶意客户端用来 fork-bomb 主机。5.2 断开后自动恢复PROC-009步骤启动websocketd --port8080 --maxforks1 ./long.sh客户端 A 连接成功客户端 B 连接收到 429断开客户端 A稍候客户端 B 再次连接期望结果客户端 A 断开后 fork 计数器递减客户端 B 现在可以成功连接。这验证了defer noteForkCompleted()的语义无论连接因何结束信号量必然归还。5.3 0 表示不限制PROC-021步骤启动websocketd --port8080 --maxforks0 cat打开大量连接50期望结果所有连接都被接受0 表示无限制系统资源是唯一约束。源码中maxforks 0时才创建信号量通道为 0 时forks为 nilnoteForkCreated直接放行。六、进程异常非零退出、崩溃与不可执行6.1 非零退出码PROC-010前置创建脚本#!/bin/bash echo about to fail exit 42步骤启动websocketd --port8080 ./fail.sh用 wscat 连接期望结果客户端收到 about to fail随后连接关闭退出码 42 被记录到日志websocketd 本身不崩溃。Terminate()中的cmd.Wait()会捕获非零退出并输出Process exit: ...的调试日志。6.2 段错误崩溃PROC-011前置编译一个必定段错误的 C 程序#include stdlib.h int main() { *(int*)0 0; return 0; }步骤启动websocketd --port8080 ./segfault用 wscat 连接期望结果WebSocket 连接关闭websocketd 记录异常终止日志websocketd 自身不崩溃其他连接不受影响。这是每连接一进程模型的隔离性收益。6.3 脚本不可执行PROC-012前置创建一个没有执行权限的脚本文件。步骤启动websocketd --port8080 ./noexec.sh用 wscat 连接期望结果连接以适当的错误失败错误被记录websocketd 不崩溃。此时launchCmd中的cmd.Start()会返回权限类错误accept()捕获后记录Could not launch process ...并结束该次会话libwebsocketd/handler.go。6.4 进程在客户端输入前快速退出PROC-018前置创建立即退出的脚本#!/bin/bash echo goodbye exit 0步骤启动websocketd --port8080 ./quick.sh用 wscat 连接期望结果客户端收到 goodbye连接关闭无竞态条件、无崩溃。stdout 读取器、WebSocket 读取器与终止逻辑之间通过done通道与defer close(pe.output)协调保证了进程先退、管道先关场景下的有序收尾。七、脚本目录模式URL 到脚本的映射7.1 --dir 目录路由PROC-013前置创建目录scripts/ echo.sh (可执行回显 stdin) count.sh (可执行计数到 5)步骤启动websocketd --port8080 --dirscripts/连接ws://localhost:8080/echo.sh——发送 hello期望回显连接ws://localhost:8080/count.sh——期望收到数字连接ws://localhost:8080/nonexistent.sh——期望报错期望结果每个 URL 映射到正确的脚本不存在的脚本返回404。源码中GetURLInfolibwebsocketd/handler.go逐段解析 URL 路径在脚本目录下逐段os.Stat寻找存在的文件路径解析到目录则继续深入最终段是目录或不存在的路径时返回ErrScriptNotFound由serveWebSocket映射为 404。同时checkPathBoundary通过filepath.EvalSymlinks校验解析后的真实路径仍在脚本目录内防止符号链接逃逸。7.2 PATH_INFO 与 SCRIPT_NAMEPROC-014步骤连接ws://localhost:8080/echo.sh/extra/path/info检查进程环境中的 PATH_INFO 与 SCRIPT_NAME期望结果SCRIPT_NAME为/echo.shPATH_INFO为/extra/path/info。计划注明此行为由 handler_test.go 覆盖对应测试文件 libwebsocketd/handler_test.go。这一机制让脚本能够按 URL 子路径区分请求语义类似 CGI 规范RFC 3875中的路径信息约定。7.3 命令参数与含空格路径PROC-015、PROC-019PROC-015websocketd --port8080 /bin/echo hello from args客户端应收到 hello from args——参数被正确传递。resolveCommandconfig.go用exec.LookPath解析可执行文件剩余参数原样保留为CommandArgs每次启动时传给launchCmd(commandName, commandArgs, env)。PROC-019脚本位于/tmp/my scripts/echo.sh路径含空格启动时整体加引号websocketd --port8080 /tmp/my scripts/echo.sh即可正常执行——因为参数通过 Go 的exec.Command数组形式传递不存在 shell 分词问题。八、行缓冲陷阱与长运行进程8.1 进程输出缓冲PROC-016前置创建无换行输出的 Python 脚本#!/usr/bin/env python3 import sys, time sys.stdout.write(partial...) sys.stdout.flush() time.sleep(1) sys.stdout.write(complete\n) sys.stdout.flush()步骤启动websocketd --port8080 ./buffer.py用 wscat 连接观察消息时序期望结果文本模式下客户端在换行符出现前收不到任何消息随后收到合并为一条的 partial...complete。文本模式是行缓冲的换行符就是分帧分隔符。注计划中记录缓冲问题来自 issues #406、#388PHP、#400。许多语言在 stdout 未连接终端时会启用全缓冲脚本必须显式 flush 并使用换行。这与readTextOutput()的实现完全一致ReadBytes(\n)只有在读到换行符时才返回一帧。反过来说这也是脚本作者的黄金法则——一行输出 一条消息意味着必须换行 flush否则消息会迟迟不出现。8.2 长运行进程PROC-017前置无限循环脚本#!/bin/bash while true; do echo alive; sleep 10; done步骤启动websocketd --port8080 ./heartbeat.sh用 wscat 连接保持连接 30 分钟以上验证消息持续到达期望结果连接无限期保持打开消息持续到达websocketd 自身不施加空闲超时。若需要保活与死链检测可另行使用--pingms设置 WebSocket ping 间隔其实现见 libwebsocketd/websocket_endpoint.go 的setupPingPong。九、孤儿进程与进程组边界PROC-020前置创建会派生后台子进程的脚本#!/bin/bash sleep 100 sleep 100 echo spawned children while IFS read -r line; do echo $line; done步骤启动websocketd --port8080 ./spawner.sh连接确认收到 spawned children断开连接2 秒后检查孤儿sleep进程ps aux | grep sleep期望结果主脚本进程被终止。孙进程的行为取决于操作系统的进程组处理方式至少 websocketd 自身不应泄漏资源。注进程组清理因操作系统而异。在 Linux 上使用进程组process group会有帮助。这是一个已知限制。这是 websocketd 进程模型中为数不多的边界websocketd 直接管理的是直接子进程脚本自行派生的孙进程不在其终止职责之内。如果脚本需要保证后代进程随连接一起消亡需要在脚本内部自行组织进程组或使用setsid/守护进程包装。十、命令行参数速查与进程管理相关以下参数均来自 config.go 的parseCommandLine并已在 help.go 中登记帮助文本参数默认值作用对应测试--closemsms0断开后开始发送终止信号前的宽限时间0 表示立即进入默认节奏PROC-005/006/007--maxforksn1024最大并发子进程数0 表示不限PROC-008/009/021--binaryfalse二进制模式原始字节流不分行与--passstderr互斥PROC-022--passstderrfalse将 STDERR 以带stream标签的 JSON 消息转发给客户端PROC-004/022--dirpath空脚本目录模式URL 映射到目录内脚本PROC-013/014--loglevellevelaccessdebug/trace/access/info/error/fatal 之一用于观察进程生命周期日志PROC-004--pingmsms0WebSocket ping 间隔毫秒用于长连接保活PROC-017注意--maxforks的默认值 1024 是防失控兜底而非容量指标高并发部署应显式设置或设 0 明确放弃限制。十一、如何系统化验证这些行为本指南所有场景均来自 qa/plans/02-process-management.md编号 PROC-001 至 PROC-022。你可以按计划原样手工复现也可以结合 Go 测试套件做自动化验证# 运行仓库全部单元测试含进程端点、启动器、HTTP 路由等 go test ./...其中与本主题最相关的自动化用例包括libwebsocketd/launcher_test.go命令启动、环境变量传递、stdin/stdout 管道回路libwebsocketd/process_endpoint_test.go--passstderr的 JSON 打标、终止时 goroutine 不泄漏libwebsocketd/handler_test.go脚本目录模式下的 URL 解析与 PATH_INFO/SCRIPT_NAME 映射PROC-014 的覆盖来源。手工验证时建议按计划中给出的 wscat 之类的 WebSocket CLI 客户端连接配合--logleveldebug观察每一条CONNECT/DISCONNECT、进程 PID 关联与退出日志即可完整复现本文所述的全部进程生命周期行为。结语从 PROC-001 到 PROC-022websocketd 的进程管理被拆解为一套清晰、可验证的契约一连接一进程的隔离模型、以换行为分帧的 stdin/stdout 管道、默认进日志的 stderr、关闭 stdin → SIGINT → SIGTERM → SIGKILL的升级式终止序列、基于信号量的--maxforks限流以及脚本目录模式下的 URL 路由与 PATH_INFO。这些机制共同保证了任何使用 STDIN/STDOUT 的程序都能零改动变成 WebSocket 服务这一设计初衷的可靠落地。理解这套契约无论是编写脚本后端、排查消息时序问题还是规划高并发部署都能做到有据可依、有章可循。赞分享CLIWebSocket后端【免费下载链接】websocketdTurn any program that uses STDIN/STDOUT into a WebSocket server. Like inetd, but for WebSockets.项目地址https://gitcode.com/gh_mirrors/we/websocketd点击查看免费下载相关推荐libuv 进程句柄uv_process_t完全指南uv_spawn 子进程创建与 stdio 管道通信实战libuv 进程句柄uv_process_t完全指南uv_spawn 子进程创建与 stdio 管道通信实战 导读 本文基于 libuv 官方 API 文网络通信异步编程CATLASS 样例工程中 AscendC 算子调测的实践CATLASS 样例工程中 AscendC 算子调测的实践 AscendC 算子调测 API 提供 kernel 内打印与 Tensor 内容查看两项能力用于桌面应用AI 应用用前必读Lens-Turbo-3.8B-bf16 许可证合规指南MIT、Apache-2.0 与 FLUX.2 的边界用前必读Lens Turbo 3.8B bf16 许可证合规指南MIT、Apache 2.0 与 FLUX.2 的边界 Lens Turbo 3.8B b上一篇GitHub_Trending/re/recipes 持续集成配置GitHub Actions 自动化流程下一篇Claudian 安装上手3 步让 Claude Code 跑进 Obsidian创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考