tcp_abort_on_overflow=1不能防御攻击，仅将队列满时的静默丢包改为立即发送RST，使客户端快速报错，但不缓解溢出根本问题，也不提升吞吐或防御SYN Flood等攻击。
直接启用 tcp_abort_on_overflow=1 并不能防御攻击，反而可能加剧服务不可用。它只是改变溢出时的响应方式——从“静默丢弃 ACK”变成“主动发 RST”，对真实攻击流量无过滤或限速作用。真正有效的处理，是结合队列容量、应用吞吐与攻击特征做分层应对。
先确认是不是真被攻击了
全连接队列溢出不等于遭受攻击，更常见的是应用 accept 速度跟不上建连速度（比如线程阻塞、GC 停顿、慢日志阻塞等）。排查优先级如下：
- 查溢出计数：
netstat -s | grep "listen overflows"或ss -s | grep "times the listen queue of a socket overflowed" - 看当前队列状态：
ss -lnt | grep :端口号，关注 Recv-Q（实际排队数）是否持续等于 Send-Q（队列上限） - 检查应用层是否卡住：用
strace -p $(pgrep -f your_server)观察是否有长时间未返回的accept()系统调用 - 排除 SYN Flood：对比
netstat -s | grep "SYNs to LISTEN sockets dropped"，若该值飙升，才是半连接队列问题，需调tcp_max_syn_backlog和启用 syncookies
合理扩大全连接队列容量
队列太小会让正常流量也排队失败，尤其在秒杀、抢购类场景。扩容不是盲目调大，而是匹配业务峰值和应用能力：
- 查当前上限：
sysctl net.core.somaxconn（系统级）和应用 listen() 的backlog参数（如 Nginx 的listen ... backlog=4096，Tomcat 的accept-count） - 取两者最小值为实际队列长度，建议统一设为 4096 或更高（需同步调整应用配置）
- 临时生效：
sysctl -w net.core.somaxconn=4096；永久生效：写入/etc/sysctl.conf - Java 应用注意：Spring Boot 内置 Tomcat 默认
accept-count=100，必须显式配置覆盖
谨慎设置 tcp_abort_on_overflow
该参数只影响溢出后客户端感知方式，不影响防御能力：
-
tcp_abort_on_overflow = 0（默认）：服务端丢弃客户端发来的 ACK，客户端会重试（超时约 1 秒起），对短超时客户端表现为“连接慢” -
tcp_abort_on_overflow = 1：服务端立即回 RST，客户端快速失败（毫秒级），适合监控告警或客户端有重试逻辑的场景 - 不推荐仅靠设为 1 来“缓解攻击”——RST 本身也是响应开销，且可能被用于探测服务状态
- 生产环境建议保持 0，配合队列扩容 + 应用优化 + 外围防护（如防火墙限速、WAF、云厂商抗 DDoS）使用
必须配套的应用与网络层措施
内核参数只是最后一道闸门，关键在前端拦截和应用提效：
- 在负载均衡层（如 Nginx、SLB）配置连接数限制、请求速率限制（rate limiting）和 IP 黑名单
- 确保服务进程有足够工作线程处理 accept 后的连接，例如 Tomcat 的
maxThreads要大于预期并发连接数 - 避免 accept 后立即执行耗时操作（如同步 DB 查询、远程调用），应尽快交由线程池异步处理
- 开启内核防护：
net.ipv4.tcp_syncookies=1（防 SYN Flood）、net.ipv4.tcp_rmem/tcp_wmem合理调优（减少缓冲区浪费）
