WebSocket响应延迟主因是服务端onOpen阻塞、代理超时或客户端配置失配；101仅表握手成功，首帧延迟90%以上源于可调环节，如Swoole中onOpen同步操作、Nginx未设proxy_read_timeout、Cloudflare免费版100秒静默断连等。
WebSocket响应延迟不是协议问题，而是服务端处理链路、中间代理或客户端配置没对齐导致的。101状态码只说明握手成功，首帧发不出去或客户端收不到，90%以上都出在可调环节。
onOpen里别做同步操作（Swoole/Workerman/Node.js通用）
服务端onOpen回调一卡，所有新连接都会排队等——这不是并发低，是事件循环被堵死。
- PHP Swoole：禁止在
onOpen里调用$server->push()或Co::mysql->query()，改用go(function () { ... })启协程异步处理 - Node.js ws库：避免
ws.on('connection', (socket) => { await db.query(...) })，应把DB操作移到socket.on('message')之后或用setImmediate()脱钩 - Java Netty：
channel.writeAndFlush()必须提交到EventLoopGroup外的业务线程池，否则阻塞整个channel
Nginx/CDN/SLB这些“透明层”会静默杀连接
很多延迟根本不在你代码里，而是在反向代理空闲超时设置上。它们不报错，只断连，客户端看到的就是“突然没响应”。
WebSocket 8.18.2
下载
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Nginx：必须在
location块内加proxy_read_timeout 3600和proxy_send_timeout 3600，http全局配置无效 - Cloudflare免费版：默认100秒超时，且不透传
Ping/Pong帧，客户端onclose可能收不到原因码 - 阿里云SLB：WebSocket超时固定为60秒且不可调，建议换ALB或直连后端
客户端send()后没立刻收到onmessage？先确认是不是缓冲区或压缩惹的祸
前端看似调用了ws.send()，但服务端onMessage迟迟不触发，常见于消息体未及时flush或压缩策略不匹配。
- Angular：
binaryType: 'arraybuffer'比'blob'减少一次类型转换，对二进制消息尤其明显 - 浏览器原生API：发送大JSON前用
pako.gzip()压缩，再base64编码，服务端解压——实测可降50%+传输耗时 - OkHttp（Android）：启用
webSocketBuilder.pingInterval(20, TimeUnit.SECONDS)，避免因心跳缺失被中间设备断连
vLLM + Open-WebUI这类AI场景要防“连接池饥饿”
大模型流式输出依赖长连接持续推送，但Open-WebUI默认每次提问建新WS连接，vLLM又没做连接复用，高频请求下连接建立开销就吃掉大部分延迟。
- 强制复用：前端用
WebSocketPool类管理连接，max_size设为10～20，避免反复new WebSocket() - vLLM启动加
--ws-max-size 16777216 --ws-per-message-deflate，开启permessage-deflate压缩 - 关键路径打点：服务端在
onOpen开头和push()前各记一次microtime(true)，差值＞5ms就要查协程/线程是否被占
真正难调的不是单点参数，而是整条链路的时间分布——从onOpen触发、鉴权完成、上下文加载、首token生成、到第一帧write系统调用返回，每个环节都要有毫秒级观测能力。没有打点，优化就是盲人摸象。
