什么是 TCP 三次握手？为什么必须是三次而不是两次？

腾势第九

前言

      只要你上网，浏览器访问网页、视频通话、接口请求，底层都会经历 TCP 三次握手。很多人背过这个名词，但很少想明白一个问题：建立网络连接，为什么偏偏是三次数据包交互，不用两次，也不用四次？
      三次握手并不是协议设计者拍脑袋定出来的规则，而是在复杂、不稳定的互联网环境下，用最小网络开销，完成双向通信校验、同步序列号，同时规避老旧滞留报文带来资源浪费的一套精巧设计。本文用通俗比喻结合协议状态机，把三次握手完整讲透，同时延伸讲解 SYN 泛洪攻击的原理。

TCP 协议与三次握手的核心目标

TCP 是面向连接的可靠传输协议。和 UDP 只管发送、不管对方收没收到不一样，TCP 在正式传输业务数据前，必须先在客户端与服务器之间建立逻辑连接。类比打电话：拨通之后，双方先要确认线路通畅，确认对方能听见自己说话，才开始正式对话。这个确认连接的过程，就是三次握手。
三次握手要完成两件核心任务：

• 验证双方发送、接收能力均正常，确认双向通路可用；
• 同步双方初始序列号 ISN。序列号相当于数据包的 “快递单号”，接收方依靠序列号识别丢包、重复包，保证数据不乱序、不丢失，是 TCP 可靠传输的基础。
  

SYN：Synchronize，同步；ACK：Acknowledgement，确认应答。SYN 报文会占用一个序列号，普通 ACK 报文不占用序列号。

三次握手完整交互流程

假设客户端随机初始序列号为x，服务器随机初始序列号为y。

• 第一次握手（客户端 → 服务器：SYN 报文）客户端向服务器发送SYN包，携带自己的初始序列号x。
  

通俗理解：客户端喊话：“你好，我想要建立连接，我的数据编号从 x 开始。”状态变化：客户端从 CLOSED → SYN_SENT，等待服务器回复。

• 第二次握手（服务器 → 客户端：SYN+ACK 报文）服务器处于监听LISTEN状态，收到 SYN 报文，如果允许建立连接，返回同时携带SYN与ACK的报文。
  

• ACK 确认号填x+1：告诉客户端 “你的请求我收到了”；
• 同时带上服务器自身的初始序列号y。
  

通俗理解：服务器回复：“收到你的请求，我这边准备好了，我的编号从 y 开始，请确认收到我的消息。”状态变化：服务器从LISTEN → SYN_RCVD（半连接状态，存入半连接队列，等待客户端最后一次 ACK）。

• 第三次握手（客户端 → 服务器：ACK 报文）客户端收到SYN+ACK，校验确认号无误，发送纯ACK报文，确认号填写y+1。
  

通俗理解：客户端回复：“你的消息我收到了，编号 y 我已记录。”状态变化：客户端变为ESTABLISHED；服务器收到这条 ACK 后，也切换到ESTABLISHED状态。✅至此握手完成，可以正式传输业务数据。

关键点：服务器的同步请求（SYN）和确认应答（ACK）可以合并到同一个报文，因此不需要四次交互腾讯云。

为什么是三次？两次握手会有什么问题？

很多面试会问到这个经典问题，主要有两大核心原因，来自 RFC793 协议文档定义CSDN博...。
1. 防止历史滞留报文造成无效连接，浪费服务器资源

网络是不可靠的，数据包会出现延迟、拥堵。场景举例：

• 客户端发出第一个 SYN 请求，数据包在网络中堵塞，迟迟没有抵达服务器；
• 客户端超时收不到回复，重新发送一份新的 SYN 报文，这次两次握手顺利完成，传输完毕，连接正常关闭；
• 过了很久，最早那份迟到的旧 SYN 报文终于到达服务器。
  

如果只有两次握手：服务器收到旧 SYN，直接就建立连接，分配内存资源，静静等待客户端发数据。但这个客户端早就关闭连接了，服务器白白维护一条无效连接，造成资源浪费。
有第三次握手的情况下：即便服务器收到旧 SYN 并回复 SYN+ACK，客户端识别出这是过期的旧连接，不会回复最后的 ACK。服务器收不到 ACK，不会把这条半连接转为正式连接，超时后自动释放资源，规避问题。
2. 完整验证双向收发能力

• 第一次握手：只能证明客户端发得出去；
• 第二次握手：证明服务器收得到，服务器也发得出去；
• 第三次握手：证明客户端可以正常接收服务器的报文。
  

假设网络出现单向故障：客户端可以发包，但是收不到服务器返回的数据。如果没有第三次握手校验，两次握手完成服务器就会开始发送数据，数据包全部石沉大海，业务完全无法通信。三次握手把双向通路全部确认完毕。

那为什么不用四次握手？理论上可以，但是服务器的 SYN 和 ACK 可以合并为一个包，拆成四次只会多一次网络往返，增加延迟，不会带来额外可靠性收益，三次是兼顾性能与可靠性的最小方案。

TCP 握手状态机，排查网络故障的依据

理解握手的状态流转，在排查网络异常、连接超时、攻击现象时非常实用：

角色	状态流转
客户端	CLOSED → SYN_SENT → ESTABLISHED
服务端	CLOSED → LISTEN → SYN_RCVD → ESTABLISHED

• SYN_SENT：客户端已经发出 SYN，等待服务器响应；
• SYN_RCVD：服务器收到 SYN，返回 SYN+ACK，等待客户端最后的 ACK（半连接）；
• ESTABLISHED：连接建立成功，可以收发数据。
  

如果服务器监控看到大量SYN_RCVD状态，就要警惕是否遭遇到 SYN 泛洪攻击。

SYN 泛洪（SYN Flood）攻击：利用三次握手的漏洞

攻击原理

SYN 泛洪是经典 DDoS 攻击，专门利用三次握手半连接机制实现攻击：

• 攻击者构造大量伪造源 IP 地址的 SYN 报文，疯狂发给目标服务器；
• 服务器收到每一个 SYN，都会回复SYN+ACK，把连接存入半连接队列，等待第三次 ACK；
• 源 IP 是伪造的，攻击者永远不会返回最后的 ACK 报文；
• 半连接队列存在上限，大量无效半连接占满队列之后，服务器再也无法接收正常用户的连接请求，合法业务直接拒绝服务。
  

攻击者不需要很大带宽，就可以耗尽服务器内存与连接资源，实现服务瘫痪。
常见防护手段

• 启用 SYN Cookies：半连接队列满的时候，服务器不再存储半连接状态，通过哈希计算生成特殊序列号放在 SYN‑ACK。合法客户端回传 ACK 时，服务器校验哈希，校验通过才正式创建连接，不存储大量半连接状态，是内核层面最常用手段。
• 调优 Linux 内核参数：调大tcp_max_syn_backlog半连接队列大小，缩短半连接超时时间。
• 防火墙 / 云高防、CDN 流量清洗：在到达业务服务器之前清洗恶意 SYN 报文，在架构层面抵御大流量攻击。
• 限制单 IP 短时间内 SYN 请求频次，拦截异常访问。
  

写在最后

每一次浏览器打开网页，每一次 APP 接口调用，在真正拿到 HTTP 数据之前，底层都默默完成这套三次握手。它不是死记硬背的面试考点，而是在不可靠网络上实现可靠通信的精妙设计。
简单回顾：

• 第一次握手：客户端发出连接请求 SYN；
• 第二次握手：服务器确认收到请求，同时发出自己的同步请求 SYN+ACK；
• 第三次握手：客户端确认服务器的应答，双方正式进入通信状态。
  

三次握手核心价值：校验双向收发通路、同步双方序列号、过滤网络中滞留的历史旧报文，用最少的报文交互，完成 TCP 连接初始化。