面对连接数突然升高，立刻压低限速值未必能解决问题，还可能挡住正常用户。TCP连接耗尽攻击的防护与限速策略，应先确认被耗尽的是半连接队列、应用连接容量，还是 Linux netfilter 的连接跟踪表，再按业务峰值设置阈值。
先找出哪种资源正在吃紧
“连接数高”不是单一故障。新连接在握手过程中占用的半连接队列，和已完成握手、仍由程序维护的连接，消耗的资源不同；启用状态跟踪的主机或防火墙还可能先遇到连接跟踪表容量压力。
- 半连接队列：关注队列占用、握手重传及相关丢弃计数。SYN cookies 可帮助应对部分半连接压力，但不会增加应用程序处理已建立连接的能力。
- 已建立连接：检查各状态连接数、进程文件描述符使用量、线程或工作进程容量，以及连接持续时间。慢请求或未及时释放的长连接，可能让并发数持续累积。
- 连接跟踪表：在启用状态跟踪的 Linux 主机上查看表项使用量和插入失败等指标。此处耗尽时，即使应用本身尚有余量，经过该主机的流量也可能受影响。
判断时按时间对齐主机、网络设备和应用指标：若连接数上升同时服务延迟、丢弃或资源占用恶化，才说明已接近瓶颈。单凭某一时刻的总连接数，无法区分正常业务高峰与攻击流量。
把业务容量转成可用阈值
先从正常运行记录中整理繁忙时段的连接建立速率、并发连接数、连接持续时间和失败率，并按服务端口、来源网段或实例分别观察。共享出口的办公网络、移动网络可能让许多用户呈现为同一个来源地址，因此不能只按单个源地址一刀切。
再核实容量边界：应用可承受的并发量、进程文件描述符上限、监听队列设置，以及主机或防火墙连接跟踪表的容量。为维护、突发流量和增长预留空间。告警线可先设在已验证容量的约70%至80%，严重线可试设在约85%至90%；这只是压测与观察的起点，不是通用标准，低延迟或资源紧张的服务可能需要更保守。
TCP连接耗尽攻击的防护与限速策略，重点是区分“新建连接速率”和“同时存活的连接数”。前者可采用令牌桶限制短时间突发；后者则要结合业务连接时长、空闲超时和用户行为。两种限制不能互相替代。
按步骤试行，保留回退空间
- 采集基线：连续覆盖常见高峰与低谷，记录各类连接、延迟、错误率、队列和资源指标；同时确认监控本身没有采样盲区。
- 确定作用位置：明确规则加在主机防火墙、边界设备还是应用入口，并确认该层是否维护连接状态。避免多层重复限速造成阈值叠加。
- 先告警或小范围观察：使用影子统计、测试实例或少量流量验证规则命中情况，观察正常峰值、共享出口和运维连接是否受影响。
- 逐步收紧：优先限制异常的新建速率，再依据证据设置并发上限、空闲超时或来源类别规则。每次只调整一类参数，并检查延迟、成功率及丢弃量。
- 准备回滚：保存原有配置，设定观察窗口和恢复条件。若正常连接失败率升高，立即撤销最近变更，再重新评估阈值；不要在故障中同时改多个内核参数。
常见问题
启用 SYN cookies 就足够了吗？
不够。它主要缓解半连接队列相关压力，不能代替已建立连接的容量管理，也不能解决连接跟踪表耗尽或应用处理能力不足。
可以直接按来源 IP 限制连接数吗？
可以作为一层控制，但须评估共享出口、代理和地址转换带来的误伤。宜先观察来源分布，再采用分层阈值或对异常行为加严。
连接限速后仍然拥塞怎么办？
复查瓶颈是否在应用工作线程、文件描述符、网络设备状态跟踪或下游依赖，并核对连接是否长期不释放。限速只控制进入速度，不会自动释放已有资源。
稳妥的TCP连接耗尽攻击的防护与限速策略，始于资源定位和业务基线，终于小步验证与可回滚配置。先证明阈值符合实际容量，再逐步启用限制，通常比照搬固定数值更可靠。
