TCP半关闭与四次挥手：CLOSE_WAIT和TIME_WAIT的优雅关闭实战-代码聚汇网

TCP半关闭与四次挥手：CLOSE_WAIT和TIME_WAIT的优雅关闭实战

随缘惜情·2026-09-05·阅读 21 GEO检测（免费）

TCP半关闭四次挥手

|难度：普通|阅读约 23 分钟

1. 从一次线上故障说起：为什么“关闭一个连接”这么难

大概半年前，我们线上有个网关服务半夜报警，文件描述符（file descriptor）直接被打满，新的连接根本进不来。当时第一反应是“连接泄漏”，赶紧上 ss -s 看了一眼，结果发现大量连接卡在 CLOSE_WAIT 状态，数量稳定在七千多，远超正常水位。

排除了代码里没关连接的低级问题之后，我盯着抓包文件里的 FIN 报文序列，才意识到问题出在“被动关闭方对半关闭状态的处理”上——对端发了 FIN，但我们的服务内核已经回了 ACK，应用层却迟迟没有调用 close，这条 TCP 连接就一直挂在半开半闭的状态，既不收数据也不发数据，像一扇没锁严的窗户，风一吹就吱呀作响，雨一飘就满屋是水。

这个场景，其实就是 TCP 半关闭（half-close）最经典的形态之一。所以想借这篇内容，把 TCP 连接“结束生命周期”这件事拆开来讲清楚：四次挥手为什么是四次、半关闭状态到底有什么用、CLOSE_WAIT 和 TIME_WAIT 哪个更可怕、以及我们在真实业务里怎么设计一套“优雅关闭”的机制。适合正在写网络服务的后端开发、中间件维护者，还有准备 TCP 面试题的同学们。

如果你对 TCP 的认知还停留在“三次握手建立连接、四次挥手断开连接”这个口诀，那这篇内容会帮你把口诀背后的原理和实战里的坑一次性补齐。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 四次挥手的底层拆解：谁的 FIN 先发、ACK 怎么凑、半关闭状态藏在哪一步

2.1 为什么必须是四次：全双工的对称关闭逻辑

TCP 是全双工协议，意思是数据在两个方向上独立传输，A 给 B 发数据的同时，B 也能给 A 发数据。正因为两个方向的数据流是独立的，关闭的时候也必须“各自为政”——每个方向都要单独关一次。

于是就有了四次挥手：

主动关闭方（假设是 A）发送 FIN，表示“我这边的数据发完了，我不再往这个方向发数据了”；
被动关闭方（B）收到 FIN 后回 ACK，表示“我收到了你关闭的请求”；
B 在合适的时间发送自己的 FIN，表示“我这边数据也发完了，我也要关了”；
A 回 ACK，确认 B 的关闭请求，连接彻底释放。

很多人问：为什么不是三次？把第 2 步和第 3 步合并成一次 ACK+FIN 不就好了？答案是不行，因为第 2 步和第 3 步之间，B 可能还要继续发数据。

举个例子：A 发送完请求后说“我不发了”，但 B 可能还要做长时间计算，算完再给 A 回一个大响应。在这个计算期间，B 必须先回 ACK 安抚 A：“你的 FIN 我收到了，但我还在工作，先别急着销毁连接。”如果 B 把 ACK 和 FIN 合并成一步提前发出去，A 就会以为 B 也彻底关闭了，这就不符合 TCP 全双工的语义。

所以四次挥手不是形式主义，而是一方“单方面关闭发送方向”这一行为在协议层面上的必然结果。这个“单方面关闭”，就是半关闭。

2.2 FIN 的语义：它不是“断开”，而是“我不再发送”

理清 FIN 的语义非常重要。FIN 的全称是 finish，但它的准确含义是“我这个方向的数据流结束了”，而不是“连接立刻没有了”。

我们再看一下标准状态转移：

主动关闭方 A 发出 FIN 后，进入 FIN_WAIT_1；
收到 B 的 ACK 后进入 FIN_WAIT_2，此时 A 不再发数据，但仍然可以读数据；
B 收到 FIN 并回了 ACK 后进入 CLOSE_WAIT，此时 B 知道自己不再有新数据可读了，但仍然可以写数据；
B 完成所有数据发送后，发出自己的 FIN，进入 LAST_ACK；
A 收到 FIN 后回 ACK，进入 TIME_WAIT，等待 2MSL 后彻底关闭；
B 收到 ACK 后进入 CLOSED。

这里最容易忽略的就是 FIN_WAIT_2 和 CLOSE_WAIT 这组“等待”状态。在 A 发出 FIN 且收到 ACK 后，到 B 发出 FIN 之前的这段时间，就是半关闭窗口期。在这个窗口期里，A 不能发数据，但 B 可以。这正好覆盖了“请求-处理-响应”这种经典模式里，客户端不再发数据、但服务端还需要时间回数据的场景。

2.3 半关闭状态与“三次握手断开”的误区

有一个常见误区是，很多人以为可以“三次挥手”。确实有 TCP 实现允许把 FIN 和 ACK 合并在同一个报文里，比如双方同时都不再有数据要发时，B 可以直接回 ACK+FIN，这样抓包看起来只有三次报文交互。但这种场景是巧合而不是常态——只有当被动关闭方恰好也无需再发送数据时，合并才是合法的。业务流里如果强制要求“三次就断”，多半是通过 SO_LINGER 配合 RST 实现的，那就是强制重置连接，而不是优雅关闭了，后面会细讲。

所以准确的说法是：优雅关闭一定基于半关闭的能力，而半关闭意味着关闭动作天然拆成两个独立步骤，因此标准实现就是四次挥手。

3. 半关闭状态的真实价值：从 shutdown 与 close 的区别说起

3.1 一份服务器代码引发的思考：为什么我不能直接 close

有一次同事写了一个简单的 echo 服务，处理完请求后直接调 close() 关闭 socket。功能上没毛病，但有一个隐患：如果客户端发完数据后立刻调 close，而服务端还在往 socket 里写最后一批数据，可能就会收到 EPIPE 或 SIGPIPE，甚至导致响应数据被丢弃。

核心原因就是 close() 干的事情太“一刀切”了。close() 把 socket 的引用计数减一，只有引用计数归零时才真正关闭连接。一旦关闭，收发两个方向同时禁止。这在某些场景下不是我们想要的——比如客户端已经告诉服务端“我不再发数据了”，但服务端还有几兆数据要回给客户端，这时候客户端如果直接 close，那服务端就再也没机会把数据发出去了。

而 shutdown() 不一样。它允许你只关闭发送方向，保留接收方向，或者反过来。这正是半关闭状态的编程接口。

3.2 shutdown 参数的具体语义与使用姿势

以 Linux 下的 socket API 为例：

shutdown(sock, SHUT_RD)：关闭读方向，后续 recv 返回 0，表示读到 EOF；
shutdown(sock, SHUT_WR)：关闭写方向，后续 send 返回错误，同时内核会给对端发送 FIN；
shutdown(sock, SHUT_RDWR)：读写都关，效果上接近 close，但不会释放 fd，且不会影响其他引用同一 socket 的进程或线程。

最经典的用法是客户端在发送完请求后，调用 shutdown(sock, SHUT_WR)，此时服务端 recv 会读到 EOF（返回 0），服务端就知道“客户端数据发完了，我处理完就可以回响应了”。而客户端虽然不再写，却还能继续 recv 服务端的响应。这叫“客户端主动进入半关闭状态”。

服务端在处理完数据、写完响应之后，再调 close() 完成整个关闭流程。这样就避免了客户端提前 close 导致服务端写失败的问题。

Python 的 socket 里对 shutdown 的封装和 C 语言基本一致，Java 的 Socket 类也提供了 shutdownOutput() 和 shutdownInput() 两个方法，分别是禁用输出流和输入流。Netty 里虽然没有特别常用 shutdown，但 Channel.close() 的宽容度也远不如协议层面的半关闭语义。

3.3 实战范例：用半关闭实现一个可靠的“请求-响应”客户端

我们用一个 Python 的最小例子演示半关闭的核心价值。

python复制import socket

def send_request_and_read_all_response(host, port, request_data):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(10)
    try:
        sock.connect((host, port))
        sock.sendall(request_data)
        # 关键：告诉服务端，我不再发送数据了，但还可以接收
        sock.shutdown(socket.SHUT_WR)

        chunks = []
        while True:
            data = sock.recv(4096)
            if not data:
                break
            chunks.append(data)
        return b"".join(chunks)
    finally:
        sock.close()

这段代码里，shutdown(socket.SHUT_WR) 做了两件事：本地不再允许 send，同时给服务端发出 FIN。服务端在 recv 时发现 EOF，就知道请求边界到了，可以放心地开始拼接响应再返回。如果不用 shutdown，服务端就必须依靠长度字段、分隔符或者超时来判断“客户端数据发完了没”，处理起来麻烦得多。

很多基于 HTTP/1.0 的旧服务端，就是靠着“客户端断开连接”来判断请求结束的，这里断开连接的本质，其实是半关闭的 FIN。

3.4 FIN 与 RST：优雅关闭和强制关闭的分岔路

讨论半关闭时，必须提到 FIN 和 RST 的对比。FIN 是“我发完了，等你的数据”，RST 是“我不玩了，直接销毁链路”。

如果你在 socket 上设置了 SO_LINGER 且 l_linger = 0，然后调 close，内核会直接发送 RST 而不是 FIN。这样做的好处是快速释放资源，代价是对端可能还没读完缓冲区里已有的数据，导致数据丢失。实际业务里，只有当确认对端不需要剩余数据时才建议这么做，比如检测到对方已经崩溃或协议已发生不可恢复的错误。

更麻烦的是，RST 的到达会让对端丢弃接收缓冲区里尚未读取的数据，对端应用层读到的就是 “Connection reset by peer”——这是生产环境最常见的报错之一，往往就是某端代码里对“数据没读完”这件事毫不知情，直接强关了连接。

4. CLOSE_WAIT 和 TIME_WAIT：线上系统最磨人的两个状态

4.1 状态堆积的危害差异：一个杀进程，一个占端口

线上排查时，一看到大量 CLOSE_WAIT 心里就该拉响警报。CLOSE_WAIT 出现在被动关闭方，也就是收到对端 FIN 并回了 ACK，但应用层迟迟没有调用 close() 的一方。这个状态每停留一秒，就意味着有一个文件描述符被占用、一个线程可能卡在业务逻辑里。量一旦上来，最先崩溃的是文件描述符资源，再往上就是无法 accept 新连接，整个服务瘫痪。

TIME_WAIT 则出现在主动关闭方。主动关闭方发出 FIN 并收到对端 FIN，回完最后一个 ACK 后进入 TIME_WAIT，等待 2MSL 才释放。它的存在本身是必要的，但量太大会占用本地端口，尤其是客户端短连接场景，一个 IP 一个端口对儿的数量上限是六万多，如果大量连接堆积在 TIME_WAIT，新连接会报 Address already in use。

这里放一个对比表，方便记忆：

维度	CLOSE_WAIT	TIME_WAIT
出现位置	被动关闭方	主动关闭方
形成原因	收到 FIN 后应用层没调 close	发送 FIN 后等待最后一个 ACK 确认
危害	fd 被占满、服务拒新连接	本地端口被占用、连接Cannot assign
常见规模	越积越多且不会自动消失	高并发短连接场景下瞬间爆发
处理思路	找代码漏洞，补 close 或 shutdown	开 reuse + 调小 TIME_WAIT 或避免主动关闭

4.2 一个关于 CLOSE_WAIT 的真实案例：read 返回 0 之后呢

回到开头提到的线上故障。我们把核心服务的代码翻出来，发现处理逻辑是：

code复制while (true) {
    n = read(fd, buf, sizeof(buf));
    if (n <= 0) break;
    process(buf, n);
}
// 业务处理完之后，这里忘掉了 close(fd)

read 返回 0 代表对端已关闭发送方向，也就是半关闭状态已经发生。代码 break 退出循环，业务逻辑处理完异常分支后直接返回，唯独没有调用 close。内核里的连接就永远停在 CLOSE_WAIT，读方向已经 EOF，写方向又没有新数据要发，FD 就这么被白白占住。

要修其实很简单：read 返回 0 之后必须 close(fd) 或者 shutdown(fd, SHUT_RDWR)。但难点在于运维层面怎么尽早发现。建议把 ss -s 的 CLOSE_WAIT 数量接入监控，超过连接总数的 1% 就告警，不要等到 fd 被打满才被动响应。

4.3 TIME_WAIT 存在的必要性与 2MSL 的来历

TIME_WAIT 不是 bug，它是一个精心设计的延迟保险。最后一个 ACK 可能丢失，如果直接释放连接，对端在 LAST_ACK 状态下收不到 ACK，就会重发 FIN。此时如果主动关闭方已经关闭了端口，那对端就会收到 RST，把一次正常关闭变成异常中断。所以设计者要求主动关闭方在发出最后一个 ACK 后，等待 2MSL（MSL 是报文最大存活时间），确保旧报文在网络中彻底消散，同时也给对端足够的重传时间窗。

这是由数据报文在网络中可能滞留的物理现实决定的。对于局域网，MSL 通常是 30 秒或 1 分钟，2MSL 就是 1 到 2 分钟。对于跨地域长肥管道，不建议盲目改短 TIME_WAIT，宁可多保留一会儿，也别让残留报文污染新连接。

4.4 内核参数调优：哪些能调，哪些不建议调

线上被 TIME_WAIT 打满时，大家第一反应是调大临时端口范围，或者开启 reuse。下面几个参数是我实际验证过还算靠谱的：

bash复制# 开启 TIME_WAIT 端口复用，注意这里的行为和 Linux 版本有关
sysctl -w net.ipv4.tcp_tw_reuse=1

# 扩大临时端口范围，从 1024 到 65535
sysctl -w net.ipv4.ip_local_port_range="1024 65535"

# 降低 FIN_WAIT_2 的超时时间，防止半关闭卡死
sysctl -w net.ipv4.tcp_fin_timeout=30

需要提醒的是：tcp_tw_reuse 只对客户端出站连接有效，且要求开启时间戳选项。它解决的是“本地端口不够用”，而不是“TIME_WAIT 状态消失”。服务端 Inbound 连接如果 TIME_WAIT 堆积，靠 reuse 是没用的，更稳妥的方案是让服务端尽量不要成为主动关闭方，或者接受 TIME_WAIT 是短连接服务的正常成本，配合端口范围调优即可。

tcp_tw_recycle 这个参数在很多内核版本里已经被移除，即便可用也不要开，它会因为时间戳机制导致 NAT 后面的机器出现连接被随机重置的问题，坑过很多人。

5. 面向实战的优雅关闭设计：从代码到系统配置的完整链路

5.1 服务端优雅关闭的三个阶段

真正工程化的服务，关闭流程不能只靠内核的默认行为。我一般会把优雅关闭设计成三个阶段：

停止接收新连接：监听 socket 先从 accept 队列摘除，不再 accept 新请求；
处理存量请求：给已有连接一个宽限期，让正在处理的请求正常完成，新请求一律回 503；
等待宽限期结束后强关：超过宽限期的连接，直接 close，或者按业务要求发送 RST。

这个流程在 Nginx、Tomcat、Netty 里都有对应的实现。Netty 的优雅关闭机制比较典型：先调用 bossGroup.shutdownGracefully() 停掉接收新连接的线程池，再调用 workerGroup.shutdownGracefully() 等存量 channel 处理完事件再关闭。核心思想就是“先断入口，再等存量，最后兜底”。

5.2 健康检查与半关闭：为什么 /health 接口要独立

服务发布滚动更新时，如果直接 kill 进程，正在处理请求的连接就断了，客户端会收到 Connection reset by peer。所以我们通常会在容器里挂一个健康检查接口。健康检查探活成功后，再把服务从负载均衡摘掉，然后才进入优雅停服流程。

这里的重点是：健康检查接口不能和业务连接共享同一个关闭逻辑。有些团队把健康检查也塞到业务 handler 里，服务在优雅关闭阶段把所有请求都拒掉，结果负载均衡探活失败，直接把这个节点从集群踢掉，正在处理的存量请求反而没机会完成。

正确做法是把健康检查绑定在独立端口或独立 server 上，停服时先摘流量，再停健康检查，最后再走业务关闭流程。这样整个发布过程对客户端来说是透明的。

5.3 连接池视角：连接被对象池用完归还还是关闭

另一个经常踩坑的地方是数据库连接池或 HTTP 连接池。连接池的核心是把 TCP 连接复用起来，但如果回收逻辑不严谨，很容易出现池子里全是濒死连接，用的时候才发现对方早已悄悄关闭，报错之后才重建连接。

连接池对半关闭的影响体现在：shutdown(SHUT_WR) 会让对端读到 EOF，而连接池一般不会调用 shutdown，它只是把 socket 重新交回池子。为了不让池里的连接“假死”，一般有两种做法：

定期发送应用层心跳，比如 MySQL 连接池的 testOnBorrow 和空闲超时清理；
在 TCP 层启用 keepalive，但要调参，默认的两小时探测间隔太长了。

关于 keepalive，下面这组参数配合连接池生命周期管理，实测下来比较稳：

bash复制# 开启 keepalive
sysctl -w net.ipv4.tcp_keepalive_time=600
# 探测间隔
sysctl -w net.ipv4.tcp_keepalive_intvl=30
# 连续失败次数
sysctl -w net.ipv4.tcp_keepalive_probes=3

需要注意的是，TCP keepalive 只负责探测“对端主机是否宕机或网络是否断开”，它无法告诉应用层“对端应用是否已经关闭连接”。应用层的道理还是得应用层自己来，比如 Redis 的 PING/PONG，MySQL 的 SELECT 1。

5.4 对端崩溃后的半关闭：为什么你的 recv 永远等不到 EOF

写网络程序时，有一个很隐蔽的问题：对端进程崩溃，内核会负责发送 FIN 吗？答案是分情况的。

如果对端是正常 exit 或进程被 kill，操作系统内核会关闭它打开的所有 fd，这时会发送 FIN，你这边 recv 会读到 EOF。如果对端是整台机器宕机、断电，或中间路由器把连接丢掉，那 FIN 就不会出现。此时你的连接仍显示 ESTABLISHED，但已经是一个“死连接”。

怎么发现这种死连接？靠 TCP keepalive，靠应用层心跳，靠读取超时。半关闭状态在这里的真正意义，是让你把“对端发送方向结束”和“对端整体不可用”区分开。很多时候，读方向 EOF 只是对方不再发数据，不代表对方没有能力接收你的数据。这一点在协议设计里经常被误用。

6. 排查链路实录：一次连接关闭异常是怎样一步步定位的

6.1 从“端口耗尽”到抓包验证的完整步骤

分享一次比较典型的排查过程。现象是新连接建不起来，服务端日志报 Resource temporarily unavailable，ss -lnt 看到大量连接处于 CLOSE_WAIT。

第一步是采集现场：

bash复制# 查看系统级连接状态统计
ss -s

# 查看针对某个端口的连接状态计数
ss -lnt | awk '{print $1}' | sort | uniq -c

# 找到 CLOSE_WAIT 连接对应的对端 IP 和端口
ss -tanp | grep CLOSE-WAIT | head -50

第二步是看进程内 fd 情况，确认是不是某个连接池或者某个 worker 线程泄漏：

bash复制ls -l /proc/<pid>/fd | wc -l
ls -l /proc/<pid>/fd | grep socket | head -20

第三步是 tcpdump 抓包，确认 FIN 是否到达以及是否回了 ACK 但没有后续：

bash复制tcpdump -i eth0 -nn "tcp port 8080 and (tcp[tcpflags] & (tcp-fin|tcp-ack) != 0)"

抓包结果里，能看到对端发来 FIN,ACK，本机回了 ACK，然后就没下文了——应用层没有发起自己的 FIN，连状态一直卡在 CLOSE_WAIT。到这里，问题已经从“网络层面”收敛到了“应用层代码没有关闭 fd”。

6.2 修复与验证：不只要 close，还要有超时兜底

修复就是补上 close，但代码里一定要加超时保护。比如说：setSoTimeout、recv 的超时时间、整个处理的 deadline，任何一个超时都走 close 路径，防止某条业务逻辑 hang 住导致连接永不释放。

我当时在代码里把 read 循环改成显式处理 n==0 的场景，统一走一个 cleanupConnection() 方法，close 放在 finally 里，确保任何异常都会走到。改完之后，连续观察两个发布周期，CLOSE_WAIT 数量从七千降到几十，问题解决。

再补充一个验证小技巧：写完关闭逻辑后，用 ss -tanp 观察主动关闭方能不能进入 TIME_WAIT，而不是直接消失或变成 CLOSE_WAIT。TIME_WAIT 的出现说明四次挥手的最后一步已经走了，关闭流程是完整的。

6.3 运维侧可长期保留的三个监控指标

CLOSE_WAIT 数量：超阈值（比如大于 100 或占比超过 1%）告警；
TIME_WAIT 数量：单端口超过端口范围 30% 时预警；
ESTABLISHED 数量的异常陡降：可能意味着网络分区或服务被 kill。

7. 把关闭当功能设计：产品视角下的连接生命周期管理

TCP 连接关闭看似只是内核的机制，但真正成熟的网络服务，会把关闭当成一个一等公民功能来设计。因为连接的生命周期直接关系到用户体验、数据完整性和资源成本。

业务侧可以约定的规则有三条：

谁主动谁负责：主动关闭方要准备承担 TIME_WAIT 的代价，所以服务端尽量少主动断连，把断连动作交给连接发起方；
关闭前必须清账：所有业务数据发送完毕后再发 FIN，不要靠 RST 去释放连接；
每一条连接都有超时：无论是读超时、写超时、空闲超时，至少要有一个生效，否则优雅关闭无从谈起。

有一次做长轮询服务，客户端处理完请求后没有关闭连接，而是继续等待服务端推送。因为长轮询的特性，服务端在超时后需要主动断开连接，客户端检测到 EOF 后再重新建连。这个“断开重连”机制就是靠半关闭实现的：客户端已经调了 shutdown(SHUT_WR)，服务端读到 EOF 就知道这次请求结束，等超时或推送完成后由服务端发 FIN，双方自然结束，重复利用半关闭的语义完成了一个业务周期。

这种“把连接关闭编进业务流程”的思路，才是 TCP 半关闭真正值钱的地方——它不只是协议栈里的一个状态，而是应用层可以依赖的设计原语。

8. 最后分享几个我用真金白银换来的细节

文章快写完了，按惯例交底几个细节，都是我实际被坑过之后沉淀下来的。

第一个是 close() 和 shutdown(SHUT_WR) 千万不要混淆使用。close() 会释放文件描述符，影响的是“引用”；而 shutdown() 控制的是“方向”。多线程共享一个 socket 时，A 线程调 close 可能不会真正关闭连接，因为 B 线程还持有引用，此时对端不会收到 FIN。如果要实现“A 线程不发了但 B 线程还能收”这样的行为，必须用 shutdown 而不是 close。

第二个是不要试图通过改内核参数来掩盖应用层 bug。tcp_tw_reuse 这类参数只能缓解端口压力，如果不解决“为什么会产生那么多 TIME_WAIT”，等流量翻倍的时候还是会爆。优先从代码层面优化：复用长连接、让服务端做主动关闭方、合理设置空闲超时。

第三个是抓包看关闭过程时，注意观察最后一个 ACK 的序列号是否正确。如果最后一个 ACK 没有带上对端 FIN 的序列号 + 1，那说明这个 ACK 不是针对 FIN 的确认，挥手过程还没走完。

第四个是针对长连接服务，建议在协议层设计一个 GOAWAY 或 DRAIN 指令。服务端要重启时，先广播一条“我要关了，别发新请求”，然后等存量请求处理完，再逐个优雅关闭。HTTP/2 的 GOAWAY 帧其实就是这个思路，值得借鉴到私有协议里。

TCP 连接的优雅关闭，本质上是对“结束”的尊重：给它时间，给它明确信号，让它把最后一句话说完。能用好半关闭状态，你的网络程序在很多极端情况下会比别人稳上一截。