WebSocket 速率限制与防抖控制本质不同：前者在握手阶段用 Nginx 或服务端令牌桶限流防攻击，后者在 onmessage 中对 UI 更新等副作用做节流/防抖保体验，二者须分层设计不可替代。

WebSocket 消息发送速率限制和防抖控制不是一回事，但常被混用。关键区别在于：速率限制管“发多少”，防抖/节流管“怎么响应”。前者防攻击、保服务稳定；后者防卡顿、保用户体验。两者必须分层设计，不能互相替代。

握手阶段：用 Nginx 或服务端拦截高频建连

恶意脚本可能在几秒内发起上百次 WebSocket 握手请求，耗尽服务端连接资源。此时限流必须发生在 HTTP 升级（Upgrade）阶段：

• Nginx 配置 limit_req 针对 Upgrade: websocket 请求，例如每分钟最多 10 次握手，超限返回 429
• 服务端（如 uWebSockets 或 Express + ws）在 .upgrade 回调中读取客户端 IP 和自定义标识（如 Sec-WebSocket-Protocol 头里的 client-id），用 Redis 原子计数（Lua 脚本保证 incr + expire）做 60 秒窗口频控
• 拒绝策略要前置——不能等到 .open 再检查，否则连接已建立，资源已被占用

连接建立后：为每个连接配独立令牌桶

单个连接也可能被滥用，比如疯狂发 ping、批量伪造业务消息。这时需会话级限流：

WebSocket 8.18.2

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

下载

• 每个 WebSocket 连接初始化时，分配一个专属令牌桶（如每秒 5 个 token，桶容量 10）
• 每次调用 send() 前执行 bucket.tryConsume()，失败则直接关闭连接（错误码 1008）
• 避免全局共享桶，否则正常用户会被恶意用户拖累
• uWebSockets 可结合 .maxBackpressure（如设为 10MB）触发背压，配合 closeOnBackpressureLimit = false + 自定义 dropped 处理，柔性降级

前端 onmessage 回调里：只对副作用逻辑做节流或防抖

onmessage 本身绝不能被防抖或节流——那会丢消息、破坏语义。真正需要控制的是它触发的 UI 更新、状态计算等操作：

• 消息代表「最终状态」（如配置更新、校验结果）→ 用 防抖，只保留最后一次，避免重复弹窗或渲染
• 消息代表「连续事件流」（如光标位置、传感器数据、K 线 tick）→ 用 节流，建议间隔 16ms–60ms，匹配浏览器帧率
• 高吞吐场景（如每秒 100+ 行情推送）→ 推荐 缓冲 + 批量节流：攒够 30 条或满 60ms 就统一处理，清空定时器，加 try/catch 防解析崩溃
• 大对象消息（如完整快照）务必移出主线程：JSON.parse 和深拷贝放 Web Worker，主线程只收结构化数据

服务端发送端也需节奏控制

后端主动推送同样可能压垮前端，尤其广播类场景（如行情、协作状态）：

• 避免无差别 ws.send(data)，应按客户端能力分级：移动端可聚合 200ms 内数据，桌面端可放宽至 50ms
• 若已做服务端消息合并（如 50ms 合并成交），客户端节流间隔应 ≥ 合并周期，否则会放大抖动
• 对低带宽或弱网设备，可协商启用压缩（permessage-deflate）或降采样协议（如只推 delta 变更）