大量 TIME_WAIT 问题的故障排查与技术总结

1. 故障分析

2025年6月，公司某微服务集群中的一个 HTTP 服务突然出现大量连接失败，业务方反馈接口偶发超时、部分请求直接报错。运维团队通过监控发现该服务节点的端口资源接近耗尽，日志中频繁出现如下报错：

java.net.BindException: Address already in use: connect

进一步排查，发现该服务为高并发短连接场景（未启用 HTTP Keep-Alive），每秒新建和关闭大量 TCP 连接。通过 ss -ano | grep TIME-WAIT | wc -l 统计，TIME_WAIT 状态的连接数高达两万余个，远超正常水平。由于本地端口被 TIME_WAIT 占用，新建连接频繁失败，导致业务中断。

2. TIME_WAIT 状态介绍

TIME_WAIT 是 TCP 四次挥手关闭连接过程中，主动关闭方进入的一个重要状态。其作用主要有：

确保对端收到最后的 ACK，防止旧连接数据包影响新连接（TIME_WAIT 状态下，主动关闭方会等待一段时间，确保对方已收到自己发出的最后一个 ACK 报文。如果立即释放端口，可能导致后续同端口下新连接收到前一个连接遗留的延迟数据包，造成数据错乱或安全隐患）
默认持续 2*MSL（Maximum Segment Lifetime，报文最大生存时间），一般为 2 分钟
在此期间，端口无法被复用，导致本地可用端口数减少

当短时间内频繁建立和关闭连接时，TIME_WAIT 数量激增，极易耗尽本地端口资源，影响新连接的建立。

3. 故障重现

假设有两台主机：Server（服务端）和 Client（客户端）。下面详细介绍如何在 Server 上快速搭建一个简单的 HTTP 服务，并在 Client 上模拟大量短连接请求，重现 TIME_WAIT 激增的现象。

3.1 Server 端搭建 HTTP 服务

可以使用 Python 的内置 HTTP 服务器快速启动一个简单的服务。在 Server 节点启动 HTTP 服务（监听 8080 端口）：

python3 -m http.server 8080

该命令会在当前目录下启动一个简单的 HTTP 文件服务，适合用于测试短连接场景。

3.2 Client 端模拟大量短连接

使用 ab 工具发起大量短连接请求（默认每次请求新建连接）：

ab -n 100000 -c 100 http://<Server-IP>:8080/

其中-n指定总请求数，-c指定并发数。可以根据实际情况调整这两个参数。

在 Server 节点观察 TIME_WAIT 数量：

netstat -an | grep TIME_WAIT | wc -l

3.3 现象观察

在压测过程中，Server 端 TIME_WAIT 状态的连接数会迅速增加。
持续压测后，出现新连接失败、端口耗尽等问题。

通过上述步骤，可以在受控环境下稳定复现大量 TIME_WAIT 的问题，为后续参数优化和方案验证提供基础。

4. 故障解决

针对大量 TIME_WAIT 问题，可以从以下几个方面优化：

（1）内核参数调整

服务端扩大本地端口范围：

sysctl -w net.ipv4.ip_local_port_range="1024 65000"

服务端缩短 TIME_WAIT 持续时间（默认60）：
```
sysctl -w net.ipv4.tcp_fin_timeout=30
```
增加文件描述符限制，避免 FD 耗尽

关于 net.ipv4.tcp_tw_reuse 参数：

该参数允许处于 TIME_WAIT 状态的 socket 被新连接复用。根据 Linux 官方文档： “Permits sockets in the ‘time-wait’ state to be reused for new connections. In high traffic environments, sockets are created and destroyed at very high rates. This parameter, when set, allows ‘no longer needed’ and ‘about to be destroyed’ sockets to be used for new connections. When enabled, this parameter can bypass the allocation and initialization overhead normally associated with socket creation saving CPU cycles, system load and time”

简单来说，开启后可以在高并发短连接场景下（无论客户端还是服务端，只要本机产生大量 TIME_WAIT），提升端口利用率，减少 TIME_WAIT 导致的端口耗尽和系统负载。

在本案例中，Server 端作为主动关闭连接的一方，也会产生大量 TIME_WAIT连接。开启该参数后，Server 端本地的 TIME_WAIT 端口可以更快被复用，有助于缓解端口耗尽问题，但无法彻底消除 TIME_WAIT 的影响。

注意：

该参数对“监听端口”无效，只对本地临时端口（主动发起连接或主动关闭连接时产生的 TIME_WAIT）有效。

在高并发短连接的服务端（如本案例），开启 tcp_tw_reuse 可以一定程度上缓解端口耗尽，但根本解决还需配合应用层优化（如 Keep-Alive、连接池）和架构调整。

（2）应用层优化

启用 HTTP Keep-Alive，减少短连接创建
数据库访问使用连接池，避免频繁新建连接
优化爬虫、批量任务等高频短连接场景

（3）架构层面

对于极端高并发短连接业务，建议从协议层或架构层重构，减少短连接产生

5. 总结

TIME_WAIT 是 TCP 协议为保证连接可靠性而设计的机制，但在高并发短连接场景下，容易引发端口耗尽、连接失败等问题。排查时应关注日志、端口状态、FD 使用率等指标。解决方案应结合内核参数优化与应用层设计，根本上减少短连接的产生。对于极端场景，建议从业务架构和协议层面进行优化，而非单纯依赖系统参数调整。

TOC