空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.js ws、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 发出。