作为网络从业者，几乎每天都要和 TCP 打交道，而三次握手就是 TCP 真正开始工作的第一步。很多人面试时背得出 SYN、SYN+ACK、ACK，但真到了排查问题的时候，看着抓包文件却说不清哪个包是重传、哪个包是异常，半连接队列溢出时也不知道从哪儿入手。这篇内容我打算抛开教科书的干巴巴描述，从协议设计的角度拆开三次握手，再结合真实场景聊一聊它到底是怎么工作的、常见故障长什么样、怎么通过现象反推根因。不管你是刚入门的小白，还是被线上问题折腾过的开发者，这篇都能给你一些平时文档上看不到的细节。
先说清楚这篇要覆盖什么：三次握手的设计动机、每个报文段的含义、状态迁移的完整路径、SYN Flood 的原理与防护、实战中的抓包分析方法，以及一些容易混淆的边缘场景。我会尽量用讲人话的方式，把每一步背后的“为什么”讲透。
1. 三次握手到底在解决什么问题
1.1 为什么不是两次或四次
很多人第一次学 TCP 都会问：为什么双方确认一下不就行了？有必要这么麻烦吗？要回答这个问题，得先想清楚 TCP 建立连接的本质目标是什么。
TCP 提供的是可靠的、双向的字节流传输。在发送任何用户数据之前，双方需要达成三个共识：第一，确认对方确实在线并能收发数据；第二，协商初始序列号，让后续数据能按序拼接；第三，明确双方各自的接收窗口、最大报文段等能力参数。三次握手就是最低成本达成这三个共识的方式。
我们来推演一下如果只有两次握手会怎样。假设客户端发送 SYN，服务端回复 SYN+ACK，然后服务端就认为连接建立成功，开始发送数据。问题出在旧报文段的干扰上：如果网络中有一个迟到的 SYN 报文段，它来自之前已经结束的一次连接，服务端收到后误以为是新连接请求，就会回复 SYN+ACK 并进入 ESTABLISHED 状态，开始为这个“幽灵连接”分配资源。客户端收到这个 SYN+ACK 后发现这个序列号并不是自己当前期望的，会直接回复 RST 将其断开，但服务端在此之前已经白白浪费了资源，并且还可能向客户端发送多余的数据。
三次握手的第三步就解决了这个问题：客户端在收到服务端的 SYN+ACK 之后，会再发送一个 ACK，服务端收到这个 ACK 才正式进入 ESTABLISHED。这样一来，服务端只有在确认客户端确实收到了自己的 SYN+ACK、并且这个客户端就是发起连接的那个客户端之后，才会建立连接。如果前面那个“幽灵连接”场景发生，客户端会直接回 RST 而不是 ACK，服务端也就能立刻清理资源。
那为什么不是四次呢？因为三次已经能让双方各自确认“我能发、你能收、你能发、我能收”。具体来说：第一次握手后，服务端知道了客户端能发；第二次握手后，客户端知道了服务端能收能发；第三次握手后，服务端知道了客户端能收。这一步到位，没有必要再增加一次纯粹为了对称而对称的交互。
1.2 序列号的起点不是 0 而是随机的
三次握手过程中，双方会各自交换一个初始序列号（ISN，Initial Sequence Number）。现代操作系统并不会简单地从 0 开始，而是采用一个随时间变化的、带有随机抖动的数值。
我经常看到有初学者抓包时疑惑：为什么第一个 SYN 包的 Sequence Number 不是 0，而是像 2750146098 这种大得吓人的数字？这是因为如果 ISN 可预测，攻击者就可以通过伪造成已知序列号的报文段来注入数据，这被称为 TCP 序列号预测攻击。老的实现中 ISN 由定时器递增，很容易被猜出规律，后来协议规范要求 ISN 必须随机化。
换一个更生活化的角度来理解：序列号相当于字节流的“编号地址”。如果连接建立后要发送 1500 字节的数据，这 1500 字节会按顺序占用了 ISN+1 到 ISN+1500 这些编号。接收方就是靠这些编号来拼接乱序到达的数据段、剔除重复段、判断哪些段丢了需要重传的。随机化 ISN 不仅是为了防攻击，也是为了让新旧连接之间留有足够大的序列号空间差，减少序列号重用时产生混乱的概率。
2. 三次握手的过程拆解与状态变迁
2.1 三组报文段逐包解读
我们以最常见的场景为例：客户端主动连接服务端，端口分别是 49152 和 80。用抓包工具看，整个过程就是三个包。
第一个包是客户端发出的 SYN。标志位只有 SYN 置 1，序列号为客户端随机生成的 ISN_c，确认号 Acknowledgment Number 为 0。这个包到达服务端时，服务端的 TCP 协议栈会分配一个传输控制块，并把连接状态从 LISTEN 置为 SYN_RCVD。
第二个包是服务端发出的 SYN+ACK。它的序列号是服务端自己的 ISN_s，确认号是 ISN_c + 1，表示“我收到了你的 SYN，并且你的序列号有效”。注意，这里的 +1 是因为 SYN 报文本省并不携带用户数据，但在序列号空间中它要占一个序号，所以确认号必须加 1。
第三个包是客户端发出的 ACK。序列号变成 ISN_c + 1，确认号变成 ISN_s + 1，表示“我收到了你的 SYN+ACK”。这个 ACK 不携带任何应用数据，可以理解为一次纯控制层面的确认。服务端收到这个 ACK 后，将状态置为 ESTABLISHED，客户端实际上在发出这个 ACK 后就会立即进入 ESTABLISHED。
从序列号的角度看，三次握手完成了两个独立的序列号同步：客户端把自己的 ISN 同步给了服务端，服务端也把自己的 ISN 同步给了客户端，最后通过那个 ACK 让双方都确认同步完成。
2.2 状态机里容易被忽略的细节
Linux 下用 ss 或者 netstat 看连接，你会发现正常建立的连接除了 ESTABLISHED，还有一个常见的状态是 SYN_SENT（客户端刚发出 SYN）、SYN_RCVD（服务端收到 SYN）。如果连接没有正常完成，你还会看到 SYN_RECV 堆积、SYN_SENT 长期不消失等异常现象。
有一个状态容易被忽略：服务端在发送 SYN+ACK 后，如果迟迟收不到客户端的 ACK，会进行 SYN+ACK 重传。默认情况下，Linux 会在 1 秒、3 秒、6 秒、12 秒、24 秒等时间点重传，超过 tcp_synack_retries 配置的次数后，就放弃并释放资源。这个重传过程是一个隐藏的时间成本，很多人排查“连接慢”的问题时，最后发现是 SYN+ACK 丢了，客户端被迫重传 SYN，或者服务端在反复重传 SYN+ACK。
还有一个细节：客户端在发送 SYN 之后，如果 SYN 丢了，客户端会重传 SYN，重传间隔由 tcp_syn_retries 控制。默认通常是 6 次，初始超时 1 秒，等比退避，总耗时可达 127 秒。所以如果服务端根本不回包，客户端的日志里常见现象是“connect timeout”，而不是直接报错。
为了让大家一眼看清状态变化，这里整理一个简易对照表：
| 阶段 | 发送方 | 报文段类型 | 发送后状态（发送方） | 接收方收到后状态 |
|---|---|---|---|---|
| 第一次握手 | 客户端 | SYN | SYN_SENT | 服务端 LISTEN -> SYN_RCVD |
| 第二次握手 | 服务端 | SYN+ACK | SYN_RCVD | 客户端 SYN_SENT -> ESTABLISHED |
| 第三次握手 | 客户端 | ACK | ESTABLISHED | 服务端 SYN_RCVD -> ESTABLISHED |
这里有个很多人会记错的地方：客户端在发出第三个 ACK 后进入 ESTABLISHED，服务端在收到第三个 ACK 后才进入 ESTABLISHED。也就是说，客户端比服务端“先认为自己建立成功了”一个网络往返的时间。在某些超高并发场景下，这个时间差会导致服务端瞬时积压大量处于 SYN_RCVD 状态的半连接。
3. 三次握手相关的故障排查与防护
3.1 半连接队列与 SYN Flood
服务端收到 SYN 但还没收到最终 ACK 时，连接处于 SYN_RCVD 状态，这个状态的连接会挂在一个半连接队列里。Linux 下这个队列的容量由 tcp_max_syn_backlog 或者较新内核的 SYN queue 机制管理，具体取决于 socket 的 backlog 和 sysctl 配置。
当攻击者伪造海量源地址发送 SYN 报文时，服务端会为每个 SYN 创建半连接，迅速打满半连接队列。队列满了之后，新的 SYN 请求会被直接丢弃，正常用户的连接也就无法建立了。这就是经典的 SYN Flood 攻击。
很多人以为 SYN Flood 只是把带宽打满，其实它是一个典型的“资源耗尽型”攻击。每个半连接都要占用内核内存中的一块传输控制块，即便每个只占几 KB，百万级别的半连接也能把内存耗尽。更麻烦的是，服务端会因为不断重传 SYN+ACK 而消耗额外的 CPU 和网络输出能力。
针对 SYN Flood，传统且有效的两个方向是优化内核参数和启用 SYN Cookies。优化内核参数的核心思路是两点：增大半连接队列容量、加快半连接超时回收。你可以调整 tcp_max_syn_backlog、tcp_synack_retries 把重传次数调低，让无效的半连接更快被清理。SYN Cookies 则是另一种思路：服务端收到 SYN 时并不分配完整传输控制块，而是通过一种算法将连接信息编码到 SYN+ACK 的序号中；等收到客户端的 ACK 后，再验证 ACK 中携带的确认号是否匹配，如果匹配才分配资源建立连接。这样一来，攻击者发一百万次 SYN，服务端也几乎不需要消耗内存来存储对应的状态。
关于 SYN Cookies 必须提醒一句：它牺牲了一部分 TCP 特性。比如不支持大的 TCP 选项如窗口缩放，有些实现下也不支持 SACK。所以 SYN Cookies 更适合作为攻击时的一种降级保护，而不是默认开启的常规配置。
3.2 握手过程中的常见异常现象归纳
我把平时排查中高频出现的握手异常整理成了一张速查表：
| 现象 | 可能原因 | 排查思路 |
|---|---|---|
| 客户端 connect 卡住，最终 timeout | SYN 被防火墙丢弃；SYN 到达服务端但 SYN+ACK 被丢弃；服务端半连接队列满 | 两端同时抓包，确认包到底走到哪一跳后消失；检查 iptables/firewalld； ss -s 查看半连接数 |
| 服务端大量 SYN_RECV 连接 | SYN Flood；客户端异常不回 ACK；SYN+ACK 出网被丢 | 查看 netstat 统计，确认 SYN_RECV 是否持续增长；结合流量特征判断是否攻击；检查安全组规则 |
| 客户端 connect 返回 Connection refused | 服务端端口未监听；防火墙回复 RST；SYN 到达了没有监听应用的端口 | 服务端 ss -lnt 确认监听状态；抓包看是否有 RST 回包 |
| connect 返回 No buffer space available | 本地端口耗尽或 SYN 发送缓冲区满 | 检查客户端本地端口范围、TIME_WAIT 连接数、文件描述符数 |
| 三次握手完成但应用层无响应 | 服务端应用阻塞，协议栈已完成连接但进程未 accept | 服务端看 ESTABLISHED 状态数量、应用日志、线程数、连接 backlog 队列 |
实际排查时最忌讳只盯着一端看。我遇到过好几次这样的情况：客户端一直超时，客户端抓包能看到 SYN 发出但没有任何响应，网络同事以为是服务端的问题，结果服务端抓包发现根本没收到 SYN，最后定位到是中间防火墙做了策略丢弃。所以任何时候都要“两端对抓”，再对比中间设备的会话表，才能精准判断丢包位置。
3.3 针对握手的隐藏陷阱：安全组与 TCP 选项
有一些干扰三次握手的因素不是协议本身，而是网络设备或者系统配置。比如安全组里只放行了源端口 80/443，却没有放行临时端口，导致 SYN+ACK 回不来；又比如 MTU 不一致导致 SYN+ACK 分片丢失；或者 TCP 的 MSS 协商不一致，握手都成功了但传大包时又持续丢包。
MSS 协商值得单独讲一下。三次握手时，双方都会在 SYN 报文里携带 MSS 选项，告诉对方“我这边能接收的最大报文段是多少”。通常是 1460，即 1500 的 MTU 减去 20 字节 IP 头、20 字节 TCP 头。如果中间隧道封装导致有效 MTU 变小，而双端又没有正确协商出更小的 MSS，那么握手结束后传输大包就可能出现 IP 分片，分片丢失会导致重传，效率急转直下。
另外，有些安全设备会干扰 TCP 选项。比如有的防火墙会把 SYN 中的 SACK 选项去掉，如果服务端开启 SACK 而客户端没有收到 SACK 能力声明，传输过程中收到乱序数据后只能依赖基础的重传机制，性能会有明显下降。这类问题在抓包时很容易被忽略，因为三次握手本身是成功的，你只有仔细展开 TCP Options 里的每一个字段，才能发现能力协商出现了不对称。
4. 三次握手的抓包实战解析
4.1 用 tcpdump 抓一次完整握手并看懂包内容
理论上讲一百遍，不如自己抓一次包。无论是物理服务器、虚拟机还是本机，都可以用 tcpdump 抓取 loopback 或者业务网卡的流量。最简单的命令是：
tcpdump -i eth0 -nn 'tcp port 80 and tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0' -c 20这个过滤表达式会抓取 TCP 端口为 80 的、带 SYN、FIN 或 RST 标志位的包。如果只是做实验，也可以更直接：
tcpdump -i any -nn 'host 目标IP and tcp port 80'抓完保存成文件之后，用 Wireshark 打开分析会更直观：
tcpdump -i eth0 -nn -w /tmp/handshake.pcap 'tcp port 80'在 Wireshark 里找到三次握手的三个包，重点看几个字段：
- Sequence Number：SYN 包里面是 ISN_c，ACK 包里面是 ISN_c+1。
- Acknowledgment Number：SYN+ACK 包是 ISN_c+1，ACK 包是 ISN_s+1。
- Flags：第一包只有 SYN，第二包 SYN+ACK，第三包只有 ACK。
如果能看到一个奇怪的“TCP Retransmission”出现在 SYN 包上，说明第一个 SYN 包被丢了或者响应太慢。如果能看到“TCP Dup ACK”在握手之前出现，那就说明有更底层的乱序问题。
4.2 用日志和内核统计反推握手问题
有时候我们不能在生产环境随便抓包，那就需要用系统提供的计数器来辅助判断。Linux 下有几个特别好用的观测点：
# 查看网络统计信息 netstat -s | grep -E "SYN|listen|drop|timeout" # 查看当前各状态连接数 ss -s # 查看半连接队列溢出计数 nstat -az | grep -i syn # 查看接口层丢包 ethtool -S eth0 | grep -i drop比如 nstat 输出中的 TcpExtListenDrops 如果持续不为 0，说明有入站连接在监听队列中被动丢弃，可能是因为 accept 队列满，也可能是因为半连接队列满。TcpExtSyncookiesSent 如果快速增长，说明系统已经开启了 SYN Cookies 并正在启用它应对异常负载。TcpExtTCPTimeouts 增加，则说明有大量的重传超时，可能是网络丢包也可能是拥塞。
这里有一个经验：如果服务端 CPU 和带宽都正常，但用户反馈连接时好时坏，多半不是网络问题，而是 accept 队列溢出了。应用层处理请求太慢，来不及调用 accept，内核里的完整连接队列堆满，新完成三次握手的连接就无法进入队列，最终被内核悄然丢弃。这种情况看抓包非常迷惑：三次握手在协议栈层面确实完成了，但应用层体验就是连不上。解决方向是优化应用的处理能力和异步 accept 模型，而不是调整网络参数。
5. 三次握手与常见面试题、性能优化边界
5.1 高频面试题的另类解答
这些年我面试过不少候选人，发现有三道关于握手的题出镜率最高。第一道是“为什么是三次而不是两次”，前面已经详细分析过，这里再补一个更精炼的表述：两次握手无法防止历史重复 SYN 对服务端造成资源浪费，也无法让服务端确认客户端具备接收能力；三次握手则通过一次额外的 ACK 让服务端确认“客户端确实收到了我的 SYN+ACK”。
第二道是“SYN Flood 的原理与防御”。原理上要讲清楚攻击者不响应 SYN+ACK，导致服务端积累大量半连接；防御则可从内核参数调优、SYN Cookies、防火墙异常流量清洗、负载均衡层卸载 TCP 握手等角度回答。我特别建议补充实际调过的参数值，而不是只背概念。
第三道是“TCP 握手的第三次 ACK 丢失会怎样”。很多人会说“连接建立失败”，其实不完全正确。如果第三个 ACK 丢失，服务端不会进入 ESTABLISHED，而是停留在 SYN_RCVD，并继续重传 SYN+ACK。此时客户端已经认为自己连接成功了，甚至可能已经开始发送数据。当服务端重传的 SYN+ACK 到达客户端后，客户端会回复一个新的 ACK（因为它的 TCP 状态机认为连接已建立），这个 ACK 能让服务端完成状态迁移，后续数据仍可正常传输。所以第三次 ACK 丢失并不一定导致连接失败，而是可能增加一次往返延迟和一次无谓的重传。
这一类边界问题的价值在于，它能帮你把状态机真正理解透，而不是只背结论。
5.2 握手过程与性能调优的临界点
三次握手占用的时间通常只有 1 个 RTT，但在跨地域、高延迟链路上，这个时间会被放大。比如客户端和服务器相隔 200ms 的跨洋链路，三次握手要两个 RTT，也就是 400ms，这还没算 TLS 握手的时间。对于大量短连接场景，握手成本非常可观。
调优的方向有几个。第一个方向是尽量减少握手次数，最有效的手段是启用连接复用，比如 HTTP 的 Keep-Alive 或者连接池，让一条 TCP 连接上跑多个请求。第二个方向是调整内核参数，让握手更快失败或更快重传。例如把 tcp_syn_retries 从默认的 6 调低到 3，客户端对不可达服务端的失败检测会快很多。第三个方向是如果并发规模极大，可以考虑把 TCP 握手卸载到负载均衡器或专用的加速设备上，由这些前置设备代替后端完成握手，后端只接收已经建立的连接。
有一次压测，我发现服务端吞吐量上不去，用 perf 分析后发现内核软中断全在处理握手包。后来换成四层负载均衡做 TCP 卸载，后端只保留一个持续连接池，吞吐量立刻翻了近一倍。这个场景说明，三次握手虽然轻量，但在极高的新建连接速率下，对 CPU 的消耗同样不可小觑。
如果业务形态允许，还可以从 TCP Fast Open（TFO）的角度优化。TFO 允许在 SYN 中携带数据，把“握手 + 首个请求”合并到一个报文里，从而省掉至少一个 RTT 的等待时间。不过它需要客户端和服务端同时开启支持，并且要考虑攻击者滥用 TFO 的风险。这个技术目前已经被很多系统默认启用，但利用率和业务感知还不普遍，可以作为进阶优化项。
6. 一些容易踩坑的细节和我的实操心得
到这里，核心知识已经讲完，我再分享几个实际运维中容易踩坑的小经验。
第一个是关于防火墙策略的坑。很多人只放行了 TCP 端口，却忘了放行 ICMP 的“Destination Unreachable”报文，导致 MTU 发现问题时，路径上的设备无法通过 ICMP 通知发送方，数据链路就直接进入黑洞。表现为三次握手成功，但一旦传大包就卡死，非常隐蔽。排查时可以尝试两端同时执行 ping 指定包大小命令，配合 tcpdump 看是否有分片相关报文。
第二个是关于业务侧超时设置的问题。有些业务的 connect 超时设置得比系统的 SYN 重传周期还短，比如设置了 2 秒超时，而首次 SYN 重传可能发生在 1 秒后，第二次在 3 秒后。如果在 2 秒时报错，客户端会直接放弃，但服务端那边还挂着半连接，后续也未必能收到对应的 ACK。这种场景下，即使服务端一切正常，偶发的丢包也会表现为偶发的连接失败。建议把 connect 超时设到至少 3 秒，并且和重传参数对齐考虑。
第三个是关于 SYN Cookies 的测试建议。如果你想验证 SYN Flood 防护是否生效，可以用 hping3 这类工具做一次小规模模拟，但务必要在隔离环境进行，并且控制速率，避免把网络设备打挂。测试过程中重点观察 nstat 里的 TcpExtSyncookiesSent、TcpExtListenDrops 和 CPU 软中断开销，通过这些指标判断防护机制真正扛到了什么程度。
第四个经验是关于抓包的时机。生产环境通常不能随便抓包，但如果你判断问题出在握手阶段，可以精准地针对目标 IP 和端口抓几十秒，文件不会太大，也不会影响业务。关键是要把抓包结果和业务报错时间对齐，不要用“大概”“可能”的时间去对，否则很容易被无关包干扰。
我个人在实际项目中最常做的操作是：先在接入层两端同时抓包，快速判定丢包在哪一段；然后看一眼 ss -s 和 nstat 里的 SYN 相关计数器，判断是协议栈层面在丢还是网络层面在丢；最后结合应用的 accept 队列和线程数，排除应用层问题。这套流程走下来，绝大多数握手异常都能在十分钟内定位到大致方向。
三次握手不是一个孤立的、只出现在教科书里的概念。它决定了你的连接能不能建、快不快、稳不稳，也和安全防护、内核参数、中间设备、应用架构都牵连在一起。希望这篇能帮你在实际工作中少走一些弯路，遇到握手问题时有清晰的排查路径。
