TCP 三次握手四次挥手：我画了六张图，终于讲清楚了

一、先搞清楚：TCP 连接是什么？

TCP连接并非抽象概念，其本质是通信双方在内核中维护的一组同步状态与缓冲区。建立连接，实质上是双方通过协议交互，确认双向通信通道已就绪并达成可靠共识的过程。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

整个过程由TCP报文头部的几个核心控制位驱动：

SYN  —— 同步序列号，发起连接
ACK  —— 确认号有效，表示应答
FIN  —— 发送方数据已发送完毕，请求终止连接
RST  —— 连接出现严重错误，强制复位

掌握这几个信号的含义，握手与挥手的过程便成为清晰的逻辑推演。

二、三次握手：不是仪式，是必要条件

首先通过流程图建立全局认知：

具体交互流程分解如下：

第一次握手：客户端发送一个SYN报文段，其序列号（seq）设置为随机生成的初始值x。此操作将客户端状态置为SYN_SENT，等待服务器确认。

第二次握手：服务器收到SYN后，若同意建立连接，则回复SYN-ACK报文。该报文同时承载两项功能：确认客户端的SYN（ACK位为1，确认号为x+1），并宣告自身的初始序列号y（SYN位为1）。服务器随即进入SYN_RCVD状态。

第三次握手：客户端对服务器的SYN进行确认，发送ACK报文（确认号为y+1）。此报文抵达后，双方同步进入ESTABLISHED状态，可靠数据传输通道正式建立。

三、灵魂拷问：为什么不能两次握手？

这是理解TCP可靠性设计的关键。仅靠两次握手无法解决“历史重复连接”问题。

考虑网络延迟场景：客户端发送的SYN报文可能因网络拥塞严重延迟。客户端超时后重发新SYN并成功建立连接。若采用两次握手，当那个延迟的旧SYN最终到达服务器时，服务器会误认为这是一个新的连接请求，直接分配资源并进入ESTABLISHED状态。

然而客户端对此连接并无感知，导致服务器资源被无效连接长期占用。这就是“已失效的连接请求报文”问题。

因此，第三次握手的ACK是服务端的必要保障。它让服务器能够最终确认：客户端确实收到了同步响应，并且当前请求是有效的。缺少这最终确认，服务器无法区分正常请求与网络延迟导致的过期请求。

四、序列号 seq 是什么？

握手过程中交换的初始序列号（ISN）承担两项核心职责：保障数据按序交付与防止旧报文干扰。

ISN为何采用随机值而非固定从0开始？这是为了防止前一个连接的报文段滞留在网络中，被后续新建的、端口相同的新连接错误接收。随机化的ISN极大降低了新旧连接序列号空间重叠的概率，确保了每个连接的独立性与数据完整性。

五、四次挥手：断开连接为什么比建立还麻烦？

连接终止需要四次交互，根源在于TCP的全双工通信特性。

建立连接时，双方目标一致（开启通道），因此服务器的SYN与ACK可合并发送。

关闭连接时，数据发送通道的关闭是独立的。当一方发送FIN，仅表示其数据发送完毕，但接收通道仍可工作。另一方需要先ACK确认收到FIN，然后继续发送其缓冲区剩余数据，最后再发送自己的FIN关闭其发送通道。由于ACK与FIN的触发条件与时机不同，因此通常需要四个步骤完成双向关闭。

六、TIME_WAIT 是什么？为什么等 2MSL？

这是TCP协议设计中一个关键状态。主动关闭连接的一方（发送最终ACK后）会进入TIME_WAIT状态，并持续2MSL（Maximum Segment Lifetime，报文最大生存时间）时长。Linux系统中MSL通常为60秒。

等待2MSL基于两个核心目的：

1. 确保连接可靠终止：若主动关闭方发出的最终ACK丢失，被动关闭方将重传FIN。2MSL的等待时间为重传FIN的到达提供了足够窗口，确保连接能彻底关闭。 2. 消除旧连接报文干扰：2MSL时间足以让本连接产生的所有报文在网络中自然消亡，避免其影响后续复用相同四元组（源/目IP与端口）的新连接。

生产环境影响与调优：高并发短连接服务中，若服务器频繁主动关闭，将产生大量TIME_WAIT连接，可能导致端口资源耗尽。解决方案是启用端口复用。

在应用层代码中设置套接字选项：

// 服务端设置 SO_REUSEADDR，允许绑定处于 TIME_WAIT 状态的地址
int reuse = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &reuse, sizeof(reuse));

或调整内核参数：

# 启用 TIME_WAIT 状态 socket 的快速复用
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse

七、完整状态机：TCP 连接一生经历的所有状态

这张状态转换图是理解TCP生命周期的核心。图中清晰划分了客户端（通常为主动发起方）与服务端（通常为被动监听方）的状态迁移路径。双方在ESTABLISHED状态汇合进行数据传输，并在关闭阶段遵循各自的路径完成资源回收。精通此图，意味着你已内化了TCP连接的管理逻辑。

八、用代码验证：亲眼看到状态变化

理论结合实践，通过命令行工具可直观观察TCP状态变迁：

# 终端1：启动简易TCP服务端监听8080端口
nc -l 8080

# 终端2：使用ss命令持续监控TCP连接状态（推荐）
watch -n 1 'ss -tan state established'
# 传统方法可使用netstat
# netstat -tan | grep :8080

# 终端3：客户端发起连接
nc 127.0.0.1 8080

# 在终端2观察，连接建立后可见 ESTABLISHED 状态
# 客户端中断连接后，可短暂观察到 TIME_WAIT 状态

在程序中，可通过getsockopt接口获取连接详细信息：

// 获取TCP连接内核信息
struct tcp_info tcp_info;
socklen_t len = sizeof(tcp_info);
if (getsockopt(sock_fd, IPPROTO_TCP, TCP_INFO, &tcp_info, &len) == 0) {
    // tcpi_state 对应连接状态，如 TCP_ESTABLISHED=1
    printf("Current TCP state: %d\n", tcp_info.tcpi_state);
}

九、高频面试题精析

Q：三次握手中，第三次 ACK 丢失会怎样？

服务端将维持在SYN_RCVD状态。根据TCP重传机制，服务端会多次重传SYN-ACK报文（默认重传次数及间隔由内核参数决定）。若客户端已进入ESTABLISHED并开始发送数据，数据报文本身带有ACK标志，可促使服务端直接进入ESTABLISHED状态。若始终无确认，服务端最终会超时清除此半连接。

Q：为什么四次挥手不能合并成三次？

根本原因在于服务端收到FIN时，应用层可能仍有数据待发送，因此ACK与FIN不能立即合并。但在特定场景下（如服务端无待发数据），其ACK与FIN可合并发送，形成“三次挥手”。Linux的延迟确认（Delayed ACK）机制有时会促成此类合并，但这属于优化特例，而非协议标准行为。

Q：SYN Flood攻击是怎么利用握手过程的？

攻击者伪造源IP发送大量SYN报文，但不回应服务端的SYN-ACK，导致服务端半连接队列（SYN_RCVD状态）被占满，无法响应合法请求。有效防御机制是启用SYN Cookies：服务端不立即分配资源，而是根据连接信息计算一个哈希值（Cookie）作为初始序列号返回；仅在收到携带正确Cookie的ACK后，才分配完整连接资源。

Q：close()和shutdown()触发挥手有什么区别？

close()操作减少文件描述符的引用计数，仅当计数归零时才触发TCP关闭序列（发送FIN）。若描述符被复制（如通过fork()或dup()），单次close()可能不会立即终止连接。shutdown(fd, SHUT_WR)则不同，它直接作用于TCP连接，立即触发FIN发送流程，无视引用计数，是更确定性的连接终止方式。

十、一图总结：三次握手 vs 四次挥手

十一、结语

TCP握手与挥手的设计，本质是对不可靠网络环境的系统性防御：

• 三次握手，以最小成本建立了双向的、可靠的通信信道。
• 四次挥手，优雅地处理了全双工通道两个方向的独立关闭。
• TIME_WAIT状态，作为连接终止的守护者，确保了关闭的可靠性，并为后续连接清扫了网络残留报文。

深入理解这些机制背后的原理，将使你在面对网络问题排查、系统调优或技术面试时，能够从协议层面进行推理，而不仅仅是复述概念。