半连接队列被打满，本质上是典型的拒绝服务攻击表现，通常指向SYN Flood攻击，属于DDoS攻击中流量型攻击与协议型攻击的混合变种。当攻击者伪造海量源地址向目标服务器发送TCP SYN请求，却不完成三次握手，服务器内核协议栈的SYN队列（半连接队列）就会迅速被占满，导致正常用户的连接请求无法被受理，服务陷入瘫痪，理解这一攻击背后的机制，是对抗和防御的前提。
半连接队列被打满属于哪一类攻击表现：从TCP握手聊起
想弄清楚半连接队列被打满属于哪一类攻击表现,得先明白服务器在处理TCP连接时内部发生了什么，一次正常的TCP连接需要经历三次握手：客户端发送SYN包，服务器回复SYN+ACK，客户端再回传ACK，当服务器发送SYN+ACK之后、收到客户端ACK之前，这个连接处于“半开”状态，内核会为它分配一个条目，存放在一个专用的队列里，这个队列就是半连接队列。
这个队列的容量是有限的,由内核参数tcp_max_syn_backlog和net.core.somaxconn共同决定，当队列满时，新到的SYN包会被直接丢弃，正常情况下，客户端会在极短时间内完成最后一次ACK，半连接条目很快被释放，队列很少会满，但如果有人刻意让这个队列塞满，情况就完全不同了。
攻击者的手法：只握手不完成
攻击者利用的正是这个机制,他控制大量僵尸主机或者伪造随机IP地址，向目标服务器发送海量SYN请求，服务器按规则回复SYN+ACK后，静静地等待客户端的ACK响应但这个响应永远不会到来，由于源IP是伪造的，服务器的SYN+ACK报文发往一个根本不存在的地址，自然不会有回应。
这些半连接条目就这么兜在队列里,直到内核的SYN重传机制耗尽重试次数，才会被清理，重传等待时间往往长达30秒到1分钟，攻击者只需持续不断地发送SYN包，让新条目进入队列的速度超过超时清理的速度，队列就会被打满。新来的正常用户请求排不上队，服务器表现就是无法访问、网页卡死或连接超时。
为什么说它属于DDoS攻击
从攻击分类上看,半连接队列被打满属于哪一类攻击表现这个问题，答案非常明确：这是DDoS攻击中的SYN Flood攻击，行业里也常称之为“半连接攻击”或“泛洪攻击”。
业内专家指出,SYN Flood是历史最悠久、也最难彻底防御的攻击方式之一，早在1996年左右就被发现并利用，它不需要攻击者拥有高带宽，因为收发极小的SYN包就能造成巨大杀伤力，属于
协议漏洞型DDoS攻击，与纯粹用流量砸垮带宽的UDP Flood不同，SYN Flood消耗的是服务器自身的连接资源和协议栈处理能力，属于资源耗尽型攻击。
半连接队列被打满是什么意思：如何准确判断攻击发生
判断半连接队列是否被打满,不能靠猜，通过几个命令和系统指标，运维人员可以迅速确认攻击状态。
用系统命令查看半连接队列状态
在Linux服务器上,ss命令是排查连接状态的第一利器，执行：
ss -s
这个命令会输出当前的TCP连接统计,如果看到大量SYN-RECV状态的连接，数量远高于正常水平，基本可以确定半连接队列正遭受冲击，正常运行的服务器上，SYN-RECV状态连接数量极少或接近于零。
进一步查看具体连接来源,用：
netstat -nat | awk '{print $6}' | sort | uniq -c | sort -rn
如果SYN_RECV条目数量异常庞大，且来源IP分布杂乱无章，那就不是正常业务流量特征，而是攻击迹象。
netstat -ant | grep -i SYN_RECV | wc -l
观察业务层的异常表现
系统层面的指标之外,业务层也会出现一系列连锁反应，用户访问网站时，浏览器长时间停在“正在连接服务器”或“等待响应”的状态，最终超时失败，服务器的CPU使用率可能并不高，但应用程序日志里充斥着大量连接超时异常，如果你在nginx配置中开启了error_log，会看到类似upstream timed out的报错记录。
需要区分的是，半连接队列被打满与全连接队列（accept队列）被打满表现不同。 全连接队列满时，通常发生在高并发正常业务场景，表现为连接建立成功但应用来不及处理；而半连接队列满则直接发生在握手阶段，意味着连接根本建立不起来。
如何防御半连接队列耗尽攻击
防御SYN Flood，需要从操作系统、应用层和网络层多个维度协同入手，以下是实操性较强的几个步骤。
调整内核参数，提升队列容量
合理的Linux内核参数调整能有效增大半连接队列的容量,提升抗冲击能力，修改/etc/sysctl.conf文件，加入或修改以下参数：
net.ipv4.tcp_max_syn_backlog = 65536 net.core.somaxconn = 65536 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_syn_retries = 1
tcp_syncookies = 1是关键选项，它开启SYN Cookies机制，当半连接队列满时，内核不会直接丢弃新SYN包，而是通过Cookies机制直接回复基于连接信息计算的特殊序列号，无需在队列中保留条目，等客户端回传ACK后再重建连接。这个机制能极大缓解半连接队列被打满这类攻击表现带来的影响。
修改完成后执行sysctl -p使参数生效。
使用iptables限速，过滤异常流量
对于明显的攻击特征,可以用iptables进行粗粒度过滤：
iptables -A INPUT -p tcp --syn -m limit --limit 200/second --limit-burst 100 -j ACCEPT iptables -A INPUT -p tcp --syn -j DROP
这条规则允许每秒不超过200个SYN包进入,超过部分的SYN包直接丢弃，正常业务流量通常不会达到这个阈值，而攻击流量则会被有效阻断。
但要注意，iptables限速对分布式大流量SYN Flood效果有限，且可能误伤正常高并发业务。
接入高防产品或CDN服务
对于互联网业务,单靠服务器自身防御很难扛住大规模攻击，据统计，近年来的SYN Flood攻击流量动辄达到每秒数百万包，远超单台服务器的处理能力，行业共识认为，可靠的方案是接入专业抗DDoS产品或高防CDN服务。
简米云盾、酷番云大禹等国内主流云厂商均提供SYN Flood专项防护，通过清洗集群在攻击流量进入机房前进行识别和丢弃，选择服务时，需要考虑防护能力、清洗阈值、业务延迟保障、价格是否适合自身规模等因素，以挑选高防产品为例，关注清洗节点的总带宽能力，以及是否支持TCP协议栈指纹校验，因为后者直接关系到对低位速率SYN Flood的检测有效度。
应用层代码的容错处理
在应用层,也可以做一定的容错设计，比如nginx作为反向代理时，设置合理的proxy_connect_timeout参数，避免因上游连接等待导致连接积压：
proxy_connect_timeout 5s;
合理设置listen指令的backlog参数，配合内核somaxconn确保应用接收队列有足够空间。
SYN Flood攻击的演进与半连接队列的关联
理解了半连接队列被打满属于哪一类攻击表现之后,还需要了解攻击本身在进化。
低速率攻击与分布式伪装
过去那种高速率洪水式SYN Flood攻击容易被检测，近年来出现了更多低速率慢速攻击，攻击者以低于触发安全告警阈值的速率，均匀地发送SYN请求，每次持续很长时间，一样能把半连接队列慢慢填满，这种攻击更难发现。
TCP连接重置攻击与半连接的关系
与SYN Flood相关的还有TCP RST攻击，攻击者通过伪造源IP，向目标服务器的对端连接发送RST报文，迫使连接中断，虽然不直接作用于半连接队列，但大量连接中断会导致客户端不断重连，进而产生大量新的SYN请求，间接加重半连接队列的负担。
物联网僵尸网络放大效应
近年来,随着物联网设备大量暴露在公网，攻击者利用Mirai等僵尸网络的变种，集中控制海量摄像头、路由器设备发起SYN Flood，这些设备数量庞大，即使每个设备只发少量SYN包，汇总后的总量也非常恐怖。半连接队列在这种指数级增长的攻击流量面前，被填满只是时间问题。
半连接队列被打满属于哪一类攻击表现：常见问答
如何区分半连接队列满与正常高并发？
正常高并发下,服务器会出现大量ESTABLISHED状态连接，SYN-RECV状态占比很小，且连接来源IP分布符合业务特征，若SYN-RECV数量占主导，来源IP分散且大量不存在于业务用户画像中，基本可判定为攻击。
开启SYN Cookies后是否就万无一失？
不是,SYN Cookies机制对中小流量攻击效果较好，但当攻击流量大到一定程度，即使不占用半连接队列，也会消耗大量CPU资源用于计算和校验Cookies，导致CPU过载，大规模攻击时仍需依赖上游清洗设备。
云服务器的安全组配置能防御SYN Flood吗？
安全组是网络访问控制层,能过滤特定源IP或端口，但无法识别和丢弃伪造源地址的SYN报文因为伪造IP在数据包到达时看起来并无明显异常，安全组可以作为第一道过滤防线，真正的SYN Flood防护需要TCP层协议栈和流量清洗机制的配合。
半连接队列被打满属于哪一类攻击表现,归结到底，它就是DDoS攻击中SYN Flood的典型症状，属于协议资源耗尽型攻击的一种。 防御它没有一劳永逸的方案，需要系统层参数调优、网络层流量过滤、架构层高防部署多管齐下，随着攻击手法不断进化，运维人员需要持续关注服务器连接状态指标的异常变化，才能在攻击发生时快速识别、从容应对。