1. 四次挥手概述

所谓四次挥手，是指客户端和服务端在断开 TCP连接 的过程中，总共发送了四个TCP报文。其中双方都可以主动断开连接。这里以客户端主动断开连接为例，展示四次挥手的完整流程：

概述：客户端向服务端发送 FIN 报文表示数据发送完毕，服务端回复 ACK 报文表示收到，待服务端将剩余的数据处理完毕，就发送 FIN 报文表示数据发送完毕，最终由客户端回复 ACK 报文，连接正式断开。

这里要特别强调一下几个问题：

「为什么第一次挥手要有ACK=1」

因为在发起第一次挥手之前，也会有服务端发送的报文，需要对它进行确认；

「为什么第三次挥手没有ACK=1？为什么第三次挥手和第二次挥手的seq、ack是一样的」

只有对「对方发来的报文」进行回应，才需要使ACK=1，并改变seq与ack。

在第二次挥手时，服务端已经对客户端进行过回应，以至于第三次挥手时，服务端并不需要再进行回应，故而没有ACK=1，第三次挥手的seq与ack也不会变化。

2. 为什么一定要四次挥手？三次挥手会出什么问题？

被动端开方在发送 第二次挥手（ACK）后，通常仍有数据需要处理并发送，因此 第二次挥手（ACK）与 第三次挥手（FIN）不能合并。

3. 某次挥手丢失，会如何？

依旧以客户端主动断开连接举例：

1. [第一次挥手丢失] 若丢失了第一次挥手，客户端等不到服务端发来的 第二次挥手（ACK），就会触发超时重传机制，重新发送 第一次挥手（FIN） 报文。若重发次数达到了限制却依旧收不到确认报文，就直接进入到 CLOSE 阶段。

2. [第二次挥手丢失] ACK报文是不会重传的，因此这里 和丢失第一次挥手一样，重发 第一次挥手（FIN）。

3. [第三次挥手丢失] 若丢失了第三次挥手，服务端等不到客户端发来的 第四次挥手（ACK），就会触发超时重传机制，重新发送 第三次挥手（FIN）报文。

4. [第四次挥手丢失] ACK报文是不会重传的，因此这里 和丢失第三次挥手一样，重发 第三次挥手（FIN）。

参考资料

TCP 是如何工作的？三次握手和 四次挥手是什么？

TCP连接的建立为什么需要三次握手？为什么不能两次或者四次？

小林coding - TCP连接断开