在 Linux 网络排障和运维面试中，TCP 连接状态几乎是必考内容。其中 TIME_WAIT 和 CLOSE_WAIT 出现频率最高，也最容易暴露候选人是否真正理解 TCP 状态机、内核参数和应用层代码问题。
这篇文章从面试回答的角度出发，先讲清楚两种状态为什么会存在，再讲“过多”时如何一步步排查，最后给出可落地的处理思路。
一、先理解 TCP 四次挥手和状态归属
要回答这个问题，必须先把连接关闭过程说清楚。TCP 建立连接是三次握手，关闭连接通常是四次挥手：
- 主动关闭方发送
FIN，进入 FIN_WAIT_1。 - 被动关闭方收到
FIN，回复ACK，进入 CLOSE_WAIT。 - 被动关闭方应用层处理完数据后，发送自己的
FIN，进入 LAST_ACK。 - 主动关闭方收到
FIN，回复ACK，进入 TIME_WAIT。 - 被动关闭方收到
ACK，连接关闭。
因此可以记住两个关键结论：
- CLOSE_WAIT 出现在被动关闭方，表示对方已经关闭连接，本端还没有调用
close()。 - TIME_WAIT 出现在主动关闭方，表示本端已经发送并确认了最后的
ACK，正在等待 2MSL 后彻底释放。
面试时如果只背“TIME_WAIT 是主动关闭方，CLOSE_WAIT 是被动关闭方”，只能算及格；能进一步说明它们分别代表“内核正常回收过程”和“应用层未及时关闭”，才是加分项。
二、TIME_WAIT 过多：多数情况下是正常现象
1. TIME_WAIT 为什么必须存在
TIME_WAIT 不是为了“拖时间”，它有两个核心作用：
- 保证最后一个 ACK 能到达对端。如果这个 ACK 丢失，对端会重传 FIN，此时本端仍处于 TIME_WAIT，可以再次回复 ACK。
- 让旧连接的延迟报文在网络中消散。避免相同四元组的新连接收到旧连接残留数据。
所以看到 TIME_WAIT 不要立刻认为系统有问题。高并发短连接服务，比如 HTTP 短连接、爬虫、压测客户端，出现大量 TIME_WAIT 是正常现象。
2. 什么情况算“过多”
通常结合以下指标判断：
ss -s或netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'中 TIME_WAIT 数量持续很高。- 客户端端口耗尽，出现
Cannot assign requested address。 - 新建连接失败率上升，但 CPU、内存并不高。
- 同一四元组复用频繁，偶发连接异常。
3. 排查思路
第一步，确认 TIME_WAIT 集中在哪一侧：
ss -ant | awk '{print $1}' | sort | uniq -c
ss -ant state time-wait | head
如果本机是客户端，TIME_WAIT 多通常说明本机在主动关闭大量短连接。
第二步，看连接分布：
ss -ant state time-wait | awk '{print $4}' | awk -F: '{print $1}' | sort | uniq -c
ss -ant state time-wait | awk '{print $5}' | awk -F: '{print $1}' | sort | uniq -c
确认是连往同一批后端，还是本地端口大量分散。
第三步，检查内核参数：
sysctl net.ipv4.tcp_tw_reuse
sysctl net.ipv4.tcp_max_tw_buckets
sysctl net.ipv4.ip_local_port_range
4. 处理方式
- 优先改应用架构：使用长连接、连接池，减少短连接频率，这是最根本的办法。
- 开启
tcp_tw_reuse=1：允许将 TIME_WAIT 连接复用于新的出站连接，但只对客户端有效，且需要时间戳支持。 - 不要轻易开启
tcp_tw_recycle：在 NAT 环境下会导致连接异常，现代内核已移除或不推荐。 - 扩大本地端口范围：
net.ipv4.ip_local_port_range = 10000 65000。 - 适当调整
tcp_max_tw_buckets：但这是限制上限，不是越多越好，超过后内核会直接销毁并打印警告。
面试回答时要注意：TIME_WAIT 过多通常优化应用连接模型，而不是一味改内核参数。
三、CLOSE_WAIT 过多：几乎都是应用层问题
1. CLOSE_WAIT 的本质
CLOSE_WAIT 表示：对端已经发送 FIN，本端内核回复了 ACK，但本端应用程序还没有调用 close() 关闭 socket。
也就是说，连接已经交到应用层手里，但应用层没有释放。它不会自动消失，除非进程退出或代码显式关闭。
2. 常见原因
- 代码中忘记关闭连接，比如异常分支没有
finally close()。 - 连接池配置不合理，借出后未归还。
- 阻塞在读写、数据库查询、下游调用，导致无法走到关闭逻辑。
- 线程池耗尽，处理连接的线程被占满，新 FIN 无人处理。
- 使用了 HTTP 客户端但未正确释放 response body。
3. 排查步骤
第一步，统计 CLOSE_WAIT 数量：
ss -ant state close-wait | wc -l
ss -ant state close-wait
第二步，定位进程：
ss -antp state close-wait
如果 ss 没有 -p 权限，用 lsof -iTCP -sTCP:CLOSE-WAIT 或 netstat -antp | grep CLOSE_WAIT。
第三步，确认对端和本地端口：
ss -antp state close-wait | awk '{print $4, $5, $6}'
如果大量连接来自同一批客户端或负载均衡，说明这些客户端已经关闭，但本服务没有释放。
第四步，检查应用日志和线程栈：
jstack <pid> > /tmp/stack.txt
grep -n "SocketRead\|SocketWrite\|close" /tmp/stack.txt
重点看是否有大量线程阻塞在读取下游、等待锁或数据库连接。
第五步，检查文件描述符：
ls /proc/<pid>/fd | wc -l
cat /proc/<pid>/limits | grep "open files"
CLOSE_WAIT 持续增长往往会伴随 fd 泄漏。
4. 处理方式
- 修复代码：确保所有异常路径都能关闭连接，使用 try-with-resources 或 defer close。
- 检查连接池：设置合理的最大连接数、空闲超时、借出超时。
- 增加超时：对下游调用、数据库查询设置 connect timeout 和 read timeout，避免线程永久阻塞。
- 重启服务只是止血：重启可以释放 CLOSE_WAIT，但根因仍在代码或连接池配置。
- 必要时调低
tcp_fin_timeout对 CLOSE_WAIT 无效：这个参数主要影响 FIN_WAIT_2 等状态，不要误答。
面试中如果被追问“CLOSE_WAIT 能不能通过内核参数解决”，正确回答是：基本不能，CLOSE_WAIT 是应用层没有 close，内核参数解决不了，必须查应用代码和连接池。
四、面试回答模板
如果面试官问：“TIME_WAIT 和 CLOSE_WAIT 过多怎么排查？”
可以这样组织回答：
- 先解释状态归属：TIME_WAIT 在主动关闭方，CLOSE_WAIT 在被动关闭方。
- 再判断是否真的异常：TIME_WAIT 高并发短连接下常见，CLOSE_WAIT 持续增长通常异常。
- 排查命令：
ss -ant、ss -s、ss -antp、lsof、/proc/<pid>/fd。 - 分因处理：TIME_WAIT 优先连接池、长连接、
tcp_tw_reuse；CLOSE_WAIT 优先查代码 close、连接池、线程阻塞和超时。 - 最后强调：TIME_WAIT 多数是协议正常行为，CLOSE_WAIT 多数是应用缺陷。
五、总结
TIME_WAIT 和 CLOSE_WAIT 是 TCP 状态机里的正常状态，但“过多”时含义完全不同。
- TIME_WAIT 过多：先看是不是短连接高并发，优先用连接池和长连接优化，谨慎调整内核参数。
- CLOSE_WAIT 过多：几乎可以断定是应用没有关闭连接，重点查代码、连接池、线程阻塞和 fd 泄漏。
能把状态归属、排查命令、根因方向和处理手段讲清楚，这道 Linux 面试题基本就能拿到高分。
未经允许不得转载：任鹏个人博客 » Linux 面试中如何解释 TIME_WAIT、CLOSE_WAIT 过多如何排查
