DDoS防护与业务连续性的容量规划

DDoS攻击早已不是打满带宽的粗暴行为，现在的攻击向量混合了应用层撞库、慢速连接耗尽、DNS放大反射以及针对TLS握手阶段的精巧打击。谈容量规划，如果只盯着“清洗带宽”这一个数字，业务连续性在真实对抗中会迅速崩溃。真正的容量规划必须把防御拆解为三个并行的维度：网络管道容量、计算处理容量和应急响应容量，三者缺一不可。

很多团队在规划时习惯性地问“我们需要多大清洗带宽”，这本身就是一种过时的思路。带宽只解决 volumetric（大流量）攻击，比如UDP洪水或者ICMP洪水，这类攻击的目的是堵死入口路由器的上行链路。但今天更致命的是状态耗尽型攻击和应用层攻击，它们流量很小，却能直接让防火墙、负载均衡器或者后端数据库连接池瘫痪。

正确的做法是，先梳理业务流量的基线模型。你需要明确正常时段内，每秒新建连接数（CPS）、并发连接总数、每秒请求数（RPS）以及TLS握手速率的峰值。容量规划的第一性原理不是“抗住多少Gbps”，而是“在攻击导致连接表溢出前，系统还能处理多少合法事务”。以SYN洪水为例，攻击者发送大量伪造源IP的SYN包，防火墙或服务器的SYN backlog队列瞬间被半开连接占满。这时候即便你还有充裕的带宽，正常用户也无法建立TCP三次握手。因此，防御容量必须精确到“每秒可处理并验证的新建连接数”，这个指标通常取决于防御设备中专用ASIC芯片或高性能内核的数量，而非单纯的背板带宽。

状态化设备，比如下一代防火墙和服务器负载均衡器，维护着巨大的会话表。攻击者可以利用这一点，发送大量构造好的合法请求，不追求大流量，只求把会话表写满。一旦会话表溢出，设备要么进入“失效开放”状态让所有流量通过（这等于裸奔），要么进入“失效关闭”状态拒绝所有新连接（这等于自我DDoS）。

容量规划时，必须为状态表设定严格的警戒线。通常建议物理设备的内存会话表上限不要超过厂商标称值的70%，因为内存碎片化和突发流量会迅速消耗剩余空间。更关键的是会话老化时间的调优。默认的TCP会话超时可能长达数十分钟甚至数小时，攻击者可以缓慢建立连接，维持僵尸一般的空闲会话。你需要针对业务特性，将空闲TCP会话超时压降到秒级，对于HTTP类的短连接，甚至可以开启激进的半关闭状态回收。这部分的容量不是靠堆硬件堆出来的，是靠协议栈行为优化释放出来的。同样，TLS卸载设备的容量瓶颈往往在SSL/TLS握手时的非对称加密运算上。如果攻击者发起TLS重协商风暴，CPU会瞬间飙升。规划TLS处理容量时，不能只看“新建TLS会话数”，还要看“重协商速率限制”和“密钥交换算法的计算开销”，强制使用ECDHE这类前向安全的算法虽然好，但计算成本远高于RSA，这在攻击场景下会放大CPU瓶颈。

网络层和传输层扛住了，压力就会传导到应用层。Web应用防火墙的容量规划极其容易踩坑。厂商宣传的“吞吐量”往往基于全放行或者极简规则测试，一旦开启深度报文检测、正则表达式回溯限制、反序列化检查，实际处理性能可能断崖式下跌到标称值的30%甚至更低。

你必须基于最严苛的防护策略来标定WAF的容量。具体做法是，用录制好的生产环境全量请求流量，混合已知的攻击载荷，在预发布环境对WAF进行压测，直到误报率或延迟开始非线性恶化，那个拐点才是真实容量。尤其要注意HTTP请求体的解析，攻击者常发送极慢的请求体（slow body attack），比如每秒发一个字节，WAF必须缓冲整个请求体才能完成规则匹配，这会耗尽WAF的内存。因此，规划中必须包含“请求体最大缓冲尺寸”和“接收超时”的硬限制，并把这些限制对应的并发承受能力算进容量模型里。

源站服务器的容量规划同样要抛弃“平均负载”的幻想。攻击期间，数据库连接池是最脆弱的环节。假设正常时业务需要200个数据库并发连接，攻击流量可能会触发大量异常查询，比如撞库攻击会导致认证接口疯狂查询用户表。如果你的数据库连接池最大只设到300，那200个恶意查询就能把池子占满，导致所有正常登录请求排队超时。容量规划必须为关键服务做严格的资源隔离，比如把登录接口、搜索接口、静态资源接口拆分到不同的服务集群，各自拥有独立的连接池和线程池，这样任何一个接口被攻击都不会拖垮全局。这种微服务化的拆分成本很高，但它是业务连续性的核心容量保障，本质上是用空间换生存概率。

自建清洗中心还是接入云防护服务，这不仅仅是成本问题，更是容量弹性边界的问题。自建清洗设备有固定的最大吞吐量，超过阈值后，唯一的保命手段就是向上游运营商宣告黑洞路由，把所有去往目标IP的流量全部丢弃。黑洞路由虽然保护了骨干网，但业务完全中断，等于攻击者得逞。

更合理的容量规划是混合架构：日常由本地设备处理小规模、高精度的应用层攻击，当流量超过本地带宽或清洗能力的80%时，通过BGP社区字符串或DNS切换将流量牵引到云端清洗中心。这里的关键规划点是“切换延迟”和“回注容量”。BGP路由收敛可能需要几十秒到几分钟，这段时间内你的本地设备已经在过载了。因此，本地设备必须有能力在过载瞬间执行“选择性丢包”策略，优先丢弃UDP、ICMP等非关键协议，死保TCP 443端口的连通性。同时，云端清洗后的干净流量回注到你源站时，如果回注链路带宽不足，干净流量本身就会造成二次拥塞。你必须确保从云端回注点到源站的专线或公网链路的可用带宽，始终大于清洗后的合法流量峰值，这个值通常需要预留出正常峰值的1.5到2倍，以应对攻击期间因用户反复刷新、重试带来的额外流量激增。

所有容量规划的根基是真实测试数据，而不是设备手册上的数字。你需要构建一套常态化的混沌工程体系，专门模拟各类DDoS攻击向量。测试不能只在凌晨业务低峰期做，必须在真实生产流量混合攻击流量的情况下进行，因为很多防御设备的性能衰减恰恰发生在规则匹配和会话状态混合维护的时候。

测试要覆盖这几个极端场景：

第一，混合向量攻击。同时发起UDP洪水、SYN洪水、HTTP慢速攻击和DNS查询洪水，观察防御设备在并行处理不同协议攻击时的资源争抢情况。很多设备单测某一类攻击表现完美，混合攻击一来，内部规则引擎的优先级调度就会乱掉。

第二，源IP地址耗尽攻击。攻击者用海量真实分散的IP（比如来自物联网设备）发起低频应用层请求，每个IP的请求频率都在WAF的限速阈值之下，但总请求量巨大。这考验的是WAF的IP信誉库容量和全局计数器的处理能力。

第三，DNS层面的容量。如果你的权威DNS服务器被攻击，即使源站完全正常，用户也无法解析到IP。DNS容量规划需要关注NS服务器的分散部署，以及DNS响应包速率限制，防止被用作反射放大器。

这些测试的结果要转换成具体的容量公式。例如，你的单台WAF设备在开启全规则集后，能处理8万RPS的HTTP请求，其中包含30%的攻击请求，此时CPU稳定在75%，内存消耗60%。那么你的安全容量就是8万乘以70%约等于5.6万RPS，超过这个值就必须触发弹性扩容或者流量调度。

技术容量再充裕，如果应急响应流程是瓶颈，业务连续性依然是空谈。攻击发生时，值班人员需要登录多个控制台、分析流量日志、判断攻击类型、决定是否切换清洗、通知业务方，这个链条的耗时就是“响应容量”。很多重大中断事故中，技术设备明明有余量，但人没有在最佳时间窗口内做出正确决策。

必须为应急响应建立预编排的剧本，并把这些剧本固化为自动化策略。比如，当边界路由器检测到入向流量超过链路带宽的70%，且非TCP流量占比超过60%时，自动触发BGP宣告，将流量牵引至清洗设备，同时向运维群发送通知。这里人不再参与决策，只做监控和事后分析。自动化策略的容量规划，就是要把“可容忍的最大自动干预范围”定义清楚。你不能让自动化系统过于激进，比如因为一次突发新闻带来的正常流量激增就触发清洗，这会造成误伤。所以，自动化的阈值设定需要结合业务流量预测模型，而流量预测模型本身又需要足够的历史数据容量来训练。这形成了一个闭环：数据积累越多，自动化决策越准，响应容量就越大。

当所有防御层都过载，或者攻击绕过了防护直接打击业务逻辑漏洞时，容量规划的最后一块拼图是“业务降级容量”。你需要提前定义哪些功能是必须死保的核心交易链路，哪些是可以暂时关闭的非核心功能。

例如，在遭受大规模撞库攻击时，可以临时关闭登录接口的详细错误提示，只返回统一模糊信息；或者对非核心的推荐系统、社交功能进行降级，只保留订单提交和支付接口的完整处理能力。这需要在应用架构层面就设计好降级开关，并且这些开关的状态同步不能依赖可能已经拥塞的中心化配置中心，最好采用本地缓存加离线配置文件的混合模式。降级后的系统，其容量需求会大幅下降，相当于用一个最小可用产品形态扛过攻击峰值。这种“逃生舱”容量的规划，往往比单纯增加带宽更考验架构功底，因为它要求你把业务拆解得足够干净，确保降级组件之间的耦合度极低，不会因为关掉一个评论功能就导致整个页面渲染失败。

容量规划的本质不是追求无限大的数字，而是建立一套动态平衡机制：知道什么时候该硬抗，什么时候该调度，什么时候该丢弃非关键流量，以及什么时候该让系统优雅地缩小自己的服务范围。把网络带宽、计算状态、应用逻辑和应急响应这四个层面的容量当作一个整体来迭代优化，才能在攻击者不断变换手法时，让业务连续性始终处在一个可防御的状态。