在计算机网络的学习与实践中，TCP协议的三次握手与四次挥手是两个被反复讨论却又经常被混淆的概念。很多人能够背诵出状态迁移的序列，却难以说清二者在设计逻辑、资源管理以及异常处理层面的本质差异。

　　一、功能定位的根本不同

　　三次握手与四次挥手最本质的区别在于它们所处的阶段不同。三次握手用于建立连接，其核心目标是让通信双方就初始序列号达成一致，并确认对方具备收发数据的能力。而四次挥手用于释放连接，其核心目标是让双方各自确认不再有数据需要发送，并优雅地关闭传输通道。

　　从逻辑上看，建立连接是一个“从无到有”的过程，需要尽量减少交互次数以降低延迟;而释放连接是一个“从有到无”的过程，需要充分考虑双方可能还未发完的数据，因此步骤天然比握手多一次。

　　这一点直接决定了两者在设计上的不对称性：三次握手只需三次报文交换就能完成双向同步，而四次挥手至少需要四次。

　　二、报文标志位的语义差异

　　从TCP报文头部来看，三次握手主要依赖SYN和ACK两个标志位。第一次握手客户端发送SYN，表示请求同步序列号;第二次握手服务端回复SYN+ACK，表示同意同步并确认客户端的SYN;第三次握手客户端发送ACK，确认服务端的SYN。整个过程没有涉及FIN标志。

　　四次挥手则主要依赖FIN和ACK。第一次挥手主动关闭方发送FIN，表示本方数据已发送完毕，请求关闭连接;第二次挥手被动关闭方回复ACK，表示已收到关闭请求;第三次挥手被动关闭方发送FIN，表示本方也准备关闭;第四次挥手主动关闭方回复ACK，确认最终的FIN。

　　关键在于：SYN是双向一次完成的，而FIN是双向分步完成的。这是因为连接建立时双方都没有数据积压，可以同步协商;而关闭时一方可能还在发送数据，不能强制对方立即关闭。

　　三、状态迁移路径的对比

　　三次握手的客户端状态路径为：CLOSED → SYN_SENT → ESTABLISHED。服务端状态路径为：LISTEN → SYN_RCVD → ESTABLISHED。状态转换简单、线性，没有中间等待状态。

　　四次挥手的状态迁移则复杂得多。主动关闭方经历：ESTABLISHED → FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED。被动关闭方经历：ESTABLISHED → CLOSE_WAIT → LAST_ACK → CLOSED。

　　其中最值得关注的是TIME_WAIT状态。主动关闭方在发送最后一个ACK后，并不立即进入CLOSED，而是等待2MSL(最大报文生存时间)。这一状态在三次握手中完全不存在。TIME_WAIT的存在是为了防止滞留在网络中的重复报文段干扰后续新建的连接，这是释放连接阶段独有的可靠性保障机制。

　　另一个显著区别是CLOSE_WAIT状态。被动关闭方在收到FIN并回复ACK后，进入CLOSE_WAIT，等待应用程序调用close。这个状态持续时间可能很长，取决于应用层何时处理完剩余数据。三次握手中没有对应状态，因为建立连接时不存在“等待上层处理”的环节。

　　四、数据流方向的处理方式

　　三次握手中，数据流尚未开始传输，因此不存在半关闭状态。三次报文交换完成后，双向数据通道同时打开。

　　四次挥手则明确引入了半关闭(half-close)概念。当主动关闭方发送FIN并收到ACK后，主动方不再发送数据，但仍然可以接收来自被动方的数据。此时连接处于“半关闭”状态，直到被动方也发送FIN为止。这种设计允许TCP实现优雅关闭：一方通知对方自己已无数据，但不强迫对方立即停止发送。

　　三次握手不存在半关闭的任何需求或设计。

　　五、资源占用的差异

　　从资源角度看，三次握手过程中，服务端在收到SYN后会为连接分配资源(如缓存、控制块)，但如果后续ACK丢失，服务端可能会陷入SYN_RCVD状态并超时重传。这带来了SYN flooding攻击的风险，即攻击者大量发送SYN但不完成第三次握手，耗尽服务端资源。

　　四次挥手则面临不同的问题。主动关闭方在TIME_WAIT期间占用的端口号无法被立即重用，对于高并发短连接服务器，大量TIME_WAIT可能导致端口资源枯竭。这是一个典型的挥手阶段资源管理问题，握手阶段不存在。

　　此外，被动关闭方在CLOSE_WAIT状态仍持有连接资源，如果应用程序忘记调用close或存在bug，会导致连接泄漏。这种泄漏在握手阶段不会发生，因为握手完成后的连接已经处于全双工可用状态，不存在“半拉子”资源。

　　六、异常处理逻辑的差别

　　三次握手处理异常的方式相对直接。例如，如果客户端的第三次ACK丢失，服务端会超时重传SYN+ACK，达到重传上限后关闭连接。如果客户端的SYN丢失，由应用层超时重传。

　　四次挥手的异常处理更复杂。比如主动关闭方发送FIN后进入FIN_WAIT_1，如果对方的ACK始终不来，超时后直接关闭。更常见的情况是：被动关闭方在CLOSE_WAIT状态长时间不发送FIN，主动方会一直停留在FIN_WAIT_2。TCP协议规范并未对FIN_WAIT_2设置强制的超时时间，依赖上层应用或操作系统的保活机制来检测死连接。

　　另一个典型差异是同时关闭的处理。当双方同时发送FIN时，双方都进入CLOSING状态，然后各自回复ACK，最终同时进入TIME_WAIT。这种状态在三次握手中没有对应情况，因为同时打开(同时发送SYN)在TCP中虽有可能，但实际极为罕见且处理方式不同。

　　七、对上层应用的影响

　　三次握手对应用层几乎是透明的。应用程序调用connect后，内核自动完成握手过程，应用层只看到连接建立成功或失败。应用层无法干预握手过程中的任何细节。

　　四次挥手则允许应用层通过半关闭接口(如shutdown函数)进行精细控制。应用程序可以选择只关闭发送通道而保持接收通道，这在某些协议(如FTP的数据连接)中非常有用。此外，SO_LINGER套接字选项可以改变挥手行为——要求立即发送RST而非正常的四次挥手，或者限制关闭时的等待时间。

　　这些控制能力是挥手阶段特有的，握手阶段不存在类似的精细调节机制。

　　八、几个容易搞混的知识点

　　第一个误区：挥手一定要四次吗?

　　不一定。如果服务端收到FIN后也没有数据要发了，它可以把ACK和FIN合并到一个包里发，那就是三次挥手。但严格来说，TCP规范允许这个优化，所以实际抓包可能会看到三次或者四次。

　　第二个误区：TIME_WAIT为什么是2MSL?

　　MSL是报文在网络里能存活的最长时间。2MSL保证一个方向上的报文完全消失，另一个方向上的ACK也足够送达。想象一下，如果连接刚关闭，网络上还飘着这个连接的旧包，新建立的连接恰好用了同样的端口和序列号，就会把旧包当成新数据。2MSL就是等这些“幽灵包”彻底消散。

　　第三个误区：三次握手能带数据吗?

　　理论上可以，第三次握手的ACK包是可以带数据的。但实际实现中，很少这么干。不过SYN包(第一次、第二次)绝对不能带数据，因为SYN本身就要消耗一个序列号，带数据会让事情变得复杂。

　　总结：三次握手与四次挥手虽然都是TCP协议中连接管理的关键环节，但它们在设计目标、状态迁移、资源占用、异常处理以及对应用层的影响等方面存在显著差异。

　　简单概括：三次握手是双向同步，两次交互就能建立双向通道;四次挥手是两次单向释放，每一方都需要单独宣告数据发送完毕。多出的一次挥手，本质上是TCP对可靠性和优雅关闭的坚持——它宁可多一次报文交换，也不愿在对方还有数据未发送时强制关闭连接。

　　理解了这一点，就能明白为什么TCP不是三次挥手也不是两次挥手。这不是协议的偶然，而是可靠传输协议在连接管理上的必然选择。