TCP四次挥手问题详解

tcp四次挥手过程

首先以通俗易懂的方式来描述此过程

• 第一次

浏览器----------》服务器
浏览器告诉服务器，我准备要断开连接了

• 第二次

浏览器《----------服务器
服务器告诉浏览器，我知道你已经准备要断开连接了

• 第三次

浏览器《----------服务器
服务器告诉浏览器，我知道你已经准备要断开连接后，我也要断开连接了

• 第四次

浏览器----------》服务器
浏览器告诉服务器，收到你断开连接，我也断开连接

真实的四次挥手

刚开始都处于established状态 客户端端口，向服务器发FIN报文 发送后，客户端变成FIN-WAIT-1状态–以及half-close（半关闭）状态，即无法向服务端发送报文只能接收 服务端接收后向客户端确认，变成closed-wait状态 客户端接收到了服务端的确认，变成fin-wait2状态 服务端向客户端发送FIN，自己进入LAST-ACK状态， 客户端收到服务端发来的FIN后，自己变成了TIME-WAIT状态，然后发送 ACK 给服务端。

等待2MSL的意义

通过等待2MSL的时间，TCP能够确保在断开连接后，两个方向上的旧数据包都已经彻底消失，避免了可能的连接混乱和干扰。

• 1 个 MSL 确保四次挥手中主动关闭方最后的 ACK 报文最终能达到对端

• 1 个 MSL 确保对端没有收到 ACK 重传的 FIN 报文可以到达

为什么是四次挥手而不是三次？

与之前需要三次握手的原因类似，如果只是三次挥手，那就相当于服务器端发送完第三次挥手的报文后直接进入CLOSED（关闭）状态，假如此时网络出现问题，丢失了第三次挥手的报文，相当于客户端没有收到，那他依旧认为连接没有结束，在一段时间没有收到第二次ACK应答报文后，他会重新发送请求断开连接的报文，但是服务器端已经关闭，不会再接收报文，又形成了类似死锁的情况。