1. 四次挥手概述
所谓四次挥手,是指客户端和服务端在断开 TCP连接 的过程中,总共发送了四个TCP报文。其中双方都可以主动断开连接。这里以客户端主动断开连接为例,展示四次挥手的完整流程:
![四次挥手完整流程](https://i-blog.csdnimg.cn/blog_migrate/7e808549d3a9378491f5c52413dd4f42.jpeg)
概述:客户端向服务端发送 FIN 报文表示数据发送完毕,服务端回复 ACK 报文表示收到,待服务端将剩余的数据处理完毕,就发送 FIN 报文表示数据发送完毕,最终由客户端回复 ACK 报文,连接正式断开。
这里要特别强调一下几个问题:
「为什么第一次挥手要有ACK=1」
因为在发起第一次挥手之前,也会有服务端发送的报文,需要对它进行确认;
「为什么第三次挥手没有ACK=1?为什么第三次挥手和第二次挥手的seq、ack是一样的」
只有对「对方发来的报文」进行回应,才需要使ACK=1,并改变seq与ack。
在第二次挥手时,服务端已经对客户端进行过回应,以至于第三次挥手时,服务端并不需要再进行回应,故而没有ACK=1,第三次挥手的seq与ack也不会变化。
2. 为什么一定要四次挥手?三次挥手会出什么问题?
被动端开方在发送 第二次挥手(ACK)后,通常仍有数据需要处理并发送,因此 第二次挥手(ACK)与 第三次挥手(FIN)不能合并。
3. 某次挥手丢失,会如何?
依旧以客户端主动断开连接举例:
-
[第一次挥手丢失] 若丢失了第一次挥手,客户端等不到服务端发来的 第二次挥手(ACK),就会触发超时重传机制,重新发送 第一次挥手(FIN) 报文。若重发次数达到了限制却依旧收不到确认报文,就直接进入到 CLOSE 阶段。
-
[第二次挥手丢失] ACK报文是不会重传的,因此这里 和丢失第一次挥手一样,重发 第一次挥手(FIN)。
-
[第三次挥手丢失] 若丢失了第三次挥手,服务端等不到客户端发来的 第四次挥手(ACK),就会触发超时重传机制,重新发送 第三次挥手(FIN)报文。
-
[第四次挥手丢失] ACK报文是不会重传的,因此这里 和丢失第三次挥手一样,重发 第三次挥手(FIN)。