TCP的“三次握手”与“四次挥手”是网络通信中建立与断开连接的核心机制，保证了数据传输的可靠性。

三次握手：如何可靠地建立连接

三次握手的本质，是通信双方在不可靠的IP网络上，通过三次交互来同步彼此的初始序列号（ISN），并确认双方的收发能力均正常。整个过程由客户端主动发起，服务器被动响应。

初始状态：起初，服务器需先进入LISTEN（监听）状态，随时准备响应客户端的请求。客户端则处于CLOSED（关闭）状态。

第一次握手（客户端 → 服务器）：客户端向服务器发送一个首部SYN（同步）标志位设为1的数据包。这个包中会携带一个客户端随机生成的初始序列号，假设为x。此报文不携带应用层数据，但会消耗一个序列号。发送后，客户端进入SYN-SENT状态，表示它已发出请求，正在等待确认。

第二次握手（服务器 → 客户端）：服务器收到SYN报文后，需要给出一个“收到并同意”的答复。它会向客户端回复一个同时设置了SYN和ACK（确认）标志位的数据包。在这个包中，服务器会填入自己的初始序列号y，并将确认号设为x+1，表示已收到客户端序号为x的报文。此报文同样不携带数据，也消耗一个序列号。发送后，服务器从LISTEN进入SYN-RCVD状态。

第三次握手（客户端 → 服务器）：客户端收到服务器的SYN+ACK报文后，会再次发送一个ACK标志位设为1的确认报文。该报文的序列号为x+1，确认号为y+1，表示已收到服务器的SYN报文。这个报文可以携带数据，若不携带则不消耗序列号。一旦发出，客户端便进入ESTABLISHED（连接已建立）状态。服务器收到这个ACK后，也随即进入ESTABLISHED状态。

核心问题：为什么必须是三次？

如果只有两次握手，就无法避免网络中延迟的、早已失效的连接请求报文突然到达服务器，导致服务器单方面错误地建立连接，白白浪费资源。最关键的是，两次握手无法让服务器确认客户端的接收能力是正常的。通过第三次握手，服务器才能确信客户端收到了自己的同步信号，从而彻底避免“单向通”的问题。

四次挥手：如何断开连接

由于TCP连接是全双工的（即数据可以在两个方向上独立流动），因此每个方向都需要被单独关闭。这就像两个人结束通话，需要各自说“我说完了”并得到对方确认，因此通常需要四次交互。

初始状态：起初，客户端和服务器都处于ESTABLISHED状态。假设这次是客户端主动发起关闭。

第一次挥手（客户端 → 服务器）：客户端决定关闭连接，于是发送一个首部FIN（结束）标志位设为1的报文，表示“我已没有数据要发送了”。发送后，客户端进入FIN-WAIT-1状态。

第二次挥手（服务器 → 客户端）：服务器收到FIN报文后，立刻回复一个ACK标志位设为1的确认报文，表示“我知道你准备关闭了”。此时，客户端到服务器这个方向的连接就被半关闭了。服务器进入CLOSE-WAIT状态，而客户端收到ACK后进入FIN-WAIT-2状态。如果此时服务器还有数据要发送，它可以继续发送，客户端依然可以接收。

第三次挥手（服务器 → 客户端）：当服务器的数据也全部发送完毕后，它便可以发起自己的关闭请求。服务器会发送一个FIN标志位设为1的报文给客户端，表示“我的数据也发完了，可以关闭连接了”。发送后，服务器进入LAST-ACK状态，等待客户端的最终确认。

第四次挥手（客户端 → 服务器）：客户端收到服务器的FIN报文后，会回复最后一个ACK标志位设为1的确认报文。发送后，客户端进入TIME-WAIT状态，等待2MSL（Maximum Segment Lifetime，即报文最大生存时间的两倍）时长后才最终关闭。服务器收到这个ACK后，则立即进入CLOSED状态。

核心细节：TIME-WAIT与CLOSE-WAIT

TIME-WAIT为何等待2MSL？ 主要目的有两个。首先，是为了确保最后一个ACK报文能被服务器收到。如果这个ACK在传输中丢失，服务器会因为没有收到确认而重传FIN报文，2MSL的等待时间足以让客户端接收到这个重传的FIN并再次回应ACK。其次，是为了让本次连接期间产生的所有“迷路”的旧报文都在网络中彻底消失，避免它们干扰到后续可能建立的、使用相同端口的新连接。

CLOSE-WAIT状态积压：如果在服务器上看到大量连接长期处于CLOSE-WAIT状态，这通常意味着服务器程序存在Bug——它收到了客户端的FIN请求并回复了ACK，但自身迟迟不调用close()函数来发送自己的FIN报文，导致连接无法释放。

概括总结

“三次握手”的本质是在不可靠的信道上，通过一次完整的往返确认，让双方都确信对方的收发能力正常，并安全地交换了初始序列号，为后续可靠传输打下基础。

“四次挥手”则是因为TCP的全双工特性，需要将两个半连接分别关闭。每一方的关闭都需要一个FIN和ACK的交互，导致了四个步骤。其核心挑战在于处理关闭过程中的不确定性，因此设计了诸如CLOSE-WAIT和TIME-WAIT等状态来应对潜在的延迟和数据丢失，确保连接最终能被干净、完整地释放。