防御DDoS攻击核心业务优先保障访问可用性

DDoS攻击发生时，很多运维团队的第一反应是“先让所有业务都活着”，但资源耗尽型攻击的本质决定了这种想法不现实。带宽、连接表、CPU、内存都是有限的，攻击流量一旦超过清洗阈值，必须做出取舍。核心业务优先保障访问可用性，不是简单地把流量切到高防IP，而是要在攻击发生前、发生时、发生后三个阶段都建立明确的优先级策略。否则就会出现一种尴尬局面：官网首页还能打开，但支付接口、登录接口、订单提交接口全部超时，用户看到的是一个“活着的空壳”。

先说清楚一个基本判断：DDoS防护不是无限资源对抗，而是资源分配策略。无论是自建清洗设备、运营商黑洞路由，还是云防护厂商的流量调度，最终都要回答一个问题——当攻击流量达到总带宽的80%、90%甚至更高时，哪些业务必须保留服务能力，哪些业务可以降级、限流或暂时关闭。没有这个预案，防护动作就是盲目的。

核心业务优先保障的第一步不是上设备，而是把业务系统按重要程度分级。通常可以分成三个等级：一级核心业务，包括登录认证、支付交易、订单提交、API对外服务等，这些业务中断会直接造成资金损失或用户流失；二级重要业务，包括商品详情页、用户中心、内容展示等，中断后影响体验但不直接产生资金损失；三级非关键业务，包括静态资源、活动页面、内部管理系统等，可以临时降级或关闭。

分级完成之后，要把这个分级结果落实到网络架构里。具体做法包括：为核心业务单独分配独立的IP段或独立域名，避免和非核心业务共用同一组入口资源；在负载均衡层为核心业务配置独立的监听端口和连接池；在DNS层面为核心业务配置独立解析记录，方便攻击时单独切换。很多企业的问题在于，所有业务都挂在同一个主域名下，攻击一来，整个域名一起被黑洞，想单独保留核心业务都做不到。

DDoS攻击最常见的打法是直接冲击业务入口IP，所以入口层的隔离能力决定了核心业务能不能在攻击中存活。一个有效的做法是，核心业务使用独立的高防IP或独立的清洗节点，非核心业务使用另一组IP。当攻击指向非核心业务IP时，核心业务入口不受影响，可以直接继续服务。当攻击指向核心业务IP时，清洗系统只需要保护这一组IP，资源消耗更集中，清洗效率更高。

如果条件不允许完全独立IP，至少要做到按端口或按路径分流。例如，核心API接口使用443端口的特定路径，非核心页面使用80端口。攻击流量往往针对80端口或整个IP段，核心接口的443路径可以通过七层负载均衡的策略保留下来。这里有一个容易忽略的细节：很多攻击工具会直接扫描全端口，所以单纯换端口并不能解决问题，但配合源站访问控制列表和协议指纹识别，可以过滤掉大部分非浏览器特征的攻击流量。

攻击流量进入清洗设备后，清洗策略的优先级设置直接决定核心业务的可用性。一个常见的错误是，清洗设备对所有进入的流量执行同样深度的检测，导致正常用户的请求也被延迟到超时。正确的做法是，对核心业务的源IP或会话特征执行快速白名单匹配，命中白名单的流量直接转发到源站，不经过深度包检测。白名单可以基于已登录用户的Cookie、Token、客户端证书或特定的HTTP头字段来建立。

对于无法提前识别为合法的流量，清洗设备需要按协议层次做分层过滤。网络层先丢弃明显的伪造源地址包、反射放大包和协议异常包；传输层对SYN Flood执行首包丢弃和Cookie验证；应用层对HTTP Flood执行频率限制、行为分析和验证码挑战。关键在于，应用层的深度检测只对非核心业务路径生效，核心业务路径即使需要检测，也要设置更宽松的阈值和更短的检测超时时间。否则清洗设备本身就成了新的瓶颈。

很多人只关注带宽和QPS，却忽略了连接表这个关键资源。无论是防火墙、负载均衡还是源站服务器，连接表都是有限的内存结构。SYN Flood、ACK Flood和慢速连接攻击的目标就是耗尽连接表。一旦连接表被打满，即使带宽还有剩余，新的正常连接也无法建立，表现为“服务器没流量但业务打不开”。

保护连接表的核心手段有三个。第一，在清洗设备或边界防火墙上启用连接老化时间动态调整，攻击期间把TCP半开连接的老化时间从默认的30秒甚至更长缩短到5秒以内，快速释放被攻击占用的表项。第二，对核心业务的源IP地址段配置连接数上限和新建连接速率限制，防止单个IP或少量IP占用过多连接资源。第三，在负载均衡层启用连接复用和HTTP/2多路复用，减少源站需要维护的连接数。对于核心业务，连接复用尤其重要，因为它能显著降低源站的压力。

即使清洗系统和负载均衡都正常工作，源站仍然可能因为应用层攻击或清洗策略绕过而被打垮。源站保护的第一步是隐藏真实IP，核心业务源站只允许来自清洗节点或负载均衡节点的流量访问，其他来源一律拒绝。这个规则要落实在网络访问控制列表和主机防火墙两个层面，不能只做一层。

第二步是源站自身的资源隔离。如果核心业务和其他业务部署在同一台服务器或同一个容器集群里，攻击导致非核心业务进程占用大量CPU或内存时，核心业务也会受到影响。建议为核心业务单独部署源站集群，或者至少使用容器资源限制和进程优先级控制，确保核心业务进程在资源竞争时优先获得CPU时间片和内存分配。

第三步是应用层的降级开关。核心业务内部还可以进一步细分，例如登录接口比注册接口更重要，支付回调比查询接口更重要。攻击期间可以临时关闭注册、找回密码等非关键功能，把资源集中到登录和支付上。这种降级开关需要在应用代码中提前埋好，不能等到攻击发生时再改代码。

DNS是DDoS防护中经常被低估的一环。攻击者可以直接对DNS服务器发起查询洪水，导致域名解析失败，用户连IP都拿不到，后面的清洗和防护都无从谈起。核心业务的域名应该使用独立的DNS解析服务，并且配置较长的TTL，这样即使DNS服务受到攻击，用户本地缓存和递归服务器缓存仍然可以继续提供解析结果。

更进一步的策略是，在攻击发生时通过DNS把核心业务的解析切换到备用IP段或备用线路。这种切换需要提前准备好备用解析记录和备用入口资源，并且确保切换动作可以在几分钟内完成。有些企业把核心业务同时配置在多个云厂商的入口上，通过DNS权重调度来分散攻击压力，这也是可行的方案，但要注意跨厂商的会话同步和数据一致性问题。

核心业务优先保障不能依赖人工判断，因为DDoS攻击的爆发速度往往在几十秒内就能把带宽打满。需要建立自动化的监控和响应机制。监控指标至少包括：入口带宽利用率、清洗设备CPU和内存使用率、连接表使用率、核心业务接口的响应时间和成功率、源站负载。当核心业务接口的成功率下降到预设阈值时，自动触发降级策略，比如启用更严格的限流、关闭非核心功能、切换备用入口。

自动化响应脚本要提前测试，不能等到攻击发生时才发现脚本有bug。测试方法可以是在预发环境模拟流量突增，观察脚本是否正确触发、降级策略是否生效、核心业务是否保持可用。另外，自动化响应要和人工决策形成配合，自动策略只处理明确的高置信度场景，模糊场景仍然需要人工介入，避免误杀正常用户。

核心业务优先保障不是攻击结束就完事了。攻击结束后，需要逐步恢复被降级或关闭的非核心业务，同时观察核心业务的性能是否恢复正常。恢复过程要分批进行，先恢复对核心业务依赖较小的功能，再恢复其他功能。如果一次性全部恢复，可能会因为攻击残留流量或用户补偿性访问导致二次过载。

复盘的重点不是“这次攻击多大”，而是“核心业务的可用性是否达到了预期”。需要回答几个具体问题：攻击期间核心业务的成功率是多少，降级策略是否按预期触发，清洗设备的资源消耗是否接近上限，连接表是否出现过饱和，DNS解析是否出现过中断。这些问题的答案会直接决定下一次攻击时策略是否需要调整。

最后强调一点：核心业务优先保障访问可用性，本质上是一种风险管理思维。资源有限的前提下，必须主动选择保护什么、放弃什么。那些试图在DDoS攻击中“全部保住”的方案，最终往往什么都保不住。把核心业务的访问路径、清洗策略、连接资源和源站能力全部独立出来，才能在攻击流量淹没入口时，让最重要的业务仍然可以被用户访问到。