为什么需要四次挥手

核心在于理解TCP连接的全双工特性。

简单来说：因为TCP连接是全双工的，它有两个独立的数据传输通道（A→B 和 B→A），每个方向必须单独关闭。

假设客户端A主动关闭连接：

第一次挥手：FIN（A -> B）
- A发送一个FIN=1的报文，表示"我没有数据要发送给你了"。
- A进入 FIN_WAIT_1 状态，等待B的确认。
- 此时，A到B的数据通道关闭，但B到A的通道仍然可用。
第二次挥手：ACK（B -> A）
- B收到A的FIN后，立即回复一个ACK确认报文。
- B进入 CLOSE_WAIT 状态。
- 此时，A到B的通道确认关闭，B知道自己不会再收到A的数据，但B可能还有数据要发给A。
- A收到这个ACK后，进入 FIN_WAIT_2 状态，等待B可能发来的FIN。
第三次挥手：FIN（B -> A）
- 当B把剩下的所有数据都发送给A后，B发送一个FIN=1的报文。
- B进入 LAST_ACK 状态，等待A最后的确认。
第四次挥手：ACK（A -> B）
- A收到B的FIN后，发送一个ACK确认报文。
- A进入 TIME_WAIT 状态（等待2MSL时间，确保B收到了这个ACK，防止最后一个ACK丢失导致B无法正常关闭，等待 2MSL = 1MSL（我的ACK彻底失效） + 1MSL（你的重传FIN最大可能到达））。
- B收到这个ACK后，连接彻底关闭 ，B进入 CLOSED 状态。
- A在TIME_WAIT状态结束后，也进入 CLOSED 状态。

这是面试官最可能追问的地方。关键在于 TCP的"半关闭"状态。

三次握手时 ：B可以将SYN（建立请求）和ACK（对A请求的确认）合并发送，因为这两个动作发生在同一时刻。
四次挥手时 ：
- B收到A的FIN后，只能立即回复ACK，表示"我收到你的关闭请求了"。
- 但此时B的应用层可能还有数据要处理并发送 ，因此B的FIN必须等所有数据都发送完毕后才能发出。
- ACK是内核TCP协议栈立即回复的，而FIN是由应用层触发的，这两个事件在时间上是分离的，所以绝大多数情况下无法合并。

只有在一种极特殊的情况下，四次挥手可以变成三次 ：当B收到A的FIN时，B也没有任何数据要发送了 ，那么B就可以将自己的ACK和FIN合并成一个报文发送给A。但这属于TCP协议的优化，并非标准流程。

"四次挥手是由TCP连接的全双工特性和半关闭状态决定的。"

全双工：连接有A->B和B->A两个独立通道，需要各自关闭。
核心过程 ：主动关闭方（如客户端）先发FIN关闭自己的发送通道；被动关闭方先回ACK确认，然后在自己数据发送完毕后，再发FIN关闭自己的发送通道；最后主动方回ACK确认。
为什么是四次 ：被动方的ACK和FIN通常无法合并发送 。因为ACK是协议栈立即回复的，而FIN需要等待应用层所有数据发送完毕，两者存在时间差，这就产生了"半关闭"状态。
对比握手 ：三次握手时，服务端的SYN和ACK都是针对连接建立的，可以同时发出，所以能合并。