前言
"面试官问：TCP 为什么是三次握手，不是两次？"
"我：呃...因为...三次比较稳？"
"面试官：......"
这是很多程序员面试时的真实写照。TCP 握手协议，计算机网络面试必考题，但很多人只会背八股文，真正理解的人寥寥无几。
今天这篇文章，我用一个"网恋奔现"的故事，带你彻底搞懂 TCP 的三次握手和四次挥手。看完保证你过目不忘，面试再也不慌！
🎭 登场角色介绍
小明（客户端 Client）：一个渴望爱情的程序员，想找人聊天
小红（服务端 Server）：一位温柔的姑娘，随时等待有缘人
TCP 协议：他们之间的"恋爱规则"，确保每次对话都靠谱
💕 第一幕：三次握手 - 网恋奔现的正确姿势
场景：小明想和小红建立连接
🔴 第一次握手：小明试探
小明 → 小红：「在吗？我想和你聊天~」（SYN=1, seq=x）
小明发出消息后，心里七上八下：
- 消息能送到吗？
- 小红在不在？
- 她愿意理我吗？
此时的状态：小明（SYN_SENT），忐忑等待中...
🟡 第二次握手：小红回应
小红 → 小明：「在的！我也想和你聊~」（SYN=1, ACK=1, seq=y, ack=x+1）
这里别混淆：
SYN=1、ACK=1是两个控制标志位seq=y是小红自己的序列号ack=x+1是小红发给小明的确认号；语义上表示“小明发来的SYN(seq=x)已收到，下一步期望小明从x+1开始发送”
小红收到消息很开心，但她也需要确认：
- 我收到了你发来的
SYN - 这是我这边的初始序列号
- 但...你能不能收到我的
SYN+ACK？
此时的状态：小红（SYN_RCVD），等待小明最终确认
💡 为什么小红要同时发 SYN 和 ACK？ 因为
ACK是在确认收到小明的SYN；而SYN表示小红也要把自己的建连信息带给小明，请小明对这边进行确认。具体的小红初始序列号，体现在seq=y这个字段里。这几件事正好可以放进同一个报文里完成。
🟢 第三次握手：小明确认
小明 → 小红：「太好了，那我们开始吧！」（ACK=1, seq=x+1, ack=y+1）
这里同样别混淆：
ACK=1是确认标志位seq=x+1是小明此时发送的序列号ack=y+1是小明发给小红的确认号；语义上表示“小红发来的SYN(seq=y)已收到，下一步期望小红从y+1开始发送”
小明收到小红的回复，激动坏了！立刻确认：
- 你发来的
SYN(seq=y)我收到了 ✓ - 你的初始序列号是
y，我后面确认时按y+1来 ✓ - 我把这个确认回给你了，你也能知道我已经收到你的
SYN+ACK✓
此时的状态：双方进入（ESTABLISHED），正式开始聊天！
🤔 灵魂拷问：为什么必须是三次？
假设只有两次握手...
小明 → 小红：「在吗？」
小红 → 小明：「在的！」
然后...连接建立成功？
问题来了：
场景一：网络延迟的恶作剧
小明发了条消息，结果网络堵车，消息卡在半路。小明等不及了，放弃了。
过了很久，这条"僵尸消息"终于到了小红那里。小红一看，立马回复"在的！"
如果是两次握手，此时连接就建立了。但小明早就走了！小红傻傻地等着，浪费了宝贵的青春（服务器资源）。
把拟人化描述翻回协议语义
你这个疑问本质是在问：TCP 为什么不是“你发了我就信”，而是必须“双向确认”。
把“网恋奔现”的故事拆回协议语义，其实就清楚了。
1. 小明发消息 ≠ 小红确认“小明真的想聊”
在现实里，你会觉得：
如果不想聊，小明干嘛发消息？
但在网络里，这个逻辑并不成立。TCP 本身是可靠传输协议，但它运行在一个不保证可靠交付的网络之上。
在这个底层网络里，报文可能丢失、延迟、乱序，甚至出现重复。
TCP 正是通过序列号、确认应答、重传等机制，才把这种“不可靠的底层传输”包装成了“可靠的连接”。
TCP 设计里有个经典风险场景：
- 小明很早之前发过一次
SYN - 这个包在网络里绕了很久
- 小明后来已经不想聊了，甚至程序都关了
- 旧
SYN突然被小红收到
如果小红看到 SYN 就直接认为连接建立了，就会出现：
- 小红这边已经建好了连接
- 小明根本不知道这回事
- 两边状态不一致，服务器资源还被白白占住
所以，小红真正要确认的不是“他主观上想不想聊”，而是：
这个请求是不是当前有效的，而不是网络里迟到的历史残留。
2. 小红为什么要 ACK？
当小红回复：
SYN=1, ACK=1, seq=y, ack=x+1
她实际上同时表达了四个关键信息：
ACK=1：表示“这是一条带确认信息的报文，后面的确认号字段有效”；它说明这条报文在回应小明上一条带SYN的报文，但不是“确认号等于 1”ack=x+1：这才是具体的确认内容；表示“你发来的SYN(seq=x)我收到了，下一步我期望你从x+1开始发”SYN=1：表示这还是一条建连报文seq=y：表示“这是我这边的初始序列号，后面我发的数据从y开始编号”
但这一步最多只能证明一件事：
小明发来的请求，确实到达了小红这里。
也就是，小红确认了 小明 → 小红 这条方向这次是可达的。
3. 为什么还要第三次握手？
关键问题在于：
小红发出去的
SYN+ACK，小明到底收没收到？
如果没有第三次握手，就可能发生这种错误场景：
- 小明发
SYN - 小红回
SYN+ACK - 这个
SYN+ACK在路上丢了 - 小红却已经把连接当成建立成功
结果就是：
- 小红以为连接好了
- 小明根本没收到回复
- 双方对“连接是否建立”这件事的认知不一致
第三次握手的那个 ACK，就是小明明确告诉小红：
“你的
SYN+ACK我收到了，这次连接我还认，这不是一条过期请求。”
4. 更精确的说法
所以，“小红确认小明确实想聊”这个说法，严格一点应该改成：
小红要确认的是：这个建连请求是当前有效的，并且双方都对“连接已经建立”这件事达成了一致。
三次握手的智慧
第三次握手，就像小明最后说一句"收到了，开始吧"，让小红确信：
- 小明还在发起这次连接
- 小明能收到我的
SYN+ACK - 双方都确认“连接已经建立”
- 这不是一条过期的请求
📌 面试金句：三次握手的本质，是在不可靠网络里同步双方初始序列号，并让双方对“连接已经建立”这件事达成一致。既要防止历史报文的干扰，也要避免两端状态不一致。
💔 第二幕：四次挥手 - 分手也要有仪式感
场景：小明聊累了，想结束对话
🔴 第一次挥手：小明提出分手
小明 → 小红：「我累了，不聊了...」（FIN=1, seq=u）
小明主动提出结束，进入半关闭状态：
- 小明不会再发消息了
- 但还能接收小红的消息
此时的状态：小明（FIN_WAIT_1）
🟡 第二次挥手：小红收到
小红 → 小明：「好的，我知道了」（ACK=1, seq=v, ack=u+1）
小红收到请求，确认了。但她可能还有话要说：
- "等等，我还有个故事没讲完..."
- "明天记得按时吃饭..."
此时的状态：小明（FIN_WAIT_2），小红（CLOSE_WAIT）
🟠 第三次挥手：小红也累了
小红 → 小明：「我也说完了，拜拜~」（FIN=1, ACK=1, seq=w, ack=u+1）
小红把想说的话都说完了，也提出结束。
此时的状态：小红（LAST_ACK）
🟢 第四次挥手：小明最终确认
小明 → 小红：「拜拜，下次再聊！」（ACK=1, seq=u+1, ack=w+1）
这个 ACK 在确认什么？
是确认："我（小明）收到了你（小红）也要分手的消息"
不是确认"小红收到小明的消息"——那个在第二次挥手就确认过了。
小明发送这个 ACK 后，不会立即关闭连接，而是进入 TIME_WAIT 状态，等待 2MSL。
此时的状态：小明（TIME_WAIT）；小红收到最后的 ACK 后直接进入（CLOSED）；等 2MSL 结束后，小明也进入（CLOSED）。
💡 为什么小明发完 ACK 还不急着走？ 因为这个 ACK 可能会丢！如果丢了，小红会以为小明没收到她的 FIN，就会重发。小明如果在门口多等一会儿，还能再补一次确认。
🤔 灵魂拷问：为什么分手要四次？
为什么不能像握手那样三次？
回顾一下握手时的情况：
第二次握手：SYN + ACK 合并发送
小红在确认对方 SYN 的同时，也把自己的 SYN 一起发出去了，所以可以合并。
但挥手时不一样：
第二次挥手：只发 ACK（收到你的分手请求了）
第三次挥手：单独发 FIN（我也准备好了，可以分手）
为什么不能合并？
因为小红可能还有话要说！
想象一下：
- 小明：「我不聊了」
- 小红：「好的拜拜」← 如果这时候直接说拜拜
- 小红：「等等！我还有个重要的事...」← 惨了，已经拜拜了
TCP 是全双工通信，就像两个人同时可以说话。一方不说了，不代表另一方也没话说。
所以小红需要：
- 先确认收到分手请求（ACK）
- 把想说的话说完
- 再提出分手（FIN）
📊 总结对比：一张表搞定面试
| 项目 | 三次握手 | 四次挥手 |
|---|---|---|
| 目的 | 建立连接 | 断开连接 |
| 发起方 | 客户端 | 任意一方 |
| 步骤 | SYN → SYN+ACK → ACK | FIN → ACK → FIN → ACK |
| 能否合并 | 中间两步可以合并 | 中间两步通常不能合并 |
| 为什么 | 需要同步双方初始序列号、避免历史报文干扰、让双方建连状态一致 | 全双工，双方需分别关闭 |
🎓 面试加分项
Q1：为什么等待 2MSL？
MSL = Maximum Segment Lifetime，报文最大生存时间（一个包在网络中能存活的最长时间）。
为什么是 2 倍 MSL？
想象最坏的情况：
小明 ──── ACK ────> 小红 ← 这个 ACK 丢了！
时间线分析：
| 步骤 | 耗时 | 说明 |
|---|---|---|
| ① ACK 在路上丢了 | ≤ 1 MSL | 报文最多存活 MSL 时间 |
| ② 小红等超时，重发 FIN | — | 小红发现没收到确认 |
| ③ 重发的 FIN 到达小明 | ≤ 1 MSL | 报文最多存活 MSL 时间 |
总耗时 ≤ 2 MSL
所以：
- 如果 2MSL 内收到了 重发的 FIN → 说明 ACK 丢了，小明补发一次 ACK，重新计时
- 如果 2MSL 内没收到 → 说明 ACK 很可能安全到达了，可以放心关闭
能 100% 确定没丢吗？
不能，但 2MSL 覆盖了最坏情况。
极端情况下，如果 ACK 丢了，小红重发的 FIN 也丢了，那确实无法确认。但这种"连续两次丢包"的概率极低，网络协议设计追求的是"足够可靠"**，而不是 100% 可靠。
📌 面试金句：2MSL = ACK 丢失的最大时间 + FIN 重发的最大时间。超过这个时间，就认为报文已经"死亡"了。
MSL 是多久？
| 系统 | MSL 默认值 | 2MSL 等待时间 |
|---|---|---|
| Linux | 30 秒 | 60 秒 |
| Windows | 2 分钟 | 4 分钟 |
2MSL 的另外两个作用
- 让网络中的旧报文消失：超过 MSL 的报文会被路由器丢弃
- 防止下次连接被旧数据干扰：确保新连接不会收到上次连接的残留数据
Q2：握手时序列号有什么用？
序列号（Sequence Number）就像对话的"页码"：
- 确保消息按顺序到达
- 检测是否有消息丢失
- 去除重复的消息
Q3：SYN Flood 攻击是什么？
恶意客户端疯狂发 SYN 但不完成第三次握手，服务器堆积大量半开连接，资源被耗尽。
防御方法：SYN Cookie、调整内核参数等。
💬 结语
TCP 的三次握手和四次挥手，看似复杂，其实就是两件事：
三次握手：同步双方初始序列号，并让双方都确认"连接已经建立"
四次挥手：确保双方都"说完了"，优雅地结束对话
下次面试被问到，就讲这个网恋奔现的故事，面试官绝对印象深刻！
欢迎关注公众号 FishTech Notes，一块交流使用心得！
