websocket握手返回101仅表示协议切换成功，并不保证低延迟；首帧延迟常见于服务端同步阻塞、代理超时或事件循环未优化等环节。
WebSocket连接成功返回 101 Switching Protocols 只是握手完成，不代表后续通信就低延迟——很多真实场景中，首条业务消息仍要等几百毫秒才到达客户端，问题往往出在服务端处理链路而非协议本身。
握手后第一帧发送被阻塞的常见原因
握手成功后，open 事件触发，但紧接着调用 send() 却迟迟不发出去，典型表现是前端 onmessage 延迟触发。这通常不是网络问题，而是服务端逻辑卡在同步环节：
- PHP-FPM 模式下直接用
fsockopen或stream_socket_client手动实现 WebSocket，未设非阻塞模式，send()调用会等待 TCP 缓冲区可写，而高负载时内核缓冲区可能满 - Swoole/Workerman 中在
onOpen回调里做了同步数据库查询或文件读取，阻塞了事件循环 - Java Netty 服务端未将业务逻辑提交到
EventLoopGroup外的线程池，导致channel.writeAndFlush()实际排队等待
Swoole 中避免 onOpen 阻塞的实操要点
onOpen 是事件循环中的关键入口，任何耗时操作都会拖慢所有连接的响应。必须剥离同步行为：
Smart Model Switcher V5
下载
智能模型自动切换 V5.0.2 - 多模态感知，自动识别图片/视频/音频/代码/文本任务，切换最优模型。支持图片理解(qwen3-vl-plus)、视频音频(qwen3.5-plus)、代码(glm-5)、Office文档(MiniMax-M2.5)、推理等场景。零感知切换，无需手动操作。
- 把用户鉴权、上下文初始化等操作改为异步：用
go(function () { ... })启协程，或调用Co::mysql等协程客户端 - 不要在
onOpen里调用$server->push($fd, $data)—— 改为先存入内存队列（如Swoole\Table），再由定时器或onMessage触发广播 - 检查是否启用了
dispatch_mode = 3（纯抢占式），否则多进程间连接 fd 映射可能引发 write 冲突
CDN 或反向代理引入的隐性延迟
即使服务端立刻 write，客户端也可能收不到——CDN 或 Nginx 默认对 Upgrade 后的长连接施加空闲超时限制：
- Nginx 需显式配置：
proxy_read_timeout 3600;、proxy_send_timeout 3600;，且必须放在location块内，不能只写在http全局 - Cloudflare 免费版默认 100 秒超时，且不透传
Ping/Pong帧；需升级到 Pro 或自建边缘节点 - 阿里云 SLB 的 WebSocket 超时不可调，低于 60 秒会静默断连；建议改用 ALB 或直连后端
心跳与首帧时间戳验证方法
延迟是否真来自服务端？最可靠的方式是打点比对：
- 在服务端
onOpen回调开头记录microtime(true)，在push()前再记一次，差值超过 5ms 就说明有阻塞 - 客户端用
performance.now()记录onopen和onmessage时间戳，若差值 >100ms 且服务端打点正常，则问题在中间链路 - 用
tcpdump -i any port 9501 -w ws.pcap抓包，看 SYN → 101 → 第一个 WebSocket DATA 帧之间是否存在空白期
真正影响首帧延迟的，从来不是 WebSocket 协议本身，而是你如何把它嵌进现有架构——从 PHP 的同步阻塞、到 Nginx 的 timeout 配置、再到 CDN 对 Ping 帧的丢弃，每一层都可能悄悄加几十毫秒。别只盯着 101 状态码，它只是起点。
