网络安全 | TCP三次握手与四次挥手
引言
TCP（传输控制协议）是互联网最核心的协议之一，它提供了可靠的、面向连接的通信服务。无论是浏览网页、发送邮件还是使用即时通讯，背后都离不开TCP的握手与挥手过程。本文将用最直观的Mermaid流程图，带你彻底搞懂TCP的三次握手和四次挥手。
为什么需要三次握手？为什么是四次挥手？
在深入流程图之前，我们先理解两个核心问题：
为什么要三次握手？
- 第一次握手：客户端告诉服务端“我要连接你”
- 第二次握手：服务端回复“我收到了，你要连我吗？”
- 第三次握手：客户端回复“好的，我们开始通信吧”
三次握手最小化地保证了双方都有收发能力，同时避免了历史连接或重复连接的干扰。
如果只有两次握手，服务端无法确认客户端是否真的准备好了，可能会浪费资源。
为什么要四次挥手？
TCP连接是全双工的，双方都可以独立关闭自己的数据通道：
- 客户端说“我发完了”
- 服务端说“我知道你发完了”
- 服务端说“我也发完了”
- 客户端说“我知道你也发完了”
四次挥手确保了双方的数据都完整传输完毕，并且可以优雅关闭。
TCP三次握手流程图
三次握手详细说明
| 步骤 | 发送方向 | 报文关键信息 | 状态变化 |
|---|---|---|---|
| 1 | 客户端 → 服务端 | SYN=1, seq=x | 客户端进入SYN_SENT |
| 2 | 服务端 → 客户端 | SYN=1, ACK=1, seq=y, ack=x+1 | 服务端进入SYN_RCVD |
| 3 | 客户端 → 服务端 | ACK=1, seq=x+1, ack=y+1 | 双方进入ESTABLISHED |
seq是序列号，ack是确认号。ack = 对方seq + 1表示“我已收到你的上一个包”。
TCP四次挥手流程图
四次挥手详细说明
| 步骤 | 发送方向 | 报文关键信息 | 状态变化 |
|---|---|---|---|
| 1 | 客户端 → 服务端 | FIN=1, seq=a | 客户端进入FIN_WAIT_1 |
| 2 | 服务端 → 客户端 | ACK=1, ack=a+1 | 服务端进入CLOSE_WAIT客户端进入 FIN_WAIT_2 |
| 3 | 服务端 → 客户端 | FIN=1, seq=b | 服务端进入LAST_ACK |
| 4 | 客户端 → 服务端 | ACK=1, ack=b+1 | 客户端进入TIME_WAIT（等待2MSL）服务端进入 CLOSED |
2MSL= 2 × Maximum Segment Lifetime（报文最大生存时间），默认通常为2分钟，确保最后一个ACK能被对方收到。
常见问题
为什么连接是三次握手，关闭是四次挥手？
- 连接时，服务端的SYN和ACK可以合并成一次发送（第二步）。
- 关闭时，客户端先发出FIN表示自己不再发送数据，但服务端可能还有数据要发，所以ACK和FIN必须分开发送，因此需要四次。
为什么客户端最后要等待2MSL？
- 保证最后一个ACK能被服务端收到。如果ACK丢失，服务端会重发FIN，客户端可以再次响应。
- 防止“旧连接”的迷途报文影响新连接。
什么是半关闭状态？
- 在第一次挥手之后，客户端不再发送数据，但可以接收数据，服务端也可以继续发送数据，这就是半关闭状态（
FIN_WAIT_2）。
如果服务端同时收到多个连接请求怎么办？
- 服务端会将每个连接请求放入半连接队列（SYN队列），三次握手完成后移入全连接队列（Accept队列）。
Linux 下查看TCP状态
# 查看所有TCP连接状态netstat-ant# 查看连接状态统计ss-s# 查看某个端口的连接状态lsof-i:8080常见状态：
LISTEN：监听SYN_SENT、SYN_RCVD：握手过程中ESTABLISHED：已建立连接FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT、CLOSE_WAIT、LAST_ACK：挥手中
总结
| 对比项 | 三次握手 | 四次挥手 |
|---|---|---|
| 目的 | 建立可靠连接 | 优雅关闭连接 |
| 次数 | 3次 | 4次 |
| 能否合并包 | 可以（SYN+ACK） | 不能（ACK和FIN必须分开） |
| 关键状态 | ESTABLISHED | TIME_WAIT、CLOSE_WAIT |
| 是否必须 | 是 | 是 |