tcp四次挥手只抓的到3个包的原因分析

理论上来说，tcp的四次挥手过程是这样的：
第一次挥手（FIN）：关闭连接的一方发送一个带有FIN（Finish）标志的TCP数据包，表示它已经没有数据要发送了，并请求关闭连接。该方将进入FIN_WAIT_1状态，等待另一方的确认。（实际这边被忽略了一个ACK，下文会解释）

第二次挥手（ACK）：另一个方接收到关闭连接的请求后，会发送一个带有ACK（Acknowledgment）标志的TCP数据包，表示它已经收到了关闭连接的请求。此时，该方进入CLOSE_WAIT状态，等待关闭连接的请求。

第三次挥手（FIN）：如果另一个方也没有要发送的数据了，它也会发送一个带有FIN标志的TCP数据包，表示它已经完成了数据发送，并请求关闭连接。该方进入LAST_ACK状态。

第四次挥手（ACK）：关闭连接的一方接收到另一个方的关闭请求后，会发送一个带有ACK标志的TCP数据包，表示它已经收到了关闭请求，并确认关闭连接。此时，该方进入TIME_WAIT状态，等待一段时间后才会关闭连接。

但是在今天真机抓包的时候发现了实际四次握手的第二次和第三次是合并在一起了，并没有分成两次来发送（seq和ack的值是没问题的），后面查了下资料这种情况不仅发生在tcp，可能在其他的协议中也会发生，比如说ssl，在握手的过程中理论上的交互包有十来个，但是实际抓的可能才几个，这种现象是协议开发者为了提高效率而做的有意的合并，以下举个例子如图：整个通信过程的最后3个包为四次挥手的过程
Fin第一个包：首个挥手包本端告诉对端的FIN和本端告诉对端的ACK合并在了一起
在TCP连接中，关闭连接通常是由其中一方发起的。当一方决定关闭连接时，它会发送一个带有FIN标志的TCP报文，表示它已经没有数据要发送了，并请求关闭连接。但是，由于TCP是可靠传输协议，它需要确保发送的报文能够被对方正确接收。因此，在发送FIN标志的同时，也需要发送ACK标志，表示它已经确认接收到对方发送的数据，并且已经准备好关闭连接。这就是为什么第一次挥手发送的TCP报文中带有FIN和ACK标志的原因。只不过在实际及大多数人的理论中经常忽略这个ACK包
Fin第二个包：对端的FIN和对端回复本端FIN的ACK合并在一起
Fin第三个包：本端回复对端的FIN的ACK