不懂 TCP 三次握手、四次挥手？面试官：回去等通知吧！

🌟 开篇：你以为你懂 TCP？其实……

来，问几个简单的问题：

1️⃣ 为什么是"三次"握手？两次不行吗？四次多余吗？

2️⃣ 为什么是"四次"挥手？两次不行吗？

3️⃣ 你知道 TCP 握手和挥手的整个流程吗？每一步到底是在干嘛吗？

如果这些问题你还不能完全确定，那你一定要继续往下看。今天用最直白、最好玩的方式，带你彻底搞懂 TCP 的握手与挥手！

🎭 场景：夜店搭讪 vs 网络连接

TCP 连接就像夜店搭讪（建立连接）和礼貌告别（断开连接）。搞不好，分分钟变成社死现场！让我们跟着小明的故事，一步步理解这个过程。

💏 第一幕：三次握手 - "搭讪的艺术"

小明在夜店看到小红，但他可不会傻傻地直接喊"做我女朋友！"（除非想被当成神经病）。他需要一个稳妥的三步走计划：

🔍 完整的三次握手过程是这样的：

图片

来看看TCP三次握手是怎么玩的：

客户端和服务器开始时都是"关门"状态（CLOSED）。这就像两个人要开始聊天：

客户端先发个招呼（SYN=1, seq=x），说"嘿，能聊聊吗？"，然后等在那里（SYN_SENT状态）。服务器这时候是准备听的状态（LISTEN 状态）。服务器收到后回应说（SYN=1, ACK=1, seq=y, ack=x+1）"好啊，我听见你了"，自己也进入等待状态（SYN_RCVD状态）。客户端最后确认一下（ACK=1, ack=y+1），相当于说"太好了，那我们开始聊吧"。这时候双方都进入了可以正常聊天的状态（ESTABLISHED状态）。

从技术角度看，这个过程不仅确认了双方都能收发数据，还完成了初始序列号的同步，建立了可靠的通信基础。

🤔 等等！为啥非要三次？两次不行吗？

🎯 原因一：建立"双向通信"（能收能发）

想象你在KTV包厢点歌：

如果只有两次对话：

你按了麦克风前台回应了但你可能没听到前台的回应结果你在那自顾自地点歌前台：？？？到底要点啥

📝 在TCP协议中，这个双向通信确认过程是这样的：

这就是TCP中的"全双工通信"建立过程：

第一次握手：客户端证明自己能发数据第二次握手：服务器证明自己能收能发数据第三次握手：客户端证明自己能收数据

就像KTV包厢的设备测试：

"喂喂？"（证明麦克风能用）"听到了，你能听到吗？"（证明音响能放，工作人员能听）"能听到！"（证明整个系统都OK）

只有这样才能确保：

客户端和服务器都能发送数据双方都能接收对方的数据通信链路是完全双向通畅的 🤔 等等！为啥非要三次握手？两次不行吗？

🔄 原因二：同步双方的序号（确认彼此的初始序列号）

如果只有两次握手：

问题：服务器不知道客户端是否真的收到了它的200

两次握手只能保证服务器收到了客户端的初始序号100但无法保证客户端收到了服务器的初始序号200双方的初始序号必须都能被对方确认，两次握手做不到这一点

所以必须要第三次握手：

就像两个人约定暗号：

小明：我用暗号100小红：收到你的100，我用暗号200小明：好，我也收到你的200了

通过三次握手：

服务器确认收到了客户端的序号客户端也确认收到了服务器的序号双方都知道对方的初始序号，可以开始可靠通信

这就是为什么必须是三次握手，因为只有这样才能确保双方的初始序号都被对方成功确认！

😱 原因三：防止过期消息（解决穿越）

如果没有第三次确认，会怎样？

服务器收到 9:00 的迟到申请回应说："好啊，我们开始聊天吧"但这时用户都聊了半小时了！服务器还傻傻地为这个旧请求准备资源结果：浪费服务器资源，还可能打断正在进行的聊天。

有了第三次握手，就不会出现这种情况：

📝 在TCP协议中，这个过程实际是这样的：

这就涉及到TCP的几个重要机制：

1.半连接队列（SYN Queue）

服务器收到SYN后，会创建一个半连接如果没收到第三次ACK，这个连接就会被丢弃避免了服务器资源被旧请求占用

2.连接超时机制

服务器会设置一个超时时间（通常是几十秒）在这个时间内没收到ACK就清理掉半连接防止半连接队列被占满

3.序列号验证

客户端收到 SYN+ACK 时会验证序列号如果是过期请求，就不会发送ACK服务器因此能识别出过期连接

这就是为什么TCP需要三次握手，而不是两次的原因：

防止历史连接的意外建立保护服务器资源不被浪费确保建立的都是有效连接

再想想上面的例子：

SYN就像小明的好友申请SYN+ACK是服务器的回应没有第三次ACK，就相当于小明没确认服务器就知道这是旧的申请，可以安全地忽略它

这个设计巧妙地解决了网络中的"延迟消息"问题，是TCP协议最精华的部分之一！

🤔 还有，为啥非要三次？四次不行吗？

让我们继续用KTV点歌的例子：

技术角度来说：

简单说：

三次刚刚好：确认双方都能收发两次不够：无法确认客户端能收四次多余：把能合并的分开了

记住：TCP设计的原则是既要保证可靠性，又要追求效率！

💡 小结

三次握手不是为了复杂，而是为了：

建立"双向通信"（双方都能收能发）同步双方的序列号（保证通信顺序）防止历史连接的意外建立（避免"延迟消息"）确保双方都准备好了才开始通信

记住：每一次握手都有它存在的道理，不是技术人员闲着没事干设计的，而是为了解决实际的网络通信问题！

🎭 第二幕：四次挥手 - "告别的艺术"

🌟 继续我们的夜店故事

还记得小明和小红吗？经过三次握手，他们已经聊得很开心了。但是夜店总要散场，到了说再见的时候。可是，体面人的告别可不是说走就走！

🎭 四次挥手是怎么回事？

分别的是时候，小明不能突然消失，得体面地说再见。我们看看这个过程：

📝 这在TCP协议中实际是这样的：

🤔 为什么要四次？两次不行吗？

想象一下这个尴尬的场景：

为什么这样不行？

小明说"我要走了"只是表示他不发消息了但小红可能还有话要说（比如发微信号）如果立即分别，小红的话就来不及说了。

技术角度来说：

所以必须要四次：

这就是为什么需要四次挥手：

让双方都能说完该说的话避免重要信息发不出去确保完整优雅地断开连接📝 深入理解四次挥手

先来看看 TCP 四次挥手的详细图解：

图片

1️⃣ 第一次挥手：主动说再见

技术视角：

客户端发送 FIN 包，序号为x进入FIN_WAIT_1状态表示客户端没有数据要发了

2️⃣ 第二次挥手：先别急

技术视角：

服务器发送ACK，序号为y，确认号为x+1进入 CLOSE_WAIT 状态，表示服务器可能还有数据要发送当客户端收到 ACK 包时，客户端进入 FIN_WAIT_2 状态

3️⃣ 第三次挥手：处理完了

技术视角：

服务器发送FIN包，序号为 z,确认号是x+1进入LAST_ACK状态表示服务器的数据也发送完毕

4️⃣ 第四次挥手：最后道别

技术视角：

客户端发送ACK，序列号为x+1，确认号为z+1进入 TIME_WAIT 状态等待 2MSL 后才真正关闭

最后，双方都进入 CLOSED 状态。

🤓 为什么要等待2MSL？

想象这个场景：

技术角度解释：

MSL是数据包的最大生存时间(一般是几十秒)等待 2MSL 是为了：确保最后的ACK能到达服务器等待可能的FIN重传防止旧连接的数据包影响新连接

旧连接的数据包影响新连接是什么意思？

让我通过一个具体的例子来解释"防止旧连接的数据包影响新连接"。

就像这样的场景：

有了2MSL等待：

简单说：

2MSL的等待就是让之前的所有互动（数据包）都完全结束，不会让旧数据包来影响新连接。💡 四次挥手的精髓

在生活中：

双方都要把话说完确保对方听到了告别给对方充足的处理时间不能突然消失

在TCP中：

确保数据完整传输双方都能正常关闭防止数据丢失资源能被正确释放

记住：四次挥手的每一步都是必要的，是为了让网络通信更可靠！

总结：

通过这篇文章，TCP的三次握手和四次挥手的来龙去脉应该都清楚了。TCP 之所以这样设计，是为了实现可靠的网络通信：三次握手确保双向通信可靠、序列号同步以及避免历史连接；四次挥手则确保数据传输完整、连接优雅关闭，以及防止旧连接影响新连接。看似繁琐的每一次握手和挥手，其实都是为了解决具体的网络通信问题，体现了 TCP 协议的可靠性和严谨性。一旦理解了这些设计背后的原因，也就理解了 TCP 协议的精髓。