高频DDoS攻击早已不是单纯拼带宽的洪水攻击，现在更常见的是每秒数百万乃至上千万个请求的应用层消耗，以及混合了UDP反射、TCP SYN洪水、TLS握手耗尽和慢速攻击的“组合拳”。如果防御思路还停留在单纯加带宽、封IP或者依赖单一防火墙规则，基本撑不过攻击发起后的前几分钟。真正能在高频场景下生效的防御，核心在于把“识别、丢弃、限速、隔离”这几件事做到自动化，并且把防御节点尽量前移。
先解决协议层的无效流量：丢弃比响应更有效
高频攻击下，最忌讳让服务器对每个请求都做出完整响应。对于UDP反射类攻击，如果业务本身不依赖特定UDP端口，直接在边界路由器或交换机上做目的端口过滤，而不是等流量进入服务器网卡。对于必须开放的UDP服务，比如DNS，要启用响应速率限制（RRL），并且对非授权递归查询直接丢弃。TCP层面，SYN洪水的高频版本往往伴随源IP伪造，此时启用SYN Cookie是基础操作，但更重要的是调整TCP backlog行为，缩短SYN队列中半开连接的存活时间，同时开启tcp_syncookies并配合iptables的hashlimit或nftables的limit模块，让新连接建立速率与服务器实际处理能力匹配。
一个常被忽视的点是：高频攻击中大量报文可能来自同一段伪造源地址。可以在边界设备上启用基于源IP前缀的速率限制，例如对每个/24网段的新建连接速率做上限，而不是只针对单个IP。这样即使攻击者不断轮换源IP，只要源地址集中在少数网段，整体速率就会被压制。对于真实源IP的分布式攻击，则需要更上层的指纹识别和行为分析。
应用层高频攻击：从“请求数”转向“行为特征”
HTTP洪水类攻击的特点是请求本身合法，但频率极高，目标往往是搜索接口、登录页面、购物车提交或API端点。单纯按IP限速容易误伤NAT出口后的正常用户，而且攻击者使用代理池时，单IP频率并不突出。更有效的方法是对请求内容做特征聚合：同一个User-Agent、相同的Cookie缺失模式、相同的请求路径组合、固定的Header顺序，这些特征在高频攻击中会大量重复出现。可以基于这些维度建立动态指纹，对匹配指纹的流量做整体限速或挑战验证。
针对TLS层面的高频握手攻击，建议在反向代理层启用TLS会话复用和0-RTT，但这并不能阻止攻击者消耗CPU做握手。更实际的策略是：对同一源IP的TLS握手速率做严格限制，同时缩短握手超时时间，对未完成握手的连接快速回收。如果攻击规模达到一定程度，可以考虑在边界启用TLS指纹识别，直接丢弃已知恶意指纹库中的客户端，或者对非主流TLS指纹的流量优先进入挑战页面。
防御架构上的关键调整：把“判断”放在离攻击源最近的地方
高频DDoS防御不能只靠源站。任何在服务器本地做的判断，当流量已经到达网卡时，其实已经消耗了带宽和中断资源。正确的做法是分层过滤：第一层在运营商或云清洗中心，基于NetFlow/sFlow数据做粗粒度丢弃；第二层在边界设备，基于报文特征和速率做精确过滤；第三层在反向代理或网关，基于应用行为做深度判断；最后才是源站自身的资源保护。
如果业务部署在云上，务必把负载均衡器的空闲连接超时调低，开启“删除不健康后端”的快速失败机制，避免攻击流量把后端连接池占满。对于自建机房，建议在服务器前端部署DPDK或XDP-based的过滤程序，利用eBPF在网卡驱动层直接丢弃报文，绕过内核协议栈的处理开销。高频攻击下，内核软中断会成为瓶颈，把过滤下沉到硬件或驱动层能显著提升抗压能力。
具体可落地的配置思路
在Linux服务器上，以下参数在高频攻击场景下需要调整：
net.core.somaxconn = 65535 net.ipv4.tcp_max_syn_backlog = 65535 net.ipv4.tcp_syncookies = 1 net.ipv4.tcp_synack_retries = 1 net.ipv4.tcp_abort_on_overflow = 1 net.ipv4.tcp_fin_timeout = 10 net.ipv4.tcp_tw_reuse = 1 net.ipv4.tcp_max_tw_buckets = 200000 net.ipv4.ip_local_port_range = 1024 65535 net.core.netdev_max_backlog = 100000 net.ipv4.tcp_max_orphans = 65536
这些参数的核心逻辑是：缩短半开连接和TIME_WAIT状态的存活时间，扩大队列长度，启用Cookie机制，让服务器在高频新建连接下不至于迅速耗尽内存和文件描述符。但要注意，这些参数只是缓解，不能替代边界过滤。
在Nginx层面，针对HTTP洪水可以做如下限制：
limit_req_zone $binary_remote_addr zone=perip:10m rate=30r/s;
limit_req_zone $http_user_agent zone=perua:10m rate=100r/s;
limit_conn_zone $binary_remote_addr zone=perconn:10m;
server {
limit_req zone=perip burst=50 nodelay;
limit_req zone=perua burst=200 nodelay;
limit_conn perconn 20;
client_body_timeout 5s;
client_header_timeout 5s;
keepalive_timeout 10s;
send_timeout 5s;
}
这里同时限制了单IP请求速率、单User-Agent请求速率和单IP并发连接数。高频攻击中，攻击脚本往往使用固定UA，对UA做整体限速能有效压制攻击流量，同时正常用户分散在不同UA下，受影响较小。
针对API和动态接口的精细化防御
很多高频DDoS攻击瞄准的是API接口，尤其是需要数据库查询或计算资源的接口。这类接口的防御不能只靠通用限速，需要结合业务逻辑做分级处理。例如：对未携带有效认证令牌的请求，直接返回401并丢弃，不进入业务逻辑；对携带令牌但请求频率异常的，先进入验证码或等待队列；对高频且参数高度重复的请求，可以在缓存层直接返回缓存结果，避免每次都打到数据库。
一个有效的做法是引入“请求优先级队列”。将用户分为正常、可疑、恶意三个等级，正常用户请求直接进入业务处理，可疑用户请求进入延迟队列，恶意请求直接丢弃。等级判定依据包括：是否携带有效会话、请求频率是否突变、请求参数是否与历史行为一致、来源IP信誉度等。高频攻击下，攻击流量会被迅速标记为恶意并丢弃，正常用户几乎不受影响。
监控与自动化响应
高频攻击的持续时间可能只有几分钟，但强度极高。人工介入往往来不及，必须依赖自动化检测和响应。建议在边界设备上设置基于速率的触发规则，例如：当某目的IP的新建连接速率超过阈值时，自动启用更严格的过滤策略；当某源IP或源网段的流量占比超过一定比例时，自动将其加入黑名单并通告上游。同时，日志系统要能实时输出Top源IP、Top目的端口、Top请求路径和Top UA，方便快速定位攻击特征。
对于应用层攻击，可以在反向代理层输出实时统计，一旦某个URL或某个UA的请求速率出现异常尖峰，自动触发针对该特征的限速或挑战。这种基于特征的动态响应比静态规则有效得多，因为攻击者会不断变化请求内容来绕过固定规则。
容易被忽略的细节
高频攻击下，DNS解析本身也可能成为瓶颈。如果源站依赖外部DNS做负载均衡，攻击者可能同时对DNS发起查询洪水，导致解析延迟增加。建议对DNS服务也做分布式部署和速率限制，同时降低TTL，确保在切换防御节点时能快速生效。另外，日志写入也会成为高频攻击下的性能瓶颈，建议将访问日志级别调整为只记录错误或采样记录，避免磁盘IO被日志写满拖垮。
还有一个关键点是：防御策略要区分“正常突发”和“攻击突发”。电商大促、抢购活动时，流量本身就会数倍增长，如果防御阈值设置过低，会误伤正常业务。因此，阈值需要结合历史基线动态调整，而不是固定不变。可以通过机器学习或简单的滑动窗口算法，计算出当前时段流量的合理区间，当实际流量偏离基线超过一定倍数时，才触发防御动作。
高频DDoS防御的本质不是“挡住所有攻击”，而是“让攻击成本高于防御成本，同时保证正常业务可用”。把过滤前移、缩短响应路径、自动化识别特征、分层限速，这四件事做到位，大部分高频攻击场景下都能保持业务不中断。真正难的是在攻击发生时，团队能快速判断攻击类型并调整策略，而不是盲目重启服务或加带宽。
