在 TCP 连接中，主动关闭的一方会在最终确认后进入 TIME_WAIT 状态，并等待 2 个最大报文段生存时间。集群内部如果大量使用短连接访问缓存、数据库和下游 HTTP 服务，主动关闭产生的 TIME_WAIT 会快速占满本地端口资源，最终表现为新连接失败。理解这一状态的设计目标，再结合内核参数和应用层连接复用，才能避免盲目调参带来的副作用。
一、TIME_WAIT 的产生与集群场景下的真实影响
TIME_WAIT 是 TCP 连接正常关闭过程中的最后一个状态。当主动关闭方发送 FIN 报文后，会收到对端的 ACK 和 FIN，随后再次发送 ACK 确认。此时主动关闭方并不会立即销毁套接字，而是进入 TIME_WAIT，等待 2MSL 时间。这样设计主要有两个目的：一是确保最后一个 ACK 能够到达对端，如果对端没有收到，可以在超时后重传 FIN；二是让旧连接中可能迟到的报文在网络中自然消亡，避免干扰使用相同源 IP、源端口、目的 IP、目的端口的新连接。
在集群环境中，服务节点经常扮演主动连接的角色。例如应用服务器主动连接 Redis 缓存、MySQL 数据库，或者前端代理主动连接后端 HTTP 服务。如果这些连接采用短连接模式，每次请求结束都由客户端主动关闭，那么每完成一次请求，客户端节点就会留下一个 TIME_WAIT 套接字。对于 16 位端口空间来说，理论上最多只有 65535 个本地端口可用，再扣除系统保留端口和已经处于监听状态的端口，实际能用于出站连接的数量会更少。当 TIME_WAIT 数量达到几千甚至几万时，新建连接就可能报 Cannot assign requested address 错误。
值得注意的是，TIME_WAIT 本身不是故障，它是 TCP 协议为了保证可靠性而存在的机制。问题核心在于集群内短连接过于频繁，导致端口资源被大量处于等待状态的套接字占用。因此优化方向并不是简单删除 TIME_WAIT，而是从参数、连接复用两个层面降低 TIME_WAIT 的堆积速度和影响范围。
二、内核 TCP 参数优化与作用边界
Linux 提供了多个与 TIME_WAIT 相关的内核参数，但并非所有参数都适合直接开启。最常被提到的两个参数是 net.ipv4.tcp_tw_reuse 和 net.ipv4.tcp_tw_recycle。其中 tcp_tw_reuse 允许将 TIME_WAIT 状态的套接字用于新的出站连接，但它必须依赖 TCP 时间戳选项。开启 net.ipv4.tcp_timestamps 后，内核可以通过时间戳判断旧报文是否已经过期，从而安全地复用端口。这个参数对客户端主动发起连接比较有效，连接建立后端口号可以被新的出站连接使用，但不会缩短已有 TIME_WAIT 的持续时间。
net.ipv4.tcp_tw_recycle 曾经被用来快速回收 TIME_WAIT 套接字，但在高版本内核中已经被移除。原因是它要求所有连接都开启时间戳，并且会依据时间戳快速回收连接，这在 NAT 环境下会导致大量包被丢弃。因为 NAT 后多个客户端共享同一个公网 IP，不同客户端的时间戳并不同步，服务端开启 tcp_tw_recycle 后可能误判旧报文，造成连接建立失败。因此集群节点如果位于 NAT 网关后面，或者负载均衡做了源地址转换，都不应该再使用该参数。
真正值得调整的参数组合如下：
# 允许将 TIME_WAIT 套接字复用于新的出站连接 net.ipv4.tcp_tw_reuse = 1 # 开启 TCP 时间戳，tcp_tw_reuse 依赖该选项 net.ipv4.tcp_timestamps = 1 # 扩大本地出站端口范围，增加可用端口池 net.ipv4.ip_local_port_range = 10000 65535 # 增大 TIME_WAIT 桶上限，避免到达阈值后直接销毁套接字 net.ipv4.tcp_max_tw_buckets = 200000
其中 tcp_max_tw_buckets 是系统允许的最大 TIME_WAIT 数量，超过这个数量后新产生的 TIME_WAIT 会被直接销毁并记录日志。适当调大这个值可以避免在高并发时出现警告，但它只是兜底手段，不能解决根本问题。另一个参数 tcp_fin_timeout 控制的是 FIN_WAIT_2 状态下等待对端 FIN 的超时时间，它并不直接控制 TIME_WAIT 的持续时间，因此缩短该值对 TIME_WAIT 数量没有明显帮助。
在四层负载均衡或代理节点上，如果代理主动关闭到后端的连接，同样会产生 TIME_WAIT。因此这些节点也需要开启 tcp_tw_reuse，并保持时间戳开启。对于纯转发场景，如果使用了 IPVS 或 HAProxy，还需要关注转发模式是否会保留源地址，透明代理模式下源端口使用更容易受到 TIME_WAIT 影响。
三、应用层连接复用是减少 TIME_WAIT 的根本方法
内核参数只能在端口耗尽前多争取一些空间，更有效的思路是减少短连接的数量。对于 HTTP 服务来说，客户端到负载均衡器、负载均衡器到后端服务之间都应当尽量使用持久连接。Nginx 作为反向代理时，默认到后端使用的是 HTTP/1.0，并且会发送 Connection: close，这会导致每次请求都重新建立 TCP 连接，后端节点因此频繁出现 TIME_WAIT。配置 upstream 中的 keepalive 可以让 Nginx 与后端之间复用空闲连接。
upstream backend {
server 10.0.0.10:8080;
server 10.0.0.11:8080;
keepalive 128;
}
server {
listen 80;
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
这段配置中 proxy_http_version 1.1 启用了 HTTP/1.1 的持久连接语义，proxy_set_header Connection "" 将上游请求中的 Connection 头清空，避免客户端要求关闭连接。启用 keepalive 后，Nginx 会在空闲连接池中保留一定数量的后端连接，后续请求直接复用，不再频繁握手和挥手，TIME_WAIT 数量会显著下降。
对于 Redis、MySQL、消息队列等非 HTTP 组件，应优先使用连接池。连接池中的长连接可以持续复用，只有空闲超时、连接失效或应用发布时才会关闭连接，TIME_WAIT 的产生频率从每请求一次降低到分钟级甚至更低。各种语言都有成熟的连接池实现，例如 Java 的 HikariCP、Go 的 database/sql 连接池、Redis 客户端的通用连接池等。连接池配置中需要关注空闲连接检测和最大存活时间，避免因服务端主动断开而持有半开连接。
集群内部通信也可以采用多路复用协议。gRPC 基于 HTTP/2 可以在一条 TCP 连接上并发传输多个请求，Dubbo 等 RPC 框架也支持单一长连接多路复用。这样不仅能减少 TIME_WAIT，还能降低握手延迟和文件描述符占用。对于已有的短连接系统，可以先从调用最频繁的下游依赖开始改造，逐步替换为连接池或长连接模式。
四、验证配置与持续监控
修改内核参数和应用配置后，需要通过命令确认当前系统的 TIME_WAIT 数量和端口使用情况。使用 ss 可以快速查看状态分布，下面的命令可以统计 TIME_WAIT 连接总数和不同端口的连接数分布。
ss -tan state time-wait | wc -l
ss -tan state established | awk '{print $4}' | cut -d: -f2 | sort | uniq -c | sort -rn | head
第二行命令用于查看已建立连接中本地端口的分布情况，可以帮助判断连接是否集中在少数源端口。若 TIME_WAIT 数量在压测期间快速上升并导致端口耗尽，应检查出站连接是否仍为短连接。仅开启 tcp_tw_reuse 而不做连接复用，通常只能延缓问题发生，无法完全消除风险。
在集群规模较大时，建议将 TIME_WAIT 数量纳入监控指标。可以通过 Prometheus 的 node_exporter 采集 node_sockstat_TCP_tw 指标，观察每个节点上 TIME_WAIT 的变化趋势。如果某个节点在业务高峰期出现 TIME_WAIT 持续增长且接近本地端口上限，说明该节点的短连接流量仍然过高，需要进一步排查调用链路。实践中还可以结合应用层的连接池命中率、后端连接复用率等指标，判断优化是否真正生效。
总体来看，集群 TCP 参数优化和 TIME_WAIT 复用需要分层处理。内核层开启 tcp_tw_reuse 和 tcp_timestamps，扩大 ip_local_port_range，是保证端口资源充足的基础；应用层通过 HTTP keep-alive、连接池和多路复用降低连接创建频率，是减少 TIME_WAIT 的根本手段。同时要避免使用已经被废弃且对 NAT 不友好的 tcp_tw_recycle。只有把内核参数和应用架构结合起来，才能在高并发集群中保持 TCP 连接稳定。