在网络通信中，TCP（传输控制协议）是一种可靠的、面向连接的协议，它在数据传输过程中保证了数据的可靠性和顺序性。而TCP的连接建立过程只需要三次握手，但是TCP的挥手过程却需要四次挥手，这是为什么呢？本文将深入探讨TCP挥手过程为何需要四次。
TCP连接的建立和断开
在深入探讨为什么TCP需要四次挥手之前，我们先简要回顾一下TCP连接的建立和断开过程。
-
TCP连接的建立（Three-way handshake）：
- 客户端向服务器发送SYN（同步）报文，表示请求建立连接。
- 服务器收到SYN报文后，向客户端发送SYN-ACK（同步-确认）报文，表示同意建立连接。
- 客户端收到服务器的SYN-ACK报文后，向服务器发送ACK（确认）报文，表示连接建立完成。
-
TCP连接的断开（Four-way handshake）：
- 主动关闭方（例如客户端）向被动关闭方（例如服务器）发送FIN（结束）报文，表示请求断开连接。
- 被动关闭方收到FIN报文后，发送ACK报文，确认收到FIN报文。
- 被动关闭方向主动关闭方发送FIN报文，表示同意断开连接。
- 主动关闭方收到FIN报文后，发送ACK报文，确认收到FIN报文，完成连接的断开。
为什么TCP需要四次挥手？
TCP需要四次挥手，主要有以下两个原因：
-
保证数据的可靠传输： 在TCP连接的断开过程中，主动关闭方发送FIN报文后，被动关闭方可能还有未发送完的数据。被动关闭方发送ACK报文确认收到FIN报文后，需要等待一段时间，直到确认所有数据已发送完毕，然后才能发送自己的FIN报文。这样可以确保数据的完整传输，避免数据丢失。
-
允许双方同时关闭连接： TCP协议允许连接的双方同时发起连接的断开。在这种情况下，双方都会向对方发送FIN报文，然后等待对方的ACK报文。如果TCP的挥手过程只需要三次，那么在双方同时发起连接的情况下，就会出现死锁的情况：双方都收到对方的FIN报文后，都发送了ACK报文，然后都等待对方的ACK报文，导致连接无法正常断开。因此，通过增加一次挥手，可以避免这种死锁情况的发生。
什么情况下可以三次挥手
当TCP连接的被动关闭方（例如服务器）没有数据要发送，并且开启了TCP延迟确认机制时，第二次 ACK 和第三次 FIN 可以合并传输，从而出现了三次挥手的情况。
TCP的延迟确认机制是一种优化机制，它允许被动关闭方在收到数据时不立即发送 ACK 报文进行确认，而是等待一段时间，如果在这段时间内收到了另一方的数据，就将 ACK 报文和之前收到的数据一起进行确认。这样可以减少网络中的 ACK 报文数量，提高网络的利用率。
当被动关闭方没有数据要发送时，它会收到主动关闭方发送的 FIN 报文，表示请求断开连接。如果开启了延迟确认机制，被动关闭方就会延迟发送 ACK 报文进行确认，而是等待一段时间，看是否在这段时间内收到了主动关闭方的数据。如果没有收到数据，被动关闭方就会发送 ACK 报文进行确认，并立即发送自己的 FIN 报文，表示同意断开连接。因此，第二次 ACK 和第三次 FIN 就可以合并传输，形成了三次挥手的情况。
这种情况下的三次挥手过程如下：
- 主动关闭方发送 FIN 报文。
- 被动关闭方收到 FIN 报文后，延迟一段时间后发送 ACK 报文进行确认，并立即发送自己的 FIN 报文。
- 主动关闭方收到 FIN 报文后，发送 ACK 报文进行确认，完成连接的断开。
在这种情况下，通过合并传输第二次 ACK 和第三次 FIN 报文，可以减少网络中的报文数量，提高网络的效率，但仍然保持了连接的可靠性和数据的完整性。
总结
TCP的挥手过程设计为四次是为了确保数据的可靠传输和允许连接的双方同时关闭连接。被动关闭方在发送第三次FIN报文之前需要确保所有数据已发送完毕，以保证数据的完整性。同时，增加一次挥手也确保了连接的灵活性和可靠性，从而提高了网络通信的稳定性和可靠性。
 toRef，toValue，toRefs和toRow，markRaw)
