TCP 三次握手与 SYN Flood：连接队列怎么被打满

新连接连不上，先看队列再看 CPU。端口在监听、CPU 不高，连接照样进不来——多数是两个内核队列之一满了。

现象：端口活着，连接进不来

ss -lnt 显示监听还在，top 里 CPU 不到两成，客户端却一直超时。重启好一阵又复发。共同点：服务端没拒绝，只是没来得及接下。

三次握手，每一步在确认什么

SYN：客户端发出自己的初始序列号 x。服务端确认"对方能发、自己能收"。
SYN+ACK：服务端回自己的序列号 y，并确认 x+1。客户端确认"对方能发、我能收"。
ACK：客户端确认 y+1。服务端确认"对方能收"。

三步确认的不是"端口开着"，是双方收发能力与序列号。服务端收到 SYN 就要为它分配半连接条目，不等握手完成——这是队列问题的起点。

两个队列，和一个容易混的 backlog

阶段	内核状态	队列	上限
收到 SYN、已回 SYN+ACK	SYN_RECV	半连接队列	`tcp_max_syn_backlog`
收到最后一个 ACK、等应用 accept	ESTABLISHED	全连接队列	`min(backlog, somaxconn)`

backlog 不是"两个队列的总长度"。它是 listen() 传入的数字，Linux 上只约束全连接队列；somaxconn 是系统级上限，两者取小；半连接队列另有参数，三者不是一回事。

全连接队列满了，内核默认丢弃最后一个 ACK：客户端以为连接已建立，到第一次读写才报错。现象常是"握手像成功，一用就卡"，比直接拒绝难查。

SYN Flood 打的是半连接队列

半连接条目正常等最后一个 ACK 释放，等不到就靠 SYN+ACK 重试超时释放。持续发 SYN、不回 ACK，每个 SYN 占一个条目；满了就丢新 SYN，真实用户走到第二步没了下文。

打的是队列，不是端口。 端口一直 listen，CPU 不高——内核只是在丢包，不处理业务。

怎么看：三条命令

BASH

# 总体状态分布：estab / timewait
ss -s
# 内核计数：丢 SYN、队列溢出
netstat -s | grep -E "SYNs to LISTEN|overflowed|failed"
# 监听套接字：Recv-Q 当前长度，Send-Q 上限
ss -lnt

TEXT

TCP:   1204 (estab 88, timewait 1002)
LISTEN 200    200    0.0.0.0:8080

监听套接字上 Recv-Q 不是"待读数据"，是当前全连接队列长度；Send-Q 是上限。两者贴住即 accept 太慢。

判据：Recv-Q 接近 0、SYN 丢包计数涨，是半连接队列；Recv-Q 贴住 Send-Q、溢出计数涨，是全连接队列。

常见形态：CPU 15%，某端口 Recv-Q 200、Send-Q 200，overflowed 持续涨。根因在业务：accept 后同步调了慢下游。先把 accept 循环拆出来单独跑，或临时调大 backlog 顶住，再修慢调用。

只盯 CPU 会走错方向，CPU 100% 排查是另一类问题。

防御：分层，不是单点

四条，从内核到入口：

SYN cookies：tcp_syncookies=1，队列满时不再分配条目，把状态编码进序列号。代价是该连接的部分选项（窗口缩放、SACK、时间戳）无法协商。
调大队列：tcp_max_syn_backlog、somaxconn、listen() 的 backlog 一起调，只改一个没用。
缩短重试：tcp_synack_retries 由默认 5 降到 2，占用时间从约一分钟到几秒。
入口侧限速与清洗：按源限 SYN，或在负载层、清洗中心拦。单机只能被动应对。

BASH

sysctl -w net.ipv4.tcp_syncookies=1
sysctl -w net.ipv4.tcp_max_syn_backlog=1024
sysctl -w net.ipv4.tcp_synack_retries=2
sysctl -w net.core.somaxconn=1024

队列属内核排队，往上还有进程与 fd 限制：操作系统底层；应用层 accept 与线程池排队见组件解析。

队列满不是"被打"，是"接不下"。 最硬的判据：丢 SYN 还是 ACK。前者是半连接队列，后者是全连接队列，修法完全不同。

本文仅用于安全学习与授权环境下的测试。文中所有示例均为本地或授权靶场环境，不构成对任何真实系统的测试指引。

仅限授权测试，严禁非法滥用。