360安全产品面临DDoS攻击时，如何设计系统架构抵御攻击并保证核心服务可用性？请分析攻击类型、防御策略及容灾架构。
360安全开发实习生-引擎难度：困难
答案
1) 【一句话结论】针对DDoS攻击，需采用“分层防御（网络层流量清洗+应用层限流+负载均衡）+动态容灾（主备/多活切换）”架构，通过多维度识别攻击并快速切换资源，确保核心服务在攻击下仍保持可用性。
2) 【原理/概念讲解】
首先，DDoS攻击类型分为三类：
- 流量型（Volumetric）：如UDP flood、ICMP flood，通过海量无效流量淹没网络带宽（攻击流量远大于正常流量）。
- 协议型（Protocol）：如SYN flood（攻击者伪造大量SYN请求，耗尽服务器资源）、ACK flood（伪造ACK包），导致服务器资源耗尽。
- 应用层（Application）：如CC攻击（伪造大量正常请求，消耗服务器计算资源，如API接口、Web页面请求），攻击流量与正常流量特征相似，难以区分。
防御策略：
- 流量清洗：部署在网络入口（如边缘路由器、专用清洗设备），识别并丢弃攻击流量，仅放行正常流量（类比“流量安检机”，过滤坏流量，让好流量进入）。
- 限流：通过漏桶/令牌桶算法控制请求速率，防止服务器过载（漏桶：请求像水滴，先入队列再以固定速率流出；令牌桶：每秒生成固定令牌，请求消耗令牌，无令牌则丢弃，类比“给服务器设限”，如每秒最多处理1000个请求/IP）。
- 负载均衡：通过L4（四层，基于IP/TCP端口）或L7（七层，基于HTTP请求）负载均衡器（如Nginx），将请求分发到多台后端服务器，分散流量压力（类比“餐厅分餐员”，均匀分配请求到不同服务器，避免单点过载）。
- 容灾架构：主备模式（主服务器运行，备服务器热备，攻击时切换）、多活模式（多区域部署，区域间负载均衡，攻击时切换到未受影响的区域）（类比“银行系统”，主服务器故障时备服务器立即接管，保证业务不中断）。
3) 【对比与适用场景】
| 方面 | 流量清洗（网络层） | 限流（应用层） |
|---|---|---|
| 定义 | 网络入口过滤攻击流量 | 应用层控制请求速率 |
| 作用对象 | 攻击流量（如UDP flood） | 正常请求（如CC攻击） |
| 优势 | 处理海量流量型攻击 | 应对应用层复杂攻击 |
| 使用场景 | 大规模流量型DDoS（百万级流量） | 小到中等规模应用层攻击（如API滥用） |
| 注意点 | 专用设备，可能误杀正常流量 | 精确速率控制，可能影响正常用户体验 |
4) 【示例】
假设核心服务为“用户登录API”，架构如下：
- 前端：Nginx（L7负载均衡器），配置限流规则（每秒1000个请求/IP）。
- 中间层：WAF（Web应用防火墙），检测并过滤SQL注入、XSS等攻击，与DDoS防护设备联动。
- 后端：主服务器（Server A）+ 备服务器（Server B），主备通过心跳检测，攻击时切换。
- 容灾：多区域部署（北京、上海），区域间用负载均衡器（如AWS ELB）分发请求，攻击时切换到上海区域。
伪代码（Nginx限流配置）：
http {
limit_req_zone $binary_remote_addr zone=per_ip:10m rate=1r/s;
server {
listen 80;
location /login {
limit_req zone=per_ip burst=5 nodelay;
proxy_pass http://backend;
}
}
}
（limit_req实现令牌桶限流，每秒1个请求/IP，突发5个，允许短时间内少量超限。）
5) 【面试口播版答案】
（约80秒）
“面试官您好，针对DDoS攻击，我设计的系统架构核心是分层防御加动态容灾。首先，攻击类型分三类：流量型（如UDP flood）、协议型（如SYN flood）、应用层（如CC攻击）。针对流量型，在网络入口部署流量清洗设备，识别并丢弃攻击流量；针对应用层攻击，后端服务用限流（漏桶/令牌桶算法）控制请求速率，比如每秒1000个请求/IP；同时，通过L7负载均衡器（如Nginx）分发请求到多台后端服务器，分散压力。容灾方面，采用主备切换，主服务器受攻击时，备服务器通过心跳检测立即接管，保证服务不中断。多区域部署时，区域间用负载均衡器，攻击时切换到未受影响的区域。这样，既能抵御不同类型的DDoS攻击，又能保证核心服务可用性。”
6) 【追问清单】
- 问题：如何检测攻击的延迟？比如流量清洗设备识别攻击的延迟会影响正常流量？
回答要点：采用实时流量分析（如基于机器学习的流量特征识别），延迟控制在50ms以内，误报率低。 - 问题：限流策略对正常用户的体验影响？比如正常用户请求被限流？
回答要点：设置突发机制（如令牌桶的burst参数），允许短时间内少量超限，同时结合IP白名单，正常用户IP不参与限流。 - 问题：容灾切换的延迟？比如主备切换的RTO（恢复时间目标）？
回答要点：采用热备模式，心跳检测间隔短（如1秒），切换延迟小于3秒，保证服务可用性。 - 问题：成本方面？比如流量清洗设备和负载均衡器的成本？
回答要点：初期投入较高，但能应对大规模攻击，长期看降低业务中断损失，性价比高。 - 问题：如何处理攻击流量与正常流量的边界？比如误杀正常流量？
回答要点：结合多维度特征（如流量速率、协议特征、请求内容），降低误杀率，同时提供告警和人工干预机制。
7) 【常见坑/雷区】
- 坑1：只说限流而不考虑流量清洗，导致流量型攻击（如UDP flood）无法处理（限流只能控制应用层请求速率，无法处理海量无效流量）。
- 坑2：容灾架构设计为单点故障，比如主备切换依赖单一设备，导致切换失败。
- 坑3：限流策略设置过严，影响正常用户体验（如正常用户频繁被拒绝请求）。
- 坑4：攻击类型分析不全，漏掉协议型攻击（如SYN flood），导致服务器资源耗尽。
- 坑5：未考虑多区域容灾的负载均衡，攻击时切换到其他区域但数据同步延迟导致服务异常。