解密TCP三次握手与四次挥手的秘密（程序员必看实战指南）

最新推荐文章于 2025-05-27 18:28:04 发布

「已注销」

最新推荐文章于 2025-05-27 18:28:04 发布

阅读量491

点赞数 9

文章标签： tcp/ip php 网络协议

本文链接：https://blog.csdn.net/logicloop/article/details/147523536

版权

各位老铁！今天咱们来聊聊网络世界里最经典的"相亲故事"——TCP三次握手（敲黑板！重点来了）。想象一下你的电脑要和服务器处对象，总得先确认双方都有诚意对吧？

第一次握手：客户端（小哥哥）发出SYN=1的求爱信号，附带随机序列号x（就像递出名片：“Hi小姐姐，这是我的ID”）

第二次握手：服务端（小姐姐）回SYN=1+ACK=1的响应，序列号y，确认号x+1（“收到啦_{这是我的ID，确认你在线哦}”）

第三次握手：客户端发送ACK=1，确认号y+1（“确认收到！咱们开始交往吧！”）

这里有个灵魂拷问：为什么非要三次？两次不行吗？（问得好！）假设网络延迟导致老SYN包突然复活，两次握手就会产生"僵尸连接"，就像收到前任突然发来的复合短信一样尴尬！

分手可比牵手复杂多了！来看经典的四次挥手流程：

第一次挥手：主动方发送FIN=1（“我想分手了…”）

第二次挥手：被动方回ACK（“收到分手请求”）

第三次挥手：被动方发送FIN=1（“我也想好了，同意分手”）

第四次挥手：主动方回ACK（“好的，江湖再见”）

等等！这里有个隐藏考点：为什么要有TIME_WAIT状态？（重点标记！！！）想象分手后突然收到前任的未读消息，这个2MSL等待期就是用来处理这种网络延迟的"幽灵数据包"的！

去年我在做高并发IM系统时，遇到过惊悚的CLOSE_WAIT堆积问题（后背发凉）。监控显示服务器上有10w+的CLOSE_WAIT连接！后来发现是代码里没正确关闭socket导致的——就像提了分手却堵着门不让对方离开！

解决方案：

# 错误示范（会残留CLOSE_WAIT）
sock.shutdown(socket.SHUT_WR) 

# 正确姿势（Python示例）
try:
    sock.shutdown(socket.SHUT_RDWR)
finally:
    sock.close()

上硬菜！打开Wireshark抓个HTTP请求看看（此处应有截图）：

三次握手阶段：
- [SYN] Seq=0
- [SYN, ACK] Seq=0 Ack=1
- [ACK] Seq=1 Ack=1
数据传输阶段：
- HTTP请求/响应清晰可见
四次挥手阶段：
- [FIN, ACK] Seq=1 Ack=1
- [ACK] Seq=1 Ack=2
- [FIN, ACK] Seq=1 Ack=2
- [ACK] Seq=2 Ack=2

注意看序列号的变化规律（这里藏着TCP可靠传输的魔法）！

Q：TCP为什么是可靠传输？
A：三板斧保证——顺序号确认机制、超时重传、流量控制（滑动窗口）

Q：TIME_WAIT状态过多怎么办？
A：调整内核参数（比如net.ipv4.tcp_tw_reuse），但要注意NAT环境下可能的问题

Q：SYN Flood攻击原理？
A：疯狂发送SYN包不完成握手，耗尽服务端资源（防御方案：SYN Cookie）

现代HTTPS通信要先完成TCP三次握手，再进行TLS握手（相当于相亲成功后的背景调查）。整个过程会多出2个RTT时间，这也是QUIC协议诞生的原因之一！

下次当你发送一个简单的HTTP请求时，想想背后这场精心编排的"网络交际舞"吧！理解这些底层机制，才能在出现网络问题时快速定位原因（比如突然暴增的延迟或连接失败）。记住，好的程序员不仅要会写代码，更要懂代码背后的"网络社交礼仪"！