长连接与连接复用的关键点
长连接省去反复握手与 TLS 协商，也跳过 TCP 慢启动，能明显降低请求延迟与服务器 CPU 消耗。它带来一个必须处理的细节：各层都有空闲超时，如果客户端保活周期长于中间层或服务端的空闲超时，请求就可能被复用到一条对端已关闭的连接上，表现为偶发的连接重置或 502。基本规则是外侧（靠近客户端）的超时短于内侧，逐层递增，并保证关闭走优雅流程。
基本信息
| 配置 | 客户端空闲超时要短于服务端与负载均衡的空闲超时 |
|---|---|
| 收益 | 省握手与 TLS 协商，降低请求延迟与 CPU 消耗 |
| 风险 | 超时层级错配导致复用到已关闭连接 |
| 典型层 | 客户端库、负载均衡、反向代理、应用服务器、上游连接池 |
典型使用场景
- 高并发 API 网关：复用连接降低握手开销，提升单位时间请求量
- 数据库访问：连接池复用连接，避免频繁建连的认证与内存开销
- 微服务间调用：长连接减少跨服务的握手与 TLS 开销
- 移动端保活：在弱网下维持连接，需要与应用前后台策略配合
- 发布期间连接排空：滚动发布时先停止接收新请求，再等待在途请求完成
超时层级示例
超时层级示例
客户端保活周期 55s
负载均衡空闲超时 75s
网关 keepalive 90s
上游应用空闲关闭 120s
统一规则：外侧（更靠近客户端）超时短于内侧，
逐层递增；任何一层的关闭都走优雅流程，
先停止接收新请求，再等待在途请求完成常见现象与排查方向
| 现象 | 可能原因 | 排查方向 |
|---|---|---|
| 偶发 502 或连接重置 | 复用到了已关闭的连接 | 对比客户端保活周期与中间层空闲超时 |
| 发布后短暂错误上升 | 连接被硬关闭，在途请求中断 | 检查是否有优雅关闭与连接排空 |
| 连接数持续偏高 | 空闲连接未回收 | 检查客户端池的保活与空闲回收配置 |
| 首字节时间偏长 | 连接被反复重建 | 统计连接建立次数与握手耗时 |
使用要点
- 出现偶发“连接被重置”时先核对整条链路各层的空闲与优雅关闭超时
- 发布时先摘流再关闭连接：让负载均衡停止转发新请求，等待在途请求完成
- 客户端池要能检测失效连接并在失败后重建，避免持续复用坏连接
- 保活探测要有节制：频率过高会带来额外流量与唤醒开销，尤其在移动端
- 把连接建立次数做成指标：重建频繁说明复用没有生效，收益无从体现
出现偶发“连接被重置”时先核对整条链路各层的空闲与优雅关闭超时，而不是先怀疑应用代码；这类问题多数由超时层级错配导致。
发布期间未做优雅关闭会让在途请求被中断：表现为发布后短暂错误率上升，容易被误判为代码缺陷而浪费时间排查。