php连接websocket帧类型咋区分_php连接websocket帧解析法【步骤】

WebSocket帧类型需手动解析帧头opcode：0x1为text、0x2为binary、0x8为close、0x9为ping、0xA为pong；PHP无内置客户端，须用unpack取前两字节并$second & 0x0F提取opcode。

WebSocket 帧类型怎么从 PHP 连接里识别

PHP 本身没有内置 WebSocket 客户端，所以你用的大概率是 ext-websocket、ratchet/pawl、react/socket 或手写 socket + 协议解析。帧类型（如 text、binary、ping、pong、close）不靠 PHP 函数自动暴露，得自己从原始帧头里解出来。

关键点：WebSocket 帧结构固定，前 2 字节就含 FIN、RSV、opcode，其中 opcode 决定帧类型：

• 0x1 → text frame
• 0x2 → binary frame
• 0x8 → close frame
• 0x9 → ping
• 0xA → pong

如果你用的是 react/socket 或原生 fsockopen + fread，读到数据后必须先解析帧头。例如，用 unpack('Cfirst/Csecond', $raw) 拿前两字节，再对 $second & 0x0F 取低 4 位得 opcode。

用 Ratchet/Pawl 怎么拿到原始帧或 opcode

ratchet/pawl 是高层封装，它默认把 text/binary 帧转成字符串/资源，直接丢掉 opcode 信息。想区分帧类型，不能只监听 onMessage，得换到更底层：

• 改用 Pawl\Client 的 on('data', ...) 事件，接收原始二进制流
• 手动调用 WebSocket\Frame::fromString($data)（需 textalk/websocket 包）还原帧对象
• 或者继承 Pawl\Client，重写 handleData，在调用父类前先解析 $data[0] 和 $data[1]

注意：onMessage 回调里的 $message 已经是解包后的 payload，opcode 丢了——这是最常踩的坑。

手写 socket 解析 WebSocket 帧头的实际步骤

从 fread($socket, 2) 开始，逐字节解析帧头，不是一步到位的事。真实步骤如下：

• 读前 2 字节：$header = fread($socket, 2)，用 unpack('Cfirst/Csecond', $header) 得到数值
• 提取 opcode = $second & 0x0F；判断是否分片（$first & 0x80 非零表示 FIN=1）
• 看 $second & 0x80 是否为 1，决定是否有 mask key（客户端发帧必有 mask，服务端回帧不能有）
• 读 payload length：若 $second & 0x7F 是 126，再读 2 字节；是 127，再读 8 字节；否则就是真实长度
• 如有 mask key（4 字节），读出来，再读 payload，最后用 mask 解密

别跳过 mask 解密——客户端发来的所有帧都带 mask，不处理会得到乱码，且 opcode 判断可能因错位而失败。

为什么 var_dump() 看不到帧类型，但抓包能看到

因为大多数 PHP WebSocket 库在收到数据后立刻解帧、去 mask、拼 payload，然后只把干净内容抛给上层回调。Wireshark 或 tcpdump 抓的是裸 TCP 流

验证方法：在 fread 后立刻 bin2hex($raw) 打印前 16 字节，对照 RFC 6455 的帧格式查第一个字节的 bit 分布。比如 81 05 68 65 6c 6c 6f 中，81 的二进制是 10000001，FIN=1，opcode=1 → text frame；05 是 masked payload len=5。

真正难的不是解析，而是保持状态：分片帧（FIN=0）、连续多个 0x0 opcode 的 continuation frame，需要缓存上下文。这点几乎所有轻量库都默认忽略，得自己补。