tcp_nodelay on仅对已升级的websocket长连接有效，需满足三条件：location中配置upgrade/connection头、proxy_read_timeout≥65s维持长连接、后端与客户端同步关闭nagle算法。
WebSocket传输延迟高，问题大概率不在协议本身，而藏在连接链路的某个环节——可能是Nginx没配对、服务端onOpen里查了数据库、客户端用了JSON.stringify发大包，或者压根连错了运营商线路。直接调优往往无效，得先定位卡点。
为什么tcp_nodelay on加了也没用？
Nginx 的 tcp_nodelay 只对已升级成功的 WebSocket 长连接生效，不是所有 HTTP 连接都管用。它只解决 Nagle 算法导致的小包攒发（比如连续几个 ping 或状态更新），但前提是：
- location 块里必须有
proxy_set_header Upgrade $http_upgrade和proxy_set_header Connection "upgrade"，否则 Nginx 当普通 HTTP 转发，tcp_nodelay根本不触发 -
proxy_read_timeout得 ≥ 65s，否则连接被提前断开，长连接不存在，优化对象都没了 - 后端和客户端 socket 也要关 Nagle：Node.js 需显式调
socket.setNoDelay(true)；C# 的ClientWebSocket默认已关，但自定义TcpClient就得手动设 - 用
ss -i dst <ip>:<port></port></ip>查连接，输出含nodelay才算真正启用
onOpen 回调里做同步操作是最大陷阱
握手返回 101 Switching Protocols 后，onOpen 立刻执行，但只要里面调一次 MySQL 查询、读一个配置文件或等 Redis 返回，整个事件循环就卡住——所有新消息都会排队，首帧延迟从几毫秒飙到几百毫秒。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- Swoole/Workerman：把鉴权、上下文初始化改用协程（
go(function () { ... })）或异步客户端（Co::mysql） - Netty：业务逻辑必须提交到
EventExecutorGroup外的线程池，不能直接channel.writeAndFlush() - FastAPI/Uvicorn：
websocket.accept()后别立刻await db.query()，先asyncio.create_task()拆出去 - ReactPHP：禁用
stream_select轮询，改用Loop::addReadStream+ 异步 MySQL 驱动
跨运营商网络下，new WebSocket() 不能只写一个地址
电信用户访问部署在联通机房的服务，BGP 多跳+路由绕行会导致 RTT 翻倍、抖动剧烈。HTML5 的 WebSocket API 不会自动选线，必须前端主动干预：
- 预置多个 endpoint，例如
wss://ws-telcom.example.com（电信专线）、wss://ws-unicom.example.com（联通专线） - 用
fetch(url, { method: 'HEAD', cache: 'no-store' })并记录performance.now()耗时，选最快且返回 200 的地址 - 若
onopen在 2.5 秒内未触发，自动 fallback 到次优地址；最多试 2 轮，避免无限重连 - 服务端配合返回当前节点归属运营商（如响应头
X-ISP: telecom），前端可存 localStorage 下次免探测
消息体膨胀比网络慢更致命
一个 300KB 的 JSON 字符串，即使走千兆内网，序列化+解析+GC 也能拖出 200ms 延迟。WebSocket 不是万能管道，得控制单帧负载：
- 禁用
JSON.stringify()发原始对象，改用ArrayBuffer + DataView手动序列化关键字段（如时间戳、ID、状态码） - 二进制帧设
websocket.binaryType = 'arraybuffer'，避免 UTF-8 编码/解码开销 - 非实时消息（如日志、快照）走独立 HTTP 接口或合并批量上报，别挤占主通道
- Uvicorn 启动加
--ws-per-message-deflate开启 permessage-deflate 压缩，但注意移动端兼容性
真正难的不是加参数，而是区分哪些延迟来自 TCP 层、哪些卡在 PHP 的 fread() 轮询里、哪些是前端 DevTools 里根本看不到的中间 CDN 静默超时——得靠 tcpdump 抓包看帧间隔，靠服务端 microtime(true) 打点比对，靠客户端 performance.now() 记录 open 到 message 的真实耗时。没有一招鲜，只有层层剥茧。
