文章目录
一、四次挥手流程

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、抓包四次挥手报文
二、引申问题
1、挥手报文丢失,会发生什么?
1.1、第一次挥手报文丢失
1.2、第二次挥手报文丢失
1.3、第三次挥手报文丢失
1.4、第四次挥手报文丢失
2、TIME_WAIT
2.1、为什么需要 TIME_WAIT?
为什么主动关闭 TCP 连接的一方需要 TIME_WAIT 状态?
2.2、为什么 TIME_WAIT 的持续时长是 2MSL?
2.3、过多的 TIME_WAIT 有什么危害?
3、为什么是四次挥手?可以是三次吗?
为什么断开 TCP 连接是四次挥手?
实战 - TCP 四次挥手,可以变成三次吗?(附代码示例)
本文详细介绍了 TCP 四次挥手断开连接的流程,包括客户端和服务端在每次挥手时的状态变化及发送的报文。还探讨了挥手报文丢失的情况、TIME_WAIT 状态的作用、持续时长及危害,以及为何是四次挥手而非三次。

被折叠的 条评论
为什么被折叠?



