1. 从一次线上故障说起为什么需要四次挥手那天晚上我正在处理一个线上服务的告警。监控显示某个核心服务的连接数在缓慢但持续地增长最终触发了“连接数过多”的阈值。登录服务器一看netstat -an | grep TIME_WAIT命令的结果密密麻麻几乎全是同一个远端地址。问题很典型大量的 TCP 连接没有正常关闭卡在了TIME_WAIT状态耗尽了本地端口资源。而这一切的根源都指向了 TCP 连接终止的那个关键过程——四次挥手。很多人对 TCP 的三次握手耳熟能详因为它象征着连接的建立是通信的开始。但四次挥手这个标志着通信结束的“告别仪式”其复杂性和重要性却常常被低估。一个不优雅的“告别”轻则导致端口被长时间占用重则引发数据丢失、连接重置甚至服务不可用。理解四次挥手不仅仅是背下FIN和ACK包的发送顺序更是理解 TCP 协议如何保证可靠、有序、全双工地结束一次对话。简单来说四次挥手是 TCP 协议用于安全、可靠地终止一个已建立连接的过程。它之所以是“四次”而非像握手那样可以优化为三次核心原因在于 TCP 连接的全双工特性。全双工意味着数据在两个方向上可以独立传输。当一方说“我的数据发完了要关闭连接”时它只是关闭了自己这个方向的数据流另一方可能还有数据要发送。因此连接的关闭必须是一个双向、分步确认的过程。这个过程涉及四个报文段FIN结束、ACK确认、另一个FIN、另一个ACK。接下来我们就深入这个过程的每一个细节看看一个连接是如何“体面”地画上句号的。2. 四次挥手的标准流程与报文段拆解让我们以一个典型的客户端-服务器模型为例假设客户端主动发起关闭。整个流程如下图所示此处为文字描述想象一个时序图客户端首先发送FIN服务器回应ACK然后服务器发送自己的FIN客户端最后回应ACK。下面我们拆解每一个步骤。2.1 第一次挥手主动关闭方发送 FIN客户端应用进程调用close()系统调用或shutdown(SHUT_WR)操作系统 TCP 协议栈会构造一个 TCP 报文段。这个报文段的关键在于其首部的控制标志位FIN 标志位被设置为 1同时序列号Seq为一个特定值假设为u。这个FIN报文段的意思是“我客户端在这个方向客户端到服务器的数据已经全部发送完毕我准备关闭我这个方向的连接了。”注意发送FIN仅仅意味着不再发送数据但仍然可以接收数据。此时客户端进入FIN_WAIT_1状态等待对方对FIN的确认。这里有一个关键细节FIN报文段和普通数据报文段一样也要占用一个序列号。也就是说Seq u的这个序列号被这个FIN报文消耗了。如果之前有最后一个数据字节的序列号是u-1那么FIN的序列号就是u。对方在确认时需要确认这个序列号u。2.2 第二次挥手被动关闭方发送 ACK服务器端的 TCP 协议栈收到这个FIN报文后知道客户端已经完成了数据发送。它首先会回应一个ACK 报文段。这个 ACK 报文段的确认号Ack被设置为u 1表示“我已经成功收到了序列号u及之前的所有数据包括这个FIN报文”。此时服务器端从ESTABLISHED状态进入CLOSE_WAIT状态。这个状态的名字很形象关闭等待。它表示服务器已经收到了对方的关闭请求并进行了确认但服务器自己可能还有数据需要发送给客户端所以它自己的发送通道还没有关闭。对于客户端而言收到这个ACK后就从FIN_WAIT_1状态迁移到FIN_WAIT_2状态。它知道对方已经确认了自己这边的关闭请求现在它只需要等待对方也发起关闭。2.3 第三次挥手被动关闭方发送 FIN当服务器端应用程序也处理完所有数据并调用close()时服务器端的 TCP 协议栈会构造并发送它自己的FIN 报文段。这个报文段的序列号Seq是另一个值假设为w它由服务器端之前的数据流决定同时FIN标志位为 1。发送完这个FIN后服务器端的状态从CLOSE_WAIT进入LAST_ACK状态。这是最后确认状态表示服务器已经发出了关闭请求现在正在等待客户端对这个请求的最终确认。2.4 第四次挥手主动关闭方发送 ACK客户端收到服务器的FIN报文后必须进行确认。它发送最后一个ACK 报文段其确认号Ack为w 1。发送完这个ACK后客户端的状态从FIN_WAIT_2进入TIME_WAIT状态。请注意此时客户端不会直接进入CLOSED状态而是会等待一段名为2MSLMaximum Segment Lifetime报文段最大生存时间通常为 2 分钟的时间。这是四次挥手中最微妙、也最容易出问题的一个环节我们稍后会详细解释。服务器端收到这个最终的ACK后就认为连接已正常关闭状态从LAST_ACK变为CLOSED释放所有连接资源。至此标准的四次挥手完成。我们可以用下面的表格来总结整个过程的状态变迁和报文关键字段步骤发送方发送报文关键字段发送方状态变化接收方状态变化第一次挥手客户端FINFIN1, SequESTABLISHED-FIN_WAIT_1ESTABLISHED-CLOSE_WAIT第二次挥手服务器ACKACK1, Acku1FIN_WAIT_1-FIN_WAIT_2(保持CLOSE_WAIT)第三次挥手服务器FINFIN1, Seqw(保持FIN_WAIT_2)CLOSE_WAIT-LAST_ACK第四次挥手客户端ACKACK1, Ackw1FIN_WAIT_2-TIME_WAIT- (等待2MSL后)CLOSEDLAST_ACK-CLOSED3. 深入核心为什么必须是四次TIME_WAIT的深意理解了标准流程我们再来深挖两个最核心的问题为什么挥手是四次而不是三次以及令人“讨厌”的TIME_WAIT状态到底为什么存在3.1 全双工连接的拆解无法合并的ACK三次握手可以合并SYNACK是因为连接建立时通信的“管道”是空的SYN报文本身不携带应用数据服务器可以将“确认客户端的SYN”和“发起自己的SYN”放在一个报文里发送。但四次挥手不行根本原因在于TCP 连接是全双工的可以看作两条独立的、单向的数据流。关闭连接需要分别关闭这两条数据流。当客户端发送FIN时它关闭的是“客户端 - 服务器”的数据流。服务器回复ACK是对这个关闭动作的确认。但此时“服务器 - 客户端”的数据流可能还在传输数据比如服务器还在发送查询结果。因此服务器的ACK和它自己的FIN不能像握手那样合并发送必须等待应用层通知“我也发完了”才能发出FIN。这就必然导致了四次交互。有一种特殊情况如果被动关闭方在收到FIN时恰好也没有任何数据要发送了那么它可以将第二次挥手的ACK和第三次挥手的FIN合并为一个报文发送这就是三次挥手。Linux 内核中有一个参数tcp_fin_timeout会影响这个行为但默认情况下为了协议的清晰和可靠标准实现仍然是分开的。3.2 TIME_WAIT不是BUG而是重要的安全特性TIME_WAIT状态也称为2MSL等待状态。MSL 是任何 IP 数据报能在网络中存活的最长时间。RFC 793 建议设为 2 分钟但 Linux 通常设置为 30 秒或 60 秒可通过/proc/sys/net/ipv4/tcp_fin_timeout查看和调整注意这个参数实际控制的是FIN_WAIT_2状态的超时而TIME_WAIT的时长是固定的2MSL通常为 60 秒。客户端在发送完最后一个ACK后必须保持TIME_WAIT状态2MSL时长。这主要有两个至关重要的目的可靠地终止连接确保最后一个ACK能到达服务器。如果这个ACK在网络中丢失处于LAST_ACK状态的服务器会因为超时而重传它的FIN报文。此时仍处于TIME_WAIT的客户端可以再次收到这个FIN并重传ACK从而保证服务器能正常关闭。如果没有TIME_WAIT客户端发完ACK就消失服务器可能永远收不到确认一直卡在LAST_ACK状态。让旧连接的报文在网络中消逝防止“旧连接的重复报文”被“新连接”错误接收。假设我们关闭了一个连接源IP:端口 目标IP:端口紧接着又用相同的四元组建立了一个新连接。如果旧连接的某个延迟报文姗姗来迟它可能会被误认为是新连接的数据。2MSL的等待时间足以让这个方向产生的所有旧报文都在网络中失效超过 MSL 被丢弃同时也让对端发送的报文有足够时间到达另一个 MSL。这从根本上避免了新旧数据混淆的问题。实操心得正因如此在编写高并发短连接服务如 HTTP 1.0 服务器、某些 RPC 框架时你会看到大量的TIME_WAIT连接。这不一定是问题它是 TCP 协议正常工作的一部分。只有当TIME_WAIT连接过多耗尽了可用端口对于客户端或影响了新连接建立对于服务器时才需要处理。处理方式不是禁用TIME_WAIT这很危险而是采用连接复用如 HTTP Keep-Alive、调整端口范围、或启用SO_REUSEADDR/SO_REUSEPORT套接字选项来允许重用处于TIME_WAIT状态的地址。4. 状态迁移全景与异常情况处理要真正驾驭 TCP 连接的生命周期必须对状态迁移图有直观的理解并知道在异常情况下如何分析和处理。4.1 TCP 连接终止状态机详解我们可以把四次挥手涉及的状态提炼出来形成一个简化的状态迁移视角主动关闭方路径ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED被动关闭方路径ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSED几个关键状态的特征FIN_WAIT_2半关闭状态。客户端在此状态只能收不能发。如果对端一直不发送FIN比如对方程序忘了调用close连接就会一直卡在这里。Linux 中可以通过net.ipv4.tcp_fin_timeout参数设置超时默认 60 秒超时后连接强制关闭。CLOSE_WAIT这是一个需要开发者高度警惕的状态它表示本地应用已经收到了对方的关闭请求FIN但本地的应用程序没有及时调用close()来关闭套接字。如果服务器程序出现 Bug 或资源泄漏会导致大量连接长期停留在CLOSE_WAIT状态同样消耗系统资源。这通常意味着你的应用程序代码在连接管理上有问题。LAST_ACK和TIME_WAIT如前所述是关闭序列的最后等待状态。4.2 常见异常场景与排查命令在实际运维和开发中你会遇到各种连接没有正常关闭的情况。掌握几个关键命令至关重要查看连接状态netstat -antp或更现代的ss -antp。重点关注TIME_WAIT,CLOSE_WAIT,FIN_WAIT_2的数量。# 统计各种状态的数量 netstat -n | awk /^tcp/ {S[$NF]} END {for(a in S) print a, S[a]}大量 TIME_WAIT现象作为客户端频繁创建短连接时出现。影响占用本地端口可能导致无法发起新连接“Address already in use”。解决首选优化应用使用长连接连接池。调整内核参数需谨慎# 启用TIME_WAIT快速回收RFC 1323可能不兼容所有网络设备 sysctl -w net.ipv4.tcp_tw_recycle0 # 注意Linux 4.12已移除该参数 # 启用TIME_WAIT重用允许新连接重用TIME_WAIT状态的套接字 sysctl -w net.ipv4.tcp_tw_reuse1 # 调整本地端口范围 sysctl -w net.ipv4.ip_local_port_range1024 65535在服务器端代码中设置套接字选项SO_REUSEADDR。大量 CLOSE_WAIT现象通常出现在服务器端是程序 Bug 的明确信号。根因对方关闭了连接发来了FIN但本机应用程序没有执行close()。可能是代码逻辑错误导致套接字未释放或是线程阻塞、死锁。排查使用lsof -i :端口号或通过ss/netstat找到对应的进程 PID检查该进程的代码确保在所有执行路径上包括异常处理都正确关闭了套接字。连接卡在 FIN_WAIT_1 或 FIN_WAIT_2FIN_WAIT_1卡住可能是发出的FIN报文丢失或对方的ACK丢失。有超时机制。FIN_WAIT_2卡住对方迟迟不发送FIN。检查对端应用程序是否正常。可通过调整tcp_fin_timeout来避免永久等待。5. 抓包实战用 Wireshark 观察四次挥手理论说得再多不如亲手抓包看一次。我们用一个简单的 Python 客户端-服务器例子并用 Wireshark 捕获挥手过程。服务器端代码 (server.py):import socket import time s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1) s.bind((127.0.0.1, 12345)) s.listen(1) print(Server listening...) conn, addr s.accept() print(fConnected by {addr}) # 接收一点数据 data conn.recv(1024) print(fReceived: {data}) time.sleep(2) # 模拟服务器处理数据 conn.send(bHello from server) # 服务器先不close等客户端先关 time.sleep(5) conn.close() s.close()客户端代码 (client.py):import socket import time s socket.socket(socket.AF_INET, socket.SOCK_STREAM) s.connect((127.0.0.1, 12345)) s.send(bHello from client) data s.recv(1024) print(fReceived: {data}) time.sleep(1) # 客户端主动关闭 s.close() time.sleep(10) # 保持进程不立即退出方便观察TIME_WAIT操作步骤启动 Wireshark监听lo环回接口过滤tcp.port 12345。先运行python server.py。再运行python client.py。观察 Wireshark 捕获的报文。你应该能看到类似下面的序列序号为相对值No. Time Source Destination Protocol Info 1 0.000000 127.0.0.1 127.0.0.1 TCP [SYN] Seq0 ... 2 0.000023 127.0.0.1 127.0.0.1 TCP [SYN, ACK] Seq0 Ack1 ... 3 0.000034 127.0.0.1 127.0.0.1 TCP [ACK] Seq1 Ack1 ... # 三次握手完成 ... (数据交换) ... 10 8.001234 127.0.0.1 127.0.0.1 TCP [FIN, ACK] Seq101 Ack201 ... # 第一次挥手 (FIN) 11 8.001267 127.0.0.1 127.0.0.1 TCP [ACK] Seq201 Ack102 ... # 第二次挥手 (ACK) 12 10.005678 127.0.0.1 127.0.0.1 TCP [FIN, ACK] Seq201 Ack102 ... # 第三次挥手 (FIN) 13 10.005689 127.0.0.1 127.0.0.1 TCP [ACK] Seq102 Ack202 ... # 第四次挥手 (ACK)在 Wireshark 的 Info 列你可以清晰地看到[FIN, ACK]和[ACK]的标志。点击某个报文在下方详情面板的 “Transmission Control Protocol” 部分可以展开看到 Flags 字段其中FIN和ACK会被标记出来。通过观察Seq和Ack号的变化你可以验证我们前面所讲的确认机制。6. 编程中的注意事项与最佳实践理解了原理最终要落实到代码上。无论是用 C、Java、Go 还是 Python处理 TCP 连接关闭时都有一些共通的坑和最佳实践。6.1 正确调用 close() 与 shutdown()close()默认行为是双向关闭。它既关闭发送通道发送FIN也关闭接收通道。如果接收缓冲区还有未读数据这些数据会被丢弃。调用close()后套接字描述符会立即被释放不能再用于读写。shutdown()提供了更精细的控制。SHUT_RD关闭读通道。后续的recv()调用会返回 0EOF。这不会发送任何 TCP 报文。SHUT_WR关闭写通道。这会触发发送FIN报文进入半关闭状态。这是实现“优雅关闭”的关键它告诉对方“我数据发完了”但还可以继续接收对方的数据。SHUT_RDWR等同于close()但描述符不一定立即释放。最佳实践对于需要“优雅关闭”的场景比如确保对方收到所有数据后再关闭推荐使用shutdown(SHUT_WR)先关闭写端然后继续读取对方可能发来的剩余数据直到recv()返回 0最后再调用close()。6.2 处理“粘包”与“半关闭”在四次挥手过程中FIN也是一个 TCP 报文段它和普通数据一样需要被确认。但FIN并不代表应用层数据的边界。这就是为什么在CLOSE_WAIT状态服务器仍然可以发送数据。应用程序必须设计自己的协议如长度头、分隔符等来界定一个完整的“应用层消息”而不能依赖FIN来判断消息结束。6.3 应对对端意外断开Reset并非所有连接都通过四次挥手优雅关闭。如果一方进程崩溃或被强制杀死操作系统会直接发送RST (Reset)报文段来重置连接。收到RST的一方连接会立即进入CLOSED状态所有待发送和已接收未读的数据都可能丢失。在编程中你需要处理这种情况当send()一个已收到RST的连接时系统会返回错误如EPIPE或引发SIGPIPE信号。当recv()时如果连接被重置会返回错误或 0取决于时机。使用心跳机制可以更快地检测到对端异常断开而不是等待 TCP 超时默认可能数分钟。6.4 套接字选项SO_LINGERSO_LINGER选项可以控制close()的行为。struct linger { int l_onoff; /* 0off, nonzeroon */ int l_linger; /* 延迟时间单位秒 */ }; setsockopt(sockfd, SOL_SOCKET, SO_LINGER, opt, sizeof(opt));l_onoff 0默认close()立即返回操作系统会在后台尝试完成数据的发送和挥手过程优雅关闭。l_onoff 1, l_linger 0强制关闭。close()立即返回并发送RST报文直接重置连接跳过四次挥手。所有未发送的数据都会丢失。这可以避免TIME_WAIT状态但破坏了协议的可靠性一般不推荐。l_onoff 1, l_linger 0close()会阻塞直到数据发送完毕并收到对方的ACK或者阻塞时间超过l_linger秒。超时后会发送RST。在大多数追求可靠性的服务端程序中通常使用默认设置或显式设置l_onoff0。只有在极端性能敏感、且能容忍连接重置的场景下才考虑使用l_linger0。7. 从协议栈到应用性能调优与内核参数对于需要处理海量短连接的服务器如网关、代理、HTTP 1.0 服务器TIME_WAIT会成为性能瓶颈。除了前面提到的应用层使用连接池还可以从操作系统内核层面进行调优。Linux 内核参数调优示例编辑/etc/sysctl.conf后执行sysctl -p# 允许将TIME_WAIT套接字重新用于新的TCP连接安全推荐 net.ipv4.tcp_tw_reuse 1 # 注意tcp_tw_recycle 在较新内核中已移除因其在NAT环境下易导致问题不应再使用。 # 扩大本地端口范围 net.ipv4.ip_local_port_range 10000 65535 # 增加系统允许的最大文件描述符数量连接数受此限制 fs.file-max 1000000 # 加快TIME_WAIT状态下连接的回收通过缩短TCP时间戳的循环周期有一定风险 # net.ipv4.tcp_timestamps 1 # (默认开启) # net.ipv4.tcp_tw_recycle 0 # **重要不要启用已废弃且有害** # 调整TCP缓冲区大小根据网络状况调整 net.ipv4.tcp_rmem 4096 87380 6291456 net.ipv4.tcp_wmem 4096 16384 4194304最重要的建议不要盲目调整内核参数。尤其是像tcp_tw_recycle这样的参数在存在 NAT网络地址转换的环境下比如云服务器、容器、家用路由器后的设备启用它会导致连接不稳定。理解每个参数的含义并在测试环境中充分验证后再应用到生产环境。理解 TCP 四次挥手不仅仅是记住一个流程更是建立起对网络连接生命周期管理的完整认知。从应用代码中正确的close()调用到操作系统内核的状态维护和超时处理再到网络报文的重传与确认每一环都影响着服务的稳定性和性能。下次当你再看到TIME_WAIT或CLOSE_WAIT堆积时希望你能胸有成竹快速定位到问题的根源。