高进阶

TIME_WAIT状态#

一句话答案#

主动关闭方进入 TIME_WAIT 等 2MSL，确保最后 ACK 到达且旧报文消亡；高并发短连接时大量 TIME_WAIT 需优化。

核心要点

TIME_WAIT：

发生在主动关闭方（通常是客户端），发出第4次 ACK 后进入
等待时间：2MSL（Maximum Segment Lifetime，报文最大存活时间）。RFC 9293 取 MSL=2 分钟；Linux 的 TIME_WAIT 时长由内核宏 TCP_TIMEWAIT_LEN 写死为 60s（相当于 MSL=30s），没有 sysctl 能改

为什么要等 2MSL：

保证最后一个 ACK 能到达对方：若 ACK 丢失，服务端会重发 FIN；2MSL 内可以重新响应
让网络中残留的旧报文消失：防止旧连接的延迟报文被新连接误接收

TIME_WAIT 过多的问题：

每个 TIME_WAIT 占用一个四元组：主动发起连接的一方（客户端、或调用下游的网关/代理）连同一个目标 IP:端口时，本地端口会被占满，新 connect() 失败；服务端监听端口上的 TIME_WAIT 不消耗本地端口，主要占内存
高并发短连接场景（如 HTTP/1.0）容易出现

解决：

# Linux 内核参数
net.ipv4.tcp_tw_reuse = 1   # 默认 2（只对回环地址开启）；1 = 全局开启。只作用于主动 connect() 的出向连接，依赖 TCP 时间戳（tcp_timestamps=1），TIME_WAIT 超过 tcp_tw_reuse_delay（默认 1000ms，6.x 新增的 sysctl）后才能复用
net.ipv4.tcp_fin_timeout = 30  # 缩短孤儿连接在 FIN_WAIT_2 的等待时间（默认 60s），不影响 TIME_WAIT 的 60s
net.ipv4.tcp_max_tw_buckets = N  # TIME_WAIT 数量上限，超过后直接销毁并打日志
# net.ipv4.tcp_tw_recycle 已在 Linux 4.12 删除，不要再配

bash

CLOSE_WAIT：

发生在被动关闭方（服务端），收到对方 FIN 后发出 ACK，等待本地应用程序关闭连接

出现大量 CLOSE_WAIT 的根本原因：

服务端代码没有调用 socket.close()，即连接没有被正确关闭

常见代码原因：

// 错误：没有在 finally 中关闭连接
try {
    InputStream in = socket.getInputStream();
    // 处理数据
} catch (Exception e) {
    log.error(e);
    // ❌ 没有 close！
}

// 正确：
try (Socket socket = ...) {  // try-with-resources 自动关闭
    ...
}

java

排查方法：

netstat -an | grep CLOSE_WAIT | wc -l   # 统计 CLOSE_WAIT 数量
# 大量 CLOSE_WAIT → 检查服务端代码是否有资源未关闭（连接池泄漏）

bash

面试回答（2分钟版）

TIME_WAIT 是 TCP 四次挥手中主动关闭方在发出最后一个 ACK 后进入的状态，需要等待 2 个 MSL 时间，Linux 上大约 60 秒。等待 2MSL 有两个目的：一是确保最后一个 ACK 能被对方收到，如果 ACK 丢失对方会重发 FIN，在 2MSL 内主动关闭方还能重新响应；二是让网络中属于旧连接的残留报文自然消亡，避免被新建的相同四元组连接误接收。TIME_WAIT 本身是正常状态，但在高并发短连接场景下会产生大量 TIME_WAIT，每个都占用一个四元组导致可用端口耗尽。优化手段包括开启 tcp_tw_reuse 允许新连接复用 TIME_WAIT 状态的 socket，或者从根本上使用长连接减少连接创建销毁次数。注意 tcp_tw_recycle 在 NAT 环境下会导致连接异常，已在 Linux 4.12 删除。另外还要区分 CLOSE_WAIT，它出现在被动关闭方，如果服务端出现大量 CLOSE_WAIT 通常是代码没有正确调用 close 关闭连接导致的资源泄漏。

追问与易错

追问方向：

“TIME_WAIT 过多怎么优化？”→ 开启 tcp_tw_reuse 复用 TIME_WAIT 连接 + 使用长连接/连接池减少建连次数 + 让服务端主动关闭改为客户端关闭
“2MSL 具体是多久？”→ MSL 是报文最大存活时间，RFC 9293 取 MSL=2 分钟（2MSL=4 分钟）；Linux 的 TIME_WAIT 固定 60s（TCP_TIMEWAIT_LEN 宏写死，不能通过 sysctl 调），实际实现各不同
“tcp_tw_reuse 安全吗？”→ 相对安全：只对主动发起的出向连接生效，依赖 TCP 时间戳和 PAWS 丢弃旧连接的延迟报文，且 TIME_WAIT 至少持续 tcp_tw_reuse_delay（默认 1s）才复用；tcp_tw_recycle 不安全，NAT 后多台机器时间戳不一致会误丢正常 SYN，已在 Linux 4.12 删除

易错点：

❌ TIME_WAIT 是异常状态——是正常的 TCP 关闭流程
❌ 直接设 tcp_tw_recycle——在 NAT 环境会导致连接异常，且 Linux 4.12 起这个参数已不存在
❌ 调小 tcp_fin_timeout 能缩短 TIME_WAIT——它只管 FIN_WAIT_2，Linux 的 TIME_WAIT 固定 60s
❌ 服务端开 tcp_tw_reuse 能减少自己的 TIME_WAIT——它只影响本机主动 connect() 的出向连接