为什么tcp不能两次握手

TCP **不能用“两次握手”**的根本缘故原由是：两次握手无法确保双方“都知道”毗连是可靠创建的，轻易引发“旧毗连哀求”造成错误毗连。

---

🔁 先看标准的 三次握手（3-Way Handshake）流程

2. 客户端                服务器
3.    |    SYN (seq=x)     |
4.    |------------------->|  // 客户端请求连接
5.    |                    |
6.    |   SYN+ACK (seq=y)  |
7.    |<-------------------|  // 服务器确认并响应
8.    |                    |
9.    |      ACK (ack=y+1) |
10.    |------------------->|  // 客户端确认

复制代码

寄义：

•         第一次（客户端→服务器）：哀求创建毗连，发送 SYN。
  
•         第二次（服务器→客户端）：回应哀求，发送 SYN + ACK。
  
•         第三次（客户端→服务器）：确认收到服务器回应，发送 ACK，毗连正式创建。
  

---

❌ 两次握手的标题是什么？

🧨 关键标题：服务器无法判定客户端是否“收到”自己的回应

假设两次握手：

•         客户端发送 SYN。
  
•         服务器收到 SYN，发送 SYN + ACK，并进入 ESTABLISHED 状态。
  

如果客户端此时宕机或网络壅闭，服务器以为毗连已创建，现实上客户端并不知道毗连是否乐成。此时：

•         服务器已分配资源（如线程、缓冲区）；
  
•         客户端根本没进入毗连状态；
  
•         后续的数据传输失败或被误吸收；
  
•         更严峻的是：旧的毗连哀求重传大概被误以为是新的毗连哀求（重放攻击）。
  

---

📌 举个例子（重放攻击场景）：

•         客户端 A 发送一个旧的 SYN 包滞留在网络中；
  
•         客户端 A 已关闭，但旧包现在才到服务器；
  
•         服务器收到旧 SYN，回 SYN+ACK，此时以为有毗连创建；
  
•         如果此时客户端 A 再发送一个新的毗连 SYN，大概发生肴杂；
  
•         如果 两次握手，服务器无法分辨这个毗连是“旧的”照旧“新的”。
  

所以需要 第三次握手 来确认客户端“确实收到了服务器的相应”，才正式创建毗连。

---

✅ 三次握手办理的标题

标题两次握手三次握手确保双方都预备好通讯❌ 否✅ 是防止旧毗连重复创建❌ 否✅ 是淘汰资源浪费（无效毗连）❌ 否✅ 是

---

✅ 总结

TCP 不能采取“两次握手”是由于：服务器无法确认客户端是否“收到并相应了”毗连确认，这会导致错误毗连、资源浪费，甚至安全标题。
三次握手是为了：

📌 重点：只有当客户端“真正在线并确认相应”，毗连才成立。

---

✅ 2. 三次握手同步双方的初始序列号（ISN）

🔁 三次握手时双方完成 ISN 的交换：

📌 重点：三次握手完成了“数据传输编号的出发点”同步，确保通讯有序、可靠。

---

✅ 3. 三次握手克制资源浪费（尤其在服务端）

🧱 今世 TCP 实现中也有SYN Cookie技能，用于在 ACK 前不分配毗连内存，从源头上对抗资源浪费。
📌 重点：三次握手让服务端“等你回应再正式投入资源”。

---

🔚 总结

功能三次握手如何实现✅ 克制旧毗连重放第三次 ACK 确认确保毗连奇怪有用✅ 同步双方序列号客户端和服务器各发送一个 ISN✅ 淘汰资源浪费服务端不在未确认毗连上分配大量资源
所以，三次握手不是多此一举，而是 TCP 协议实现可靠、同步、安全通讯的最小且须要步调。

•         确保可靠毗连创建；
  
•         防止因网络耽误导致的“旧毗连哀求”被误担当；
  
•         双方都确认对方已预备好通讯。
          ✅ 三次握手缘故原由
  
•         ✅ 1. 三次握手可以克制重复汗青毗连的初始化（防止重放旧毗连）
  
•         网络环境中，旧的 SYN 包大概在耽误、丢包、缓存之后再次被送达服务器。
  
•         如果是两次握手，服务器在收到 SYN 后立刻创建毗连，纵然是个“幽灵毗连”也会成立。
  
•         三次握手通过等候客户端的确认（第三次 ACK），克制了只凭 SYN 就创建毗连，有用拦截了旧毗连的重复使用（重放攻击）。
  
•         每次 TCP 毗连，客户端和服务器都要天生一个 初始序列号（ISN），用来标识和确认数据包的次序。
  
•         如果没有三次握手，服务器不知道客户端的 ISN，客户端也不知道服务器的 ISN，后续数据通讯就无法可靠确认。
  
•         第一次：客户端发送自己的 ISN；
  
•         第二次：服务器复兴自己的 ISN，并确认客户端的 ISN；
  
•         第三次：客户端确认服务器的 ISN。
  
•         服务端收到一个 SYN 后，并不会立刻分配大量资源（如线程、毗连对象），而是进入 半毗连状态（SYN_RECV）；
  
•         如果没有收到第三次 ACK，毗连不会正式创建；
  
•         如允许以防止攻击者伪造大量 SYN 包来拖垮服务器资源（也就是所谓的 SYN Flood 攻击）。