tcp_nodelay解决的是Nagle算法导致的“守规矩式等待”延迟，即小数据包（如JSON、响应头）在长连接中因未收到前序ACK而被内核缓冲20–200ms才发出的问题；它专治写完不发的人为延迟，不提升吞吐量。
tcp_nodelay 的作用很明确：关掉 Nagle 算法，让小数据包“写完就发”，不等 ACK、不攒包。它不提速、不增吞吐，专治那种“数据早准备好了，却卡住 20–200ms 才出门”的人为延迟——尤其在长连接下高频发送小响应的场景里效果立竿见影。
它解决的是哪类延迟？
不是网络抖动，也不是后端处理慢，而是 TCP 协议栈内部的“守规矩式等待”：
- Nagle 算法默认开启，逻辑是：如果前一个包还没收到 ACK，新来的小数据（比如几十字节的 JSON、HTTP 响应头、WebSocket ping 帧）就先缓着，要么等 ACK 回来，要么等凑够一整包（MSS）再发
- 这个等待在文件传输里省带宽，在实时交互里就是硬伤——用户点一下按钮，后端毫秒级返回了 {"ok":true}，结果被卡在内核缓冲区里等 ACK，白白多出 40ms 延迟
- tcp_nodelay on 就是告诉内核：“别等，有数据就发”
哪些场景真正受益？
必须同时满足三个条件：长连接 + 小响应（≤1KB）+ 高频连续发送。典型例子包括：
- React/Vue 应用加载的 JS/CSS chunk（几百字节到几 KB，大量复用同一 keepalive 连接）
- WebSocket 实时消息（行情推送、聊天指令、心跳帧）
- SSE 流式事件（data: {...}\n\n 类型的短消息）
- API 网关返回的轻量 JSON（如健康检查 /health、登录态校验、表单验证）
- 服务端渲染 HTML 中内联的小段 JS 或图标响应（ 返回的 1KB 以内 ICO）
纯大文件（>50KB 图片/视频）或短连接接口完全不受影响，也不需要配。
Blender Geometry Nodes Script Generator
下载
生成Blender Python (bpy)脚本，该脚本使用node_groups API和GeometryNodeTree接口程序化地创建几何节点修改器树，用于参数化3D资产生成。
怎么配才真正起效？
不能全局开，也不能随便加。Nginx 中必须满足三要素：keepalive_timeout 已设、作用域精准、避开冲突选项：
- 必须启用长连接：在 server 块中配置 keepalive_timeout 65;，否则 tcp_nodelay 完全无效
-
按路径精准启用：只在小响应路径上开，例如：
location /ws { proxy_pass http://backend; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; tcp_nodelay on; }
location /api/realtime { proxy_pass http://api_cluster; proxy_http_version 1.1; proxy_set_header Connection ''; tcp_nodelay on; } - 禁用干扰项：确保没开 sendfile on（零拷贝绕过 socket 缓冲区，tcp_nodelay 失去作用对象）；也别和 tcp_nopush on 共存（两者逻辑冲突，Nginx 会静默忽略 tcp_nodelay）
为什么不能用 sysctl 全局设置？
Linux 内核根本没有 net.ipv4.tcp_nodelay 这个参数。TCP_NODELAY 是 per-socket 选项，只能由应用在 connect() 之后、send() 之前调用 setsockopt() 显式设置：
- Python：sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1)
- Node.js：socket.setNoDelay(true)
- Java：socket.setTcpNoDelay(true)
- curl 测试：curl --tcp-nodelay http://example.com/api
试图执行 sysctl -w net.ipv4.tcp_nodelay=1 会报错："net.ipv4.tcp_nodelay" is an unknown key。这是常见误解，务必避开。
