TCP 四次挥手断开连接详解

原创已于 2025-08-12 10:04:45 修改 · 407 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#网络 #tcp

于 2019-10-27 15:46:40 首次发布

网络专栏收录该内容

51 篇文章

订阅专栏

本文详细介绍了 TCP 四次挥手断开连接的流程，包括客户端和服务端在每次挥手时的状态变化及发送的报文。还探讨了挥手报文丢失的情况、TIME_WAIT 状态的作用、持续时长及危害，以及为何是四次挥手而非三次。

一、四次挥手流程

在这里插入图片描述
TCP 四次挥手断开连接前，客户端和服务端都处于 ESTABLISHED 状态

1、第一次挥手

客户端主动关闭连接，此时会向服务端发送 FIN+ACK 报文(将 TCP 首部 FIN 和 ACK 标志位都设成 1)，之后客户端处于 FIN_WAIT_1 状态

注意

FIN 会消耗一个序列号

2、第二次挥手

服务端收到客户端的 FIN+ACK 报文后，会回给客户端 ACK 报文(将 TCP 首部 ACK 标志位设成 1)，之后服务端处于 CLOSE_WAIT 状态
客户端收到服务端的 ACK 报文后，进入 FIN_WAIT_2 状态

3、第三次挥手

服务端完成数据的发送后(如果还需要发送数据到客户端的话)，会向客户端发送 FIN+ACK 报文(将 TCP 首部 FIN 和 ACK 标志位都设成 1)，之后服务端处于 LASK_ACK 状态

注意

FIN 会消耗一个序列号

4、第四次挥手

客户端收到服务端的 FIN+ACK 报文后，会回给服务端 ACK 报文(将 TCP 首部 ACK 标志位设成 1)，之后客户端处于 TIME_WAIT 状态，一段时间(2MSL)后，客户端彻底关闭连接
服务端收到客户端的 ACK 报文后，彻底关闭连接

注意

主动关闭连接的一方才有 TIME_WAIT 状态
MSL：Maximum Segment Lifetime，报文最大生存时间，任何报文在网络上存在的最长时间，超过该时间的报文会被丢弃
- MSL 大于等于 TTL 消耗为 0 的时间
- Linux 内核中，2MSL 是 60s

/* Linux Kernel 6.14.7 tcp.h */
#define TCP_TIMEWAIT_LEN (60*HZ) /* how long to wait to destroy TIME-WAIT
				  * state, about 60 seconds	*/

5、抓包四次挥手报文

实战 - eNSP 抓包 TCP 四次挥手报文

二、引申问题

1、挥手报文丢失，会发生什么？

2、TIME_WAIT

2.1、为什么需要 TIME_WAIT？

为什么主动关闭 TCP 连接的一方需要 TIME_WAIT 状态？

2.2、为什么 TIME_WAIT 的持续时长是 2MSL？

为什么 TIME_WAIT 状态的持续时长是 2MSL？

2.3、过多的 TIME_WAIT 有什么危害？

过多的 TIME_WAIT 状态有什么危害？

3、为什么是四次挥手？可以是三次吗？

为什么断开 TCP 连接是四次挥手？
实战 - TCP 四次挥手，可以变成三次吗？(附代码示例)

4、异常情况下的连接断开机制

实战 - 验证 TCP 连接在异常情况下的断开机制