上位机远程监控系统实战手记：用 WebSocket 打通工业现场与云端的“神经末梢”
你有没有遇到过这样的场景？
凌晨三点，产线报警灯狂闪，值班工程师抓起手机点开监控页面——温度曲线还在 10 秒前的缓存里跳动；
操作员在平板上点击“急停”，指令却卡在 HTTP 请求队列中，等了 800ms 才收到200 OK；
IT 部门刚部署完新版本 Web 界面，结果发现 PLC 数据每 5 秒轮询一次，Nginx 日志里全是GET /api/status?id=PLC_007的重复请求……
这不是故障，是通信范式错配。当设备已能毫秒级采样、边缘网关具备实时推理能力时，我们还在用为文档传输设计的 HTTP 协议，去承载对时间敏感的工业控制流。
真正让上位机“活起来”的，不是更炫的图表，而是数据抵达前端的那一瞬间是否真实、确定、可追溯。而 WebSocket，正是这根打通“最后一公里”的低延迟神经纤维。
为什么是 WebSocket？不是 HTTP/2，也不是 MQTT？
先说结论：它不是万能胶，但却是当前工业远程监控中最平衡的选择。
- HTTP/2 Server Push 看似先进，但它本质仍是“服务端单向推送”，客户端无法在同一连接上发指令；而且 Push 流不可取消、不可复用，实际部署中极易被中间代理（如企业防火墙）静默丢弃；
- MQTT 虽为物联网而生，但它的发布/订阅模型在“一对一强绑定”的上位机场景中反而冗余——你需要额外维护 broker、topic 权限、QoS 级别，而绝大多数上位机需求只是“我要看这台设备的实时值，并能点一下让它停机”；
- WebSocket 则像一条双向对讲机线路：握手一次，从此两端随时开口、随时倾听。帧头最小仅 2 字节（无 mask），不带 Cookie、User-Agent、Accept-Encoding 这些 HTTP 的“行李”，带宽利用率比轮询高 8～12 倍（实测 100 台设备并发时，WebSocket 总流量 ≈ 1.3MB/s，同等数据量 HTTP 轮询达 14MB/s）。
更重要的是——它原生支持浏览器。这意味着你的上位机不用再打包 Electron、不用适配 WinCE、不用给每个工控机装 ActiveX 插件。只要打开 Chrome 或 Edge，输入网址，就能看到和中控室大屏完全一致的实时画面。
握手之后，真正的挑战才开始
很多人以为new WebSocket(url)成功，就等于“连上了”。其实不然。真正的连接，始于第一次心跳被确认，终于最后一次 Pong 被记录。
我们曾在线上某食品包装线调试时发现：设备端日志显示“WebSocket 已连接”，但上位机仪表盘整整 3 分钟没刷新。抓包一看，设备确实在发Ping，但服务端根本没回Pong——原因竟是 Node.js 的ws库默认关闭了自动响应，而开发人员误以为“库会处理一切”。
于是我们把心跳逻辑彻底收归服务端统一管控：
// 不再依赖客户端 Ping → 服务端主动探测 const clients = new
