TCP三次握手与四次挥手原理及工程实践

1. 为什么我们需要理解TCP握手与挥手

TCP协议作为互联网的基石，其连接建立与终止机制直接影响着每一个网络应用的性能表现。我曾在处理一次线上服务超时问题时，发现80%的延迟都发生在TCP连接阶段——这正是因为开发团队对三次握手机制理解不足，导致连接池配置不当。理解这些基础概念，绝非纸上谈兵。

TCP采用三次握手而非两次，核心是为了解决"历史重复连接"问题。想象这样一个场景：客户端发出的SYN包因网络拥堵延迟到达，客户端超时重发并完成通信后，那个迟到的SYN包才到达服务端。如果是两次握手，服务端会误认为这是新的连接请求，直接建立冗余连接。而第三次握手的确认机制，确保了双方对连接状态的认知绝对同步。

2. 三次握手的全流程拆解

2.1 第一次握手：SYN探针

客户端发送SYN=1的TCP报文，随机生成初始序列号seq=x（32位无符号数）。这个x的随机性至关重要——我见过某金融系统使用固定初始序列号，导致中间人攻击者能预测后续序列号。典型的Wireshark抓包显示：

code复制[TCP] Flags=SYN, Seq=0, Win=65535

关键细节：此时客户端进入SYN_SENT状态，但Linux内核实际会先发送SYN+ACK重传探测（内核参数net.ipv4.tcp_syn_retries控制重试次数）

2.2 第二次握手：SYN-ACK响应

服务端收到SYN后，构建特殊响应：

• 设置SYN=1和ACK=1
• 确认号ack=x+1
• 生成自己的初始序列号seq=y

这个ack=x+1的设计非常精妙——它既确认收到了客户端的x，又隐含要求对方下次必须从x+1开始发送数据。我曾通过这个机制诊断出某厂商设备错误实现TCP栈，其ack值总是等于x而非x+1。

2.3 第三次握手：最终确认

客户端发送ACK=1，seq=x+1，ack=y+1。注意此时已经可以携带应用层数据（开启TCP_FASTOPEN时），但多数实现仍会等待握手完成。至此双方进入ESTABLISHED状态，内核开始维护连接状态机。

3. 四次挥手的必要性解析

3.1 为什么不能三次挥手

TCP是全双工协议，每个方向都需要独立关闭。当客户端发送FIN时，仅表示"我没有数据要发了"，但可能还需要接收服务端的数据。这与握手的本质区别在于：握手是同步行为，而挥手是异步过程。

典型案例：MySQL客户端执行quit后，服务端可能还需要发送最后的OK包，此时就需要半关闭状态（FIN_WAIT_2）。过早关闭会导致数据丢失。

3.2 完整挥手流程

1. 主动方FIN：发送FIN=1，seq=u（已传送数据最后一个字节+1）
2. 被动方ACK：回复ack=u+1，此时被动方进入CLOSE_WAIT
3. 被动方FIN：处理完剩余数据后发送自己的FIN=1，seq=v
4. 主动方ACK：回复ack=v+1，进入TIME_WAIT状态

血泪教训：某电商平台曾因TIME_WAIT设置过短（net.ipv4.tcp_fin_timeout=15），导致高并发下端口耗尽。建议生产环境保持默认60秒。

4. 状态转换的工程实践

4.1 关键状态解析

• SYN_RCVD：服务端收到SYN但未完成握手。DDoS攻击常利用此状态耗尽资源，需配合syn cookies防御。
• TIME_WAIT：主动关闭方维持2MSL时长。MSL（Maximum Segment Lifetime）建议值为60秒，对应内核参数tcp_max_tw_buckets。

4.2 网络问题诊断

通过netstat -antp可观察连接状态。常见异常：

• 大量CLOSE_WAIT：应用未正确调用close()，典型资源泄漏
• 大量SYN_SENT：对端拒绝服务或防火墙拦截
• FIN_WAIT2堆积：对端未及时关闭，需检查tcp_fin_timeout

5. 协议优化与内核参数

5.1 握手加速技术

• TCP Fast Open：允许在SYN包携带数据（需设置TCP_FASTOPEN）
• SYN Cookies：防御SYN Flood攻击，通过算法计算初始序列号

5.2 关键内核参数

bash复制# 查看当前配置
sysctl -a | grep tcp

# 生产环境推荐调整（需测试）
net.ipv4.tcp_syn_retries = 3          # SYN重试次数
net.ipv4.tcp_synack_retries = 3       # SYN-ACK重试
net.ipv4.tcp_max_syn_backlog = 8192   # SYN队列长度
net.ipv4.tcp_tw_reuse = 1             # 允许TIME_WAIT复用

6. 抓包实战分析

使用tcpdump捕获握手过程：

bash复制tcpdump -i eth0 'tcp port 80 and (tcp-syn|tcp-ack)'

典型输出解读：

1. 客户端 [SYN] Seq=0
2. 服务端 [SYN, ACK] Seq=0, Ack=1
3. 客户端 [ACK] Seq=1, Ack=1

异常情况示例：

• 只有SYN没有SYN-ACK：检查防火墙规则
• SYN重传：网络延迟或对端处理能力不足

7. 常见误区澄清

误区1："ACK包不消耗序列号"
事实：纯ACK确实不递增seq，但若携带数据则需占用序列号空间。这就是为什么抓包看到的序列号可能不是连续+1。

误区2："TIME_WAIT有害应尽量减少"
真相：TIME_WAIT是TCP可靠性的重要保障。与其盲目调小，不如优化连接复用（如HTTP Keep-Alive）。

误区3："挥手必须四次"
特殊场景：当被动方没有待发数据时，其ACK和FIN可合并发送，退化为三次挥手。但这属于优化特例而非标准行为。