空Ping帧是高并发WebSocket服务的带宽底线，RFC 6455允许0字节Ping/Pong帧保活，服务端需强制截断非空Ping、禁用客户端定时Ping，并确保ping-pong成对响应以防重连风暴。
心跳包体积直接决定带宽占用下限——1KB 的 ping 帧在 10 万连接、30 秒间隔下，每秒固定产生约 3.3 MB 无效流量；压到 10 字节后，降到 33 KB/s，差两个数量级。这不是“可选优化”，而是高并发 WebSocket 服务的带宽底线。
为什么空 Ping 帧是合法且最省的方案
RFC 6455 明确允许 Ping 帧携带 0 字节负载，服务端收到后必须回复 Pong 帧（同样可为空）。这已足够触发中间设备保活、检测链路连通性，无需任何业务字段。
- 浏览器原生
WebSocket对象不支持手动发Ping，但服务端（如 Node.jsws、Swoole、Netty）可主动调用ping()发空帧 - PHP 客户端用
stream_socket_client或fsockopen时，需自己构造 WebSocket 帧：帧头设0x89（Ping opcode），长度字节为0x00，跳过掩码段（客户端必须掩码，但空负载掩码键可任意填 4 字节，不影响语义） - 抓包验证：Wireshark 中过滤
websocket.opcode == 9，看websocket.payload_length是否为 0
服务端强制限制 Ping 负载大小防误用
开发者常在 ping 里塞 JSON（如 {"ts":1716932640}），既无协议必要，又放大流量。应在服务端入口做硬性截断或拒绝。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Node.js
ws库：监听connection后，在ws.on('ping', data => { if (data.length > 4) ws.terminate(); }) - Swoole：在
onMessage中判断$frame->opcode === WEBSOCKET_OPCODE_PING，再检查strlen($frame->data) - Java Netty +
WebSocketServerProtocolHandler：覆写userEventTriggered，捕获IdleStateEvent之外的原始PingWebSocketFrame，调用content().readableBytes()校验 - 拒绝逻辑比日志更有效：直接
close(CloseStatus.PROTOCOL_ERROR)，避免无效连接持续耗资源
客户端不该发 Ping，除非服务端明确要求
WebSocket 协议不要求客户端主动 ping；绝大多数场景中，仅服务端单向 ping 就够用。客户端加 setInterval(() => ws.send('ping'), ...) 是典型错误，会导致双向心跳叠加、流量翻倍。
- 确认服务端是否已启用自动 ping：如
ws库的server.options.heartbeatInterval，Swoole 的websocket->set(['heartbeat_check_interval' => 30]) - 若服务端未开自动 ping，客户端应只在连接建立后发一次
ping触发握手保活，而非定时轮询 - 前端 JS 中禁用所有
ws.send(...)类心跳逻辑，改用ws.addEventListener('pong', ...)监听服务端响应即可 - 移动端弱网下，
ping频率建议 ≥ 60 秒；频繁重传空帧在丢包率 > 5% 时反而加剧拥塞
真正容易被忽略的是：空 Ping 帧虽小，但若服务端未正确处理 Pong 响应（比如漏掉 ws.pong() 调用），会导致客户端超时误判断连，进而触发重连风暴——此时带宽压力不是来自心跳本身，而是重连握手的 TLS 握手和 HTTP Upgrade 请求。务必在服务端日志中确认每条 ping 都有对应 pong 发出。
