WebSocket带宽突增主因是连接管理失控：心跳频率过高、未过滤冗余数据、无效连接堆积、未启用压缩及TLS频繁重连。需抓包分析，优化心跳、状态清理、差分推送与连接复用。
WebSocket 连接后带宽突增，是不是心跳包没控好？
PHP 本身不原生维持 WebSocket 长连接（socket_create 或 fsockopen 建连后得自己管收发），常见“带宽高”其实是服务端持续发心跳、重复推送未过滤数据、或客户端未正确关闭导致连接堆积。先确认是不是心跳频率太高：ping_interval 设成 5 秒却每秒发一次 ping，带宽就直接翻 5 倍。
- 用
tcpdump -i any port 8080 -w ws.pcap抓包，看 payload 是否大量重复{"type":"ping"}或冗余字段 - 服务端若用
Workerman，检查$connection->send()是否在onMessage外误写进定时器循环 - 客户端 JavaScript 若用
setInterval(() => ws.send('ping'), 1000)，但服务端也主动 ping，双向心跳叠加会翻倍流量
PHP 客户端发消息前没压缩，JSON 字段全传？
PHP 用 fsockopen 或 stream_socket_client 连 WebSocket 时，协议层不自动压缩；如果每次发 {"user_id":123,"action":"update","data":{"x":1,"y":2,...}} 这种结构固定、字段多的 JSON，体积很容易超 2KB。真实场景中，省掉空字段、用数字代替字符串 key、启用 deflate 扩展能压到 1/3 大小。
- 服务端支持
permessage-deflate时，PHP 客户端需手动调用gzcompress()并设置RSV1标志位（非简单 base64） - 更稳妥做法：改用短编码，比如
{"u":123,"a":1,"d":{"x":1,"y":2}}，字段映射表存在客户端和服务端约定好 - 避免在 PHP
循环里拼接大数组再
json_encode()，改用json_encode($arr, JSON_PARTIAL_OUTPUT_ON_ERROR | JSON_UNESCAPED_UNICODE)减少转义开销
服务端广播没做连接筛选，全量推送给离线/闲置连接？
很多 PHP WebSocket 服务（如基于 Swoole 或 Workerman）默认用 $server->connections 遍历所有 client fd 发送，但其中可能包含：已断开但未触发 onClose 的僵尸连接、心跳超时未踢的 idle 连接、或权限不足不该接收某类消息的用户。这些无效推送不仅占带宽，还拖慢主循环。
- 必须维护连接状态表，用
tick定时器每 10 秒扫描last_message_time，超 60 秒无交互就$connection->close() - 广播前加白名单判断，例如
if ($conn->authorized && $conn->room_id === $target_room)，别图省事用foreach ($server->connections as $fd) - 对高频率消息（如实时坐标），改用「差分更新」：只传变化字段，而不是整个对象；PHP 端用
array_diff_assoc()计算 delta 再发
SSL/TLS 握手频繁重连，TLS record 层加密开销被忽略？
用 wss:// 时，PHP 客户端每次 stream_socket_client("tls://host:443", ...) 都走完整 TLS 握手，而握手过程要多传几轮加密数据包（ClientHello/ServerHello/Certificate 等），单次就比 ws:// 多 10–20KB 流量。如果业务逻辑导致频繁断连重连（比如错误处理里没复用连接），这部分开销会被放大。
- 确保 PHP 客户端复用 socket 资源：不要每次发消息都新建
stream_socket_client，而是保存$socket句柄并检测feof($socket) === false - 服务端开启 TLS session resumption（Swoole 中设
'ssl_session_cache' => 'shared:SSL:10m'），让二次握手跳过证书交换 - 若非必要，内网通信优先用
ws://，外网才升wss://；别为“看着安全”盲目全站强制 wss
真正卡带宽的往往不是单条消息大小，而是连接生命周期管理松散——一个没清理的 idle 连接，每分钟悄悄吃掉几百 KB；三五个这样的连接，比优化 JSON 压缩更致命。先抓包看实际流量构成，再动代码。
