长连接与短连接无绝对优劣，关键看业务是否需要复用连接；性能差异体现在tcp握手开销、后端压力、首屏体验和资源占用上，api网关适合长连接，静态资源收益有限，iot/im等保活场景则为刚需。
长连接和短连接没有绝对优劣，关键看业务是否真正需要复用连接。性能差异主要体现在TCP握手开销、后端连接压力、首屏加载体验和系统资源占用上，不同场景下表现截然不同。
API网关类业务：长连接明显占优
高频、小体量请求（如微服务调用、APP接口轮询）天然适合长连接。Nginx默认 keepalive_timeout 75s，配合后端启用 HTTP/1.1 和连接池，能大幅减少握手次数。
- 100次请求在短连接下需200次TCP握手；长连接仅需1次初始握手
- 实测后端TCP连接数可下降约70%，QPS提升35%
- 必须同步配置后端 keepalive 参数（如 Node.js 的 agent.keepAlive = true），否则 Nginx 与后端之间仍是短连接
- WebSocket 等协议需显式设置 proxy_http_version 1.1、Upgrade 和 Connection 头，并延长 proxy_read_timeout（建议≥3600s）
静态资源服务：长连接收益有限但无需关闭
HTML/CSS/JS等静态文件响应极快（毫秒级），单次连接耗时本身不构成瓶颈。浏览器通常并行发起多个请求，是否复用连接对单个资源影响不大，但对整页加载有间接作用。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 现代浏览器默认使用 HTTP/1.1 并开启 Keep-Alive，Nginx 无需额外配置即可支持
- 若前端资源路径带哈希（如 /static/js/app.abc123.js），且 CDN 或浏览器缓存已生效，连接复用价值进一步降低
- 不建议为静态服务单独关闭 keepalive——它几乎不增加负担，反而能避免首屏多资源请求时反复建连的微小延迟
IoT/IM等保活型业务：长连接是架构刚需
设备心跳、消息通道、实时行情推送等场景，连接长期空闲但必须稳定存活。此时长连接不是优化项，而是系统可用性的前提。
- 需调大内核参数：net.core.somaxconn 和 fs.file-max，防止句柄不足
- Nginx worker_connections 建议设为 65535，启用 use epoll（Linux）
- upstream 中配置 keepalive 100，表示每个 worker 最多缓存 100 个空闲后端连接
- 配合 least_conn 负载均衡算法，避免某台后端因连接堆积而响应变慢
何时考虑禁用长连接？仅限极少数情况
生产环境一般不建议全局关闭，只有在明确遇到兼容性或调试需求时才局部处理。
- 后端服务老旧，无法正确解析 HTTP/1.1 keepalive，频繁出现连接异常或超时
- 做精确连接计数审计，且确认所有客户端都支持 Connection: close
- 调试阶段临时隔离问题，用于对比基线性能
- 可通过 location 精确控制，例如：location /health { keepalive_timeout 0; }
