websocket连接数必须在服务端限制，前端控制不可靠；fastapi可用全局active_connections集合硬限流，node.js需结合内存、事件循环与系统负载综合限流。

WebSocket连接数不加限制，服务端内存和文件描述符会很快耗尽，轻则响应变慢，重则进程崩溃。限制必须做，而且得在服务端做——前端控制不可靠，浏览器标签页刷新、脚本重载、异常退出都会绕过它。

FastAPI里用全局计数器硬限流

最直接的方式是维护一个active_connections集合，在websocket_endpoint里检查数量再放行。这种方式简单、无依赖，适合快速验证或低流量场景：

• 每次accept()前检查len(active_connections) >= MAX_CONNECTIONS，超限就调websocket.close(code=1008)
• 必须用try/finally或async with确保连接断开时从集合中移除，否则计数会漂移
• 注意WebSocketState.DISCONNECTED状态可能滞后，不能只靠on_disconnect回调清理
• 单进程有效，多进程部署时需换成Redis计数器，否则各worker独立计数会失效

Node.js + ws库配合内存与事件循环监控

Node.js环境里，光靠wsServer.clients.size不够，因为连接对象可能已断开但未被GC回收，或者事件循环卡住导致新连接堆积：

WebSocket 8.18.2

WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。

下载

• 每秒采样process.memoryUsage().heapUsed，超过阈值（如 1.2GB）主动拒绝新连接
• 用perf_hooks.performance.eventLoopUtilization()监控事件循环延迟，> 5ms 持续 3 秒就触发限流
• 不要只看连接数，要结合os.loadavg()[0]和os.freemem()做综合判断
• ws.Server的maxPayload和skipUTF8Validation参数会影响单连接内存占用，大消息场景必须调小前者、关闭后者

tcpkali压测时绕过系统文件描述符瓶颈

tcpkali是单机压测 WebSocket 的高效工具，但它默认受限于系统ulimit -n。不调这个，连 1000 连接都起不来：

• 运行前必须执行ulimit -n 65535，否则会报too many open files
• 加-w启用 WebSocket 模式后，-c指定的是并发连接数，不是请求数；每个连接会持续存在，直到-T超时
• 测试 WSS 时，openssl握手开销大，建议先用ws://排除 TLS 干扰，确认逻辑正确后再切回wss://
• tcpkali不支持自定义心跳或消息序列，如需模拟真实用户行为（比如每 30 秒发一次 ping），得换 JMeter 或自己写脚本

JMeter分布式压测突破单机 1.6 万连接上限

单机 JMeter 压测 WebSocket 超过 16000 连接基本必崩，根本原因是端口范围（默认 32768–65535）和 JVM 堆内存双重限制。分布式是唯一可行路径：

• 用 Peter Doornbosch 插件，它支持连接池复用和 Ping/Pong 心跳管理，比 Zaleski 版更稳
• 每台 slave 机器分配 5000 连接，配-Xmx4g堆内存，避免 GC 频繁导致连接超时
• master 不参与压测，只负责调度；所有 slave 的user.properties里必须设client.rmi.localport=50000防端口冲突
• 连接建立阶段务必加Uniform Random Timer（100–500ms），否则所有连接在毫秒级内涌进服务端，瞬间打穿握手队列

真正难的不是“怎么限”，而是“限多少”——这个数字必须来自压测数据：先用 tcpkali 找出服务端内存拐点，再用 JMeter 分布式验证该连接数下的 P99 延迟是否达标。硬编码一个 10000，不如动态看 heapUsed 和 event loop utilization。