WebSocket连接中如何实现Ping/Pong双向心跳彻底防止虚假在线方法【详细】-js教程-PHP中文网

WebSocket协议层Ping/Pong需服务端主动发起，浏览器原生API不支持手动发送/监听；前端应采用应用层心跳（'ping'/'pong'字符串），配合lastPongTime超时判定、readyState检查及pongTimeoutTimer强制重连，并要求服务端配置pingTimeout、禁用主动ping、及时终止假活连接。

WebSocket协议层Ping/Pong必须由客户端主动发，服务端被动回

浏览器原生 websocket 实例不支持手动发送 ping 帧（opcode 0x9），也不能监听或拦截底层 pong 帧（opcode 0xa）。也就是说：你调用 ws.send('ping') 发的只是普通文本消息，不是协议级心跳——它无法触发浏览器自动响应 pong，也无法绕过中间设备的静默超时检测。

真正起作用的协议级 Ping/Pong 必须依赖服务端主动发起（如 ws 库的 ping() 方法）或客户端使用支持该能力的封装库（如 uWebSockets.js、ws 客户端版、或 Electron 环境下的自定义 socket）。但绝大多数 Web 前端场景下，只能退而求其次：用「应用层心跳」模拟协议行为，并配合服务端协同设计。

服务端需启用 pingTimeout（如 ws 库设为 60000），并在收到客户端发来的 "ping" 字符串后，立即调用 ws.ping() 或直接 ws.send('pong')
客户端不能只靠 setInterval 发送字符串，还必须维护一个 lastPongTime 时间戳，在 onmessage 中识别 'pong' 并更新它
若 Date.now() - lastPongTime > 90000（建议 ≥ 1.5 倍心跳间隔），就应判定连接“假死”，而非等待 onclose 被动触发

如何避免“发了 ping 却收不到 pong”导致的误判

常见错误是把 onmessage 当作通用消息通道，未区分业务数据和心跳响应。一旦服务端返回的 'pong' 和某条业务消息结构相同（比如都用 JSON、都含 type: 'pong'），或网络抖动导致 pong 延迟到达，客户端就可能漏处理、重复处理，甚至把 pong 当成业务指令执行。

解决方法很直接：约定唯一、不可伪造的心跳标识，且不走业务解析流程。

客户端发心跳统一用纯字符串 'ping'（非 JSON，无空格/换行），服务端匹配 if (data === 'ping') 后立刻 ws.send('pong')
客户端 onmessage 中先做字面量判断：if (event.data === 'pong') { lastPongTime = Date.now(); return; }，之后再走 JSON.parse 逻辑
禁用所有中间件对 'ping'/'pong' 的日志记录或审计，防止它们被当成异常流量拦截

为什么光有心跳还不够？必须配合 readyState + error 事件兜底

readyState 是表象，onerror 是残缺信号，单靠它们无法识别“连接仍为 OPEN 但已无法通信”的假在线状态。典型表现：页面没报错、ws.readyState === 1，但发消息后服务端完全收不到，也不触发 onclose。

WebSocket 8.18.2

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

下载

这就是为什么必须用「主动探测 + 超时判定」代替被动监听：

不要依赖 onclose 作为唯一断连依据——它可能永远不触发（尤其在 NAT 超时后）
每次发 'ping' 前检查 ws.readyState !== WebSocket.OPEN，则跳过本次发送并立即重连
设置独立的 pongTimeoutTimer：发完 'ping' 后启动，超时未清则 ws.close(4001, 'pong timeout')，强制走重连流程
onerror 里只做日志，不重连；真正重连动作必须由心跳超时或 onclose（带明确 code）触发

服务端如何配合才能让心跳真正生效

服务端不是“收到 ping 就 send pong”这么简单。如果它不主动管理连接活性，客户端再严谨也白搭。关键点在于：服务端必须用读写超时机制反向约束客户端行为。

Node.js + ws 库必须配置 pingTimeout: 60000（对应客户端心跳间隔 ≤ 30s），否则服务端不会因未收 ping 而关连接
禁用服务端主动 ping（即设 pingInterval: 0），避免和客户端心跳竞争，也防止服务端 ping 被中间设备丢弃后误判
每个连接实例绑定唯一 clientId，在收到 'ping' 时更新其最后活跃时间；定时扫描超时连接并 ws.terminate()（比 close() 更彻底）
不要在 on('message') 里做耗时操作（如数据库查询），否则会阻塞 pong 响应，导致客户端误判超时