分析面试复盘问题：TCP两次握手为什么不行？三次挥手为什么不行？详解三次握手与四次挥手

本文链接：https://blog.csdn.net/2401_89221445/article/details/146569518

分析面试复盘问题：TCP两次握手为什么不行？详解三次握手与四次挥手

在计算机网络的面试中，TCP（传输控制协议）的握手和挥手机制是高频考点，尤其是“为什么TCP需要三次握手而不是两次？”以及“四次挥手的具体过程”等问题，几乎是网络基础知识的必考内容。本文将从问题本质出发，详细分析TCP两次握手为什么不行，深入讲解三次握手和四次挥手的原理，并结合面试常见考点探讨“三次挥手是否可行”。

一、TCP两次握手为什么不行？

TCP是面向连接的可靠传输协议，建立连接时需要确保双方都准备好发送和接收数据。假设TCP采用两次握手，过程可能是这样的：

客户端发送SYN（同步请求）给服务器。
服务器收到SYN后，直接回复ACK（确认）并进入连接状态。

表面上看，两次握手似乎完成了双方的确认，但问题在于这种机制无法保证服务器端确认客户端已经正确接收到ACK，从而可能导致连接的不可靠性。具体原因如下：

1. 旧连接请求的干扰（核心问题）

网络中可能存在延迟的数据包。假设客户端发送了一个SYN（序列号为X），由于网络拥堵，这个SYN迟迟未到达服务器。客户端超时后重新发送一个新的SYN（序列号为Y），服务器收到后回复ACK并建立连接。如果此时旧的SYN（X）突然到达服务器，服务器会误认为这是一个新的连接请求，再次回复ACK并建立一个“幽灵连接”。但客户端并不知道这个旧SYN的存在，不会响应，导致服务器单方面浪费资源。

三次握手通过额外的确认步骤（客户端收到ACK后回复ACK），可以让服务器验证客户端是否真的有意建立连接，从而避免旧连接请求的干扰。

2. 双向确认的缺失

两次握手中，服务器发送ACK后直接认为连接建立，但客户端可能并未收到这个ACK（例如ACK在网络中丢失）。此时服务器认为连接已建立，而客户端认为连接未成功，双方状态不一致，无法可靠通信。

因此，两次握手无法满足TCP对可靠性的要求，必须引入第三次握手。

二、TCP三次握手的详细过程

三次握手是TCP建立连接的标准流程，确保双方都能正常发送和接收数据。过程如下：

第一次握手（SYN）
客户端发送SYN包（SYN=1，seq=x），表示请求建立连接，seq是客户端的初始序列号。客户端进入SYN_SENT状态。
第二次握手（SYN+ACK）
服务器收到SYN后，回复SYN+ACK包（SYN=1，ACK=1，seq=y，ack=x+1），表示同意建立连接。seq=y是服务器的初始序列号，ack=x+1是对客户端SYN的确认。服务器进入SYN_RCVD状态。
第三次握手（ACK）
客户端收到SYN+ACK后，发送ACK包（ACK=1，seq=x+1，ack=y+1），确认服务器的SYN。客户端进入ESTABLISHED状态，服务器收到ACK后也进入ESTABLISHED状态，连接正式建立。

三次握手的意义

确认双方的发送和接收能力：第一次和第二次握手确认客户端到服务器的通道畅通，第二次和第三次握手确认服务器到客户端的通道畅通。
防止旧连接干扰：第三次ACK让服务器验证客户端的请求是当前的，而不是过期的。
初始化序列号：双方通过seq和ack协商初始序列号，确保数据传输的顺序和完整性。

三、TCP四次挥手的详细过程

TCP连接的释放需要四次挥手，确保双方都完成数据发送并关闭连接。过程如下：

第一次挥手（FIN）
主动关闭方（假设是客户端）发送FIN包（FIN=1，seq=x），表示自己数据发送完毕，不再发送数据，进入FIN_WAIT_1状态。
第二次挥手（ACK）
被动关闭方（服务器）收到FIN后，发送ACK包（ACK=1，ack=x+1），表示已收到关闭请求，但可能还有数据要发送。服务器进入CLOSE_WAIT状态，客户端收到ACK后进入FIN_WAIT_2状态。
第三次挥手（FIN）
服务器发送完剩余数据后，发送FIN包（FIN=1，seq=y），表示自己也准备关闭，进入LAST_ACK状态。
第四次挥手（ACK）
客户端收到FIN后，发送ACK包（ACK=1，ack=y+1），进入TIME_WAIT状态。服务器收到ACK后关闭连接，进入CLOSED状态。客户端在TIME_WAIT等待2MSL（最大报文生存时间）后也进入CLOSED状态。