聊一个经常被问到的配置项：open_tcp_nodelay。很多开发者知道它和 Nagle 算法有关，但具体在 Swoole 里该怎么配、配了之后实际生效范围是什么，以及哪些场景下配了等于白配——里面有不少细节值得理清楚。
先说个结论：open_tcp_nodelay 本质上是一个“取消人为延迟”的开关，不是翻跟斗。对于那些高频小响应、长连接推送的场景，比如 WebSocket、HTTP/2 服务端推送、SSE 实时流，把它设为 true 能直接消除 20-200 毫秒的延迟抖动。但如果你配错了地方，或者协议本身就不支持，那这个配置就等于没写。
open_tcp_nodelay 是什么，为什么需要设为 true
简单来说，open_tcp_nodelay 控制的是 Swoole 服务端在 TCP 层面上，是否启用 TCP_NODELAY 这个 socket 选项。默认值是 false，意味着 Nagle 算法是开启的。Nagle 算法的工作逻辑是：把小数据包攒起来，要么攒到 MSS（最大报文段长度），要么等到之前发送的数据包收到 ACK 确认之后再统一发出去。这样做的好处是减少了网络上的小包数量，提升了吞吐效率，代价是引入了额外的延迟——几十毫秒甚至更多。
是不是觉得，只要设成 true，就等于给数据包按下了快进键？其实没那么玄乎。设为 true 之后，内核会跳过 Nagle 的合并逻辑，应用层调用 send() 或 write() 之后，数据立即发出去，不再等待 ACK 或者凑包。所以这本质上不是“加速发送”，而是“取消人为延迟”。真实效果取决于你的协议特征和网络 RTT。
swoole_http_server 和 swoole_server 的配置差异
虽然两者都支持 open_tcp_nodelay，但生效范围不一样，这块容易踩坑。
swoole_http_server：只对 HTTP 协议连接生效，也就是通过on("request")处理的那些连接。不会影响底层的 TCP 连接池，也不会影响 WebSocket upgrade 之后、后续帧级别的裸 TCP 流。swoole_server（TCP 模式）：对所有 accept 进来的 TCP 连接全局生效。自定义协议、长连接心跳、二进制通信——只要是 TCP 层面的，都受影响。- 特别要注意的是 WebSocket 场景：
swoole_websocket_server继承自swoole_http_server，所以它的open_tcp_nodelay默认只影响 HTTP 握手阶段。一旦 upgrade 成 WebSocket 之后，需要手动在on("open")回调里调用$fd->set(['tcp_nodelay' => true])，才能让后续的数据帧也走无延迟路径。很多人忽略了这一步，导致 HTTP 握手时延迟正常，但 WebSocket 推送还是卡。
容易被忽略的坑：UDP 和 KCP 场景下别乱配
这个坑肉眼可见，但确实有人会踩。open_tcp_nodelay 是纯 TCP 选项，对 UDP 完全无效。如果你在配置里同时写了 open_kcp_protocol => true 和 open_tcp_nodelay => true，后者会被直接忽略——KCP 有自己的 nodelay 参数，必须单独设置。
- 错误写法：
['open_kcp_protocol' => true, 'open_tcp_nodelay' => true]→open_tcp_nodelay不起作用 - 正确写法：
['open_kcp_protocol' => true, 'kcp_nodelay' => true] - KCP 的
kcp_nodelay模拟的是 TCP_NODELAY 的行为，但底层机制完全不同：它控制的是是否启用快速重传以及取消发送间隔限制，和系统级的 socket 选项是两码事。
验证是否生效的最简方式
不要只看配置写对了没，要去操作系统层面确认 socket 确实有了这个标志。步骤也不复杂：
- 服务启动后，用
lsof -i :端口 -n | grep TCP找到主进程的 PID。 - 执行
ss -ti -p "pid=PID"（Linux ≥ 4.1）。观察输出里有没有ts sack字样并且没有nagle提示；更直接的方法是看ss -i输出里的wscale和rtt行为变化——如果 Nagle 被禁用了，数据包的发送行为会有明显不同。 - 代码层面，也可以在
onConnect回调里加一段日志：var_dump($server->connection_info($fd)['tcp_nodelay'] ?? 'unknown');。注意这个字段只在连接建立后才可读，并且需要 Swoole ≥ 4.8.13 版本才支持。
最后想提醒一点：真正关键的不是“配置开了没”，而是“开了之后，你的业务请求是否还出现首字节延迟”。如果你在前面挂了 nginx 做反向袋里，记得检查 upstream 里是否也配了 tcp_nodelay on;——否则 Swoole 这边开得再猛，数据到了 nginx 那层又被攒起来了，等于白费功夫。
