在TCP三次握手过程中,“第二次握手”是指服务器对客户端发起的连接请求作出响应的步骤

发布时间:2026/6/2 3:06:21

在TCP三次握手过程中,“第二次握手”是指服务器对客户端发起的连接请求作出响应的步骤 在TCP三次握手过程中“第二次握手”是指服务器对客户端发起的连接请求作出响应的步骤。具体来说客户端首先发送一个SYNSynchronize报文第一次握手其中包含初始序列号ISN表示“我想建立连接”。服务器收到SYN后回复一个SYNACK报文第二次握手ACKAcknowledgment确认号 客户端SYN中的序列号 1表示“我收到了你的SYN”SYN同时携带自己的初始序列号服务器的ISN表示“我也准备好了这是我的起始序号”。此报文标志位中SYN1、ACK1是同步与确认的合并响应。这一步完成后服务器进入 SYN_RCVD 状态等待客户端的最终确认。客户端 → 服务器SYN (seqx) // 第一次握手 服务器 → 客户端SYNACK (seqy, ackx1) // 第二次握手 ✅ 客户端 → 服务器ACK (seqx1, acky1) // 第三次握手注意SYN 和 ACK 都是 TCP 头部中的控制标志位SYN 报文虽不携带应用层数据但仍消耗一个序列号即SYN占用1字节序号空间。TCP三次握手不能简化为两次握手根本原因在于无法在不可靠的网络中可靠地同步双方的初始序列号ISN并防止历史重复连接old duplicate connection的干扰。两次握手会导致以下关键问题❌ 主要问题无法防止“失效的旧SYN”引发错误连接即“迷途重复连接”问题假设客户端发送SYNseqx建立连接但该SYN在网络中严重延迟未被服务器及时响应或丢弃客户端超时重传新SYNseqx’成功完成两次握手客户端→SYN服务器→SYNACK连接建立并通信后关闭此时滞留的旧SYNseqx突然到达服务器——若仅两次握手服务器收到后会直接回复SYNACKackx1并认为新连接已建立进入ESTABLISHED状态但客户端并未发起该连接且不期望此响应不会发送ACK也不会处理后续数据而服务器却维持半打开/错误连接浪费资源甚至可能误收后续伪造数据。✅ 三次握手通过客户端最终确认第三次ACK强制要求“只有当我明确收到了你的SYNACK并确认你的ISNy后我才发ACK否则这个连接不成立。”这确保了双方都确认了对方的初始序列号客户端知悉服务器ISNy服务器知悉客户端ISNx客户端对服务器SYN的显式应答可过滤掉因网络延迟导致的旧SYN重放服务器必须等到客户端ACK才进入ESTABLISHED状态避免单方面维持无效连接。 补充两次握手还无法解决“双方同时发起连接”simultaneous open的协调问题虽少见但协议需健壮支持两次握手❌ 不安全 Client → SYN (seqx) Server → SYNACK (seqy, ackx1) → 连接即建立 → 但若此SYNACK丢失或旧SYN迟到服务器已“自以为连接就绪”而客户端一无所知。 三次握手✅ 安全 Client → SYN (seqx) Server → SYNACK (seqy, ackx1) Client → ACK (seqx1, acky1) ← 关键只有此时双方才真正同步并就绪。因此三次握手是保证连接可靠性、安全性与状态一致性的最小必要机制。

相关新闻