大促期间DDoS防护容量预估与弹性扩容方案

大促期间，攻击者很清楚你不敢随便封禁IP，因为每一笔订单都可能是真金白银。他们赌的就是你在业务中断和高额清洗成本之间的两难。DDoS防护容量预估，本质上不是算一个数字，而是算清楚你的业务在极端流量下，哪些服务可以降级，哪些必须死保。很多团队在预估时，习惯把历史峰值的1.5倍或者2倍作为弹性目标，这在常规活动里勉强够用，但面对秒杀、抢券这种瞬时并发叠加DDoS攻击的场景，这个系数很可能直接被打穿。

不要把目光只盯在带宽总量上。大促期间的致命问题往往出在新建连接数和应用层请求速率。你需要把预估拆成三个维度：带宽吞吐量、每秒新建连接数、应用层QPS。先梳理核心交易链路的API端点，比如登录、加购、结算、支付回调。针对每一个端点，拿出过去一年促销活动的峰值数据，再乘以业务增长系数。这个系数不是拍脑袋的1.5，而是要根据今年预热期的收藏加购量、优惠券发放量、预约人数来倒推。例如，今年预热期加购量比去年同期增长了80%，那你的应用层QPS预估基线就应该在去年峰值的基础上至少翻倍，因为攻击者往往会混在正常流量里，用略高于正常值的请求速率去消耗你的连接表。

带宽层面，除了考虑正常业务流量，还必须单独计算攻击流量冗余。一个容易被忽视的事实是，现在的大流量攻击很多是反射放大加直接发包的组合。如果你的核心业务入口在公有云上，需要确认云厂商单线清洗能力是否和你预估的攻击峰值匹配。注意，这里说的是单线，因为很多厂商的总清洗容量是跨区域、跨线路的汇总值，而你的业务入口可能集中在某个BGP线路。一旦该线路的清洗节点被打满，流量就会被黑洞，业务直接中断。所以，防护容量预估的底线，是单接入点清洗容量必须大于你预估的最大攻击流量，而不是看厂商的总宣称值。

弹性扩容最大的误区，就是认为只要资源够多就能扛住。实际上，当攻击流量大到一定程度，你的数据库连接池、Redis连接数、消息队列堆积量会先于带宽触达瓶颈。扩容方案必须分层设计。接入层做横向扩展相对容易，通过负载均衡把流量分散到更多节点。但问题在于，如果攻击请求都带着合法的会话Cookie，穿透到了后端，那应用服务器扩容的速度远远跟不上攻击请求建立连接的速度。这时候需要在接入层之前，就完成恶意流量识别。

一个有效的做法是把防护策略和弹性策略联动。在自动化编排脚本里，设置触发条件不仅是带宽使用率超过70%，还要包括新建连接速率异常、特定URL的请求比例失衡、以及后端服务响应时长的突增。当这些条件同时命中，自动执行的扩容动作不是直接加应用服务器，而是先切换至高防清洗中心，同时把静态资源回源策略临时改为全站缓存，减少对源站的穿透压力。这个切换动作必须在30秒内完成，否则秒杀开始后的第一波攻击就能把库存缓存击穿。

很多人忽略了TCP协议栈本身的状态表限制。一台高配服务器，在默认内核参数下，能够同时处理的半连接和全连接数量是有限的。大促期间，攻击者会大量发送SYN包，占满你的SYN Backlog队列。即便你买了高防IP，如果源站的内核参数没有调优，流量清洗完回注到源站时，源站自己也会因为连接表溢出而拒绝服务。所以，在预估防护容量时，必须把源站的内核调优纳入考量范围。调整tcp_max_syn_backlog、启用SYN Cookie、缩短tcp_synack_retries这些操作，不是上线前夜才做，而是要在压测阶段就验证过。

对于使用HTTPS的业务，TLS握手带来的CPU消耗是另一个隐形杀手。大促时大量攻击请求会故意发起TLS握手但不完成，或者使用过期的加密套件，迫使服务器消耗大量CPU去做无效运算。在弹性扩容方案里，应该把TLS卸载前置到高防节点或者专门的SSL加速集群，源站只处理明文HTTP流量。如果架构上做不到，那就必须在高防节点上启用TLS指纹识别，把不符合正常浏览器指纹特征的握手请求直接丢弃，不消耗后端资源。

大促期间，攻击者越来越倾向于使用慢速攻击和应用层CC攻击。这类攻击的流量并不大，但每一条请求都在消耗你最昂贵的资源，比如数据库查询、短信验证码接口、库存扣减逻辑。防护容量预估如果只看流量图，会完全漏掉这类风险。你需要单独列出业务系统中的高消耗接口清单，对每一个接口做独立的速率限制。这个限制不能是全局一刀切，比如整个网站限制每秒1000次请求，而是要对搜索接口、领券接口、下单接口分别设置不同的阈值。

更关键的是，这些阈值要和业务预期对齐。比如你预估大促当天有10万人同时抢一张券，那领券接口的瞬时并发可能达到每秒5万次以上。如果攻击者混入其中，用脚本以每秒几百次的频率反复调用，传统限频很难区分正常用户和攻击者。这时候需要在限频策略里加入行为特征分析，比如同一个会话在领券前是否有正常的浏览轨迹，同一个设备指纹是否在短时间内切换了多个账号。这些判断逻辑必须在前置的WAF或者风控引擎里完成，不能落到后端业务系统上。

单点云厂商的清洗容量再大，也有被针对性打满的风险。大促防护的弹性扩容方案，理想状态是具备跨云调度能力。但这不意味着你要把业务做成完全多云部署，那样成本太高。更务实的做法是，核心交易链路跑在主云上，静态资源和部分非核心接口提前在备用云上做好预热。当主云入口遭遇超大规模攻击时，通过DNS智能解析，把非核心流量切到备用云，把主云的清洗容量集中留给交易链路。

这个切换过程需要提前演练。DNS的TTL设置、证书的跨云部署、会话同步机制，任何一环出问题都会导致切换失败。尤其是会话同步，如果用户在A云登录，被切到B云后需要重新登录，那大促期间的客户体验会直接崩盘。所以，要么在网关层做中心化的会话存储，要么在切换策略里保证已经登录的用户在一定时间内不会被调度到其他云。这些细节，远比买多少G的防护带宽重要。

纸面上的方案再完美，没有经过实战检验都是空谈。大促前的压测，不能只测正常业务流量，必须混合攻击流量一起测。你需要模拟三种攻击场景：一是大流量ACK Flood，测试带宽清洗能力和黑洞阈值；二是CC攻击，测试应用层限频和风控引擎的响应速度；三是混合慢速攻击，测试连接表耗尽时业务是否还能提供降级服务。这三种场景要同时叠加在正常压测流量之上，观察整个系统的表现。

很多团队做压测时，习惯在内网环境进行，这完全测不出真实问题。因为内网延迟低、带宽充足，而真实攻击流量是从互联网多个节点涌入，经过清洗设备时还会引入额外延迟。压测环境必须和生产环境一致，包括经过高防节点、WAF、负载均衡的完整链路。压测工具的发包模型也要尽量模拟真实攻击工具，不能只用简单的HTTP GET请求，要包含带参数的POST请求、异常TLS握手、分片传输等高级攻击手法。

弹性扩容方案里，最容易被忽略的是回滚和止损策略。当攻击流量超出预估，自动扩容也扛不住的时候，必须有一套精确到接口级别的降级预案。这套预案要明确写出：第一级降级关闭商品推荐和评论服务，第二级降级关闭搜索功能，第三级降级只保留已登录用户的下单和支付。每一级降级对应的触发条件、执行动作、恢复条件都要写成自动化脚本，不能靠人工判断。

同时，要预设一个终极止损方案。当攻击流量大到连降级后的核心交易链路都无法维持时，是切换至静态公告页并暂停交易，还是通过其他渠道完成订单。这个决策必须提前和业务方达成一致，并写在应急预案的第一页。大促当天，技术团队没有时间开会讨论，所有动作都必须按照预案自动或半自动执行。

大促不是一天，而是一个周期。从预热期开始，攻击者就在不断探测你的防护边界。你需要建立一个贯穿整个大促周期的监控视图，把预热期、专场期、爆发期的流量基线分开。预热期的攻击手法通常是低频率的扫描和试探，目的是摸清你的限频阈值和WAF规则。如果在这个阶段你暴露了过于严格的拦截策略，攻击者会在爆发期针对性地绕过。所以，预热期的防护策略应该适当宽松，把拦截动作改为记录和标记，积累攻击特征，到爆发期再启用严格模式。

在爆发期，监控大盘上除了展示带宽、QPS、错误码比例，还必须展示各清洗节点的健康状态和容量使用率。一旦某个清洗节点的容量使用率超过80%，就要立即启动流量调度，把该节点上的部分流量牵引到其他节点或备用云。这个调度动作，同样需要提前写成自动化策略，并经过演练验证。

大促DDoS防护没有一劳永逸的方案，每一次大促的流量模型和攻击手法都在变化。把容量预估做细，把弹性策略做活，把应急预案做狠，才能在攻击者不断升级的对抗中，保住核心交易链路不中断。