实战排查 Linux 生产环境高并发下 TIME_WAIT 与 CLOSE_WAIT 堆积成因及线上平滑调优

一、生产环境问题背景

在分布式架构与微服务体系中，服务节点之间存在频繁的 RPC 调用、HTTP API 请求以及对下游数据库/缓存的连接交互。某核心微服务网关在高并发业务峰值期间，监控系统频繁触发告警，日志中出现大量如下典型错误：

dial tcp 10.0.1.25:8080: connect: cannot assign requested address

或者偶发伴随：

java.io.IOException: Too many open files

登录该生产节点执行系统级网络连接快照检查：

ss -s

输出显示 TCP 连接数异常暴涨：

Total: 32410
TCP:   31200 (estab 2400, closed 0, orphaned 12, timewait 28500)

进一步通过统计脚本拆解所有 TCP 连接状态分布：

netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

结果显示两处致命异常：

1. TIME_WAIT 状态高达 28500 多个，几乎将 Linux 默认的本地临时端口资源消耗殆尽；
2. 内部某业务实例的连接池中，同时存在数百个持续处于 CLOSE_WAIT 状态的连接，且存活时间超过数小时未消失。

二、TCP 状态机机制与本质差异剖析

要彻底解决该问题，必须准确厘清 TIME_WAIT 与 CLOSE_WAIT 在四次挥手协议中的本质差异。

1. TIME_WAIT：主动关闭方的正常保护机制

当主动发起关闭连接的一方发送最后一个 ACK 响应后，必须在该状态停留 2MSL（Maximum Segment Lifetime，Linux 内核通常固定硬编码为 60 秒）。其核心作用有两个：

• 保证全双工连接可靠关闭：若被动关闭方未收到最后的 ACK，会超时重传 FIN，主动关闭方处于 TIME_WAIT 才能重新回传 ACK；
• 防止旧连接的迟到报文混淆新连接：确保本次连接产生的所有报文在网络中自然消亡，避免新复用端口的连接收到脏报文。

因此，TIME_WAIT 发生在主动关闭方。生产中出现数万个 TIME_WAIT，根本原因在于客户端（或充当客户端的代理网关）频繁使用短连接发起请求，每次请求完毕即主动断开。

2. CLOSE_WAIT：被动关闭方的应用层未释放

当被动关闭方接收到对端发送的 FIN 并自动回复 ACK 后，操作系统内核会进入 CLOSE_WAIT 状态，并通知上层应用程序读取结束。此状态要求本端应用程序主动调用 close() 关闭 Socket，内核才会向对端发送 FIN 报文。

如果连接长时间停留在 CLOSE_WAIT，说明操作系统内核已经完成了握手响应，但应用程序没有执行关闭 Socket 的逻辑（例如代码异常未在 finally 中 close、线程池阻塞、HTTP 连接池泄露等）。CLOSE_WAIT 无法通过修改操作系统内核参数直接消除，必须修复应用层代码。

三、现场实战排查与诊断流程

1. 快速定位 CLOSE_WAIT 关联的具体进程

执行以下命令，列出所有处于 CLOSE_WAIT 状态且带有 PID 信息的套接字：

ss -tpn state close-wait

或者利用 lsof 关联进程已打开的文件描述符：

lsof -i :8080 | grep CLOSE_WAIT

通过进程 PID 追踪对应的 Java/Go/Python 进程调用栈：

jstack <PID> | grep -A 20 -B 5 "run"

排查发现，某下游监控上报组件在发起 HTTP 请求发生 SocketTimeoutException 时，直接在 catch 块中记录日志并 return，未在 finally 块中释放 HttpURLConnection 输入流与连接，导致对应底层 FD 一直被占用，形成 CLOSE_WAIT 僵死连接。

2. 检查系统可用临时端口范围

检查当前内核允许分配的客户端临时端口范围：

cat /proc/sys/net/ipv4/ip_local_port_range

默认情况下很多系统配置为 32768 60999，总可用端口仅 28232 个。当 TIME_WAIT 数量达到两万多时，新发起的主动连接便无法分配到可用源端口，直接抛出 cannot assign requested address 错误。

四、生产级平滑调优与解决实践

针对上述诊断结果，实施分层治理方案。

1. 应用架构优化：长连接复用（治本之策）

在高并发服务间调用中，全面废弃每次交互新建连接的短连接模式：

• 在微服务网关、Nginx 反向代理配置中开启 upstream keepalive：

  upstream backend_service {
      server 10.0.1.25:8080 max_fails=3 fail_timeout=10s;
      keepalive 256;
      keepalive_requests 10000;
      keepalive_timeout 60s;
  }
  

• 在客户端代码中配置带连接复用池的 HTTP Client（如 Apache HttpClient 开启 PoolingHttpClientConnectionManager，设置合理的 maxTotal 和 defaultMaxPerRoute）。

2. Linux 内核参数精准调优

针对依然存在的突发性网络连接，通过优化 /etc/sysctl.conf 提升网络栈吞吐能力：

# 1. 扩大本地端口分配范围
net.ipv4.ip_local_port_range = 1024 65535

# 2. 允许将处于 TIME-WAIT 状态的套接字重新用于新的 TCP 连接（仅对安全时戳有效）
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_timestamps = 1

# 3. 设置系统允许保留的 TIME_WAIT 套接字上限，防止耗尽内存
net.ipv4.tcp_max_tw_buckets = 262144

# 4. 优化孤儿连接与 FIN 超时时间（默认为 60s，可缩短为 15-30s）
net.ipv4.tcp_fin_timeout = 20

# 5. 调整 TCP 保持存活探测参数，快速发现断网死链
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

执行使参数立即生效：

sysctl -p

特别注意：切勿盲目开启已在 Linux 内核 4.12 之后被废弃的 net.ipv4.tcp_tw_recycle 参数！在现代云环境或 NAT 网关网络下，该参数会导致来自同一 NAT 公网 IP 的多个客户端由于时间戳乱序而遭到静默丢包，引发灾难性事故。

五、验证效果与总结

完成代码修复并在内核层面放宽端口范围、开启 tcp_tw_reuse 后，在同样峰值并发流量压测下，再次采集连接指标：

ss -s

输出显示：

• TIME_WAIT 连接数量稳定控制在 3000 以内，且新连接能够安全复用端口；
• CLOSE_WAIT 数量归零，应用未再发生句柄泄露；
• 网关不再出现端口耗尽或文件句柄溢出报错，服务请求成功率恢复至 99.99%。

在 Linux 生产排障过程中，理清协议状态机是定位网络故障的前提，合理结合代码级连接池管理与内核参数微调，方能实现系统的高可用与高吞吐。