跳到页面内容
跳到互动练习
互动课堂 / 容量瓶颈观察台DAILY / SECURITY TERMS

022 / 网络与基础设施 / DDoS

城里还有空位,为什么客人进不来?

DDoS 分布式拒绝服务 · DDoS

服务器似乎还很空闲,进入服务的链路却被挤满了。多开几台服务器能救到这些请求吗?沿流量经过的路径找出最先耗尽的资源,再比较上游过滤、源站容量和合法用户受到的影响。

开始探索 ↓9–12 分钟
动手实验 · 场景判断 · 实用检查

大量发红光的设备挤在通向城门的桥上,城墙上有服务器角色,右侧拿购物袋的人被隔在外面。桥与入口比喻共享容量瓶颈;红色面孔是画家的提示,真实流量不会自带攻击者标签。

展开读图提示
读图提示
角色与机制
设备大军比喻分布式流量来源,桥与城门比喻带宽和服务处理能力。
风险在哪里
攻击流量耗尽容量后,正常用户即使有合法请求也无法及时获得服务。
防护与边界
结合上游清洗、CDN 与合适的限流和容量预案;单个源站的限流不能解决已被打满的上游带宽。

DDoS 分布式拒绝服务 · 本课场景

大量发红光的电脑、手机和设备挤满通往城堡的桥,右侧正常访客推着车排队等待,城堡内服务器忙碌。

大量发红光的设备挤在通向城门的桥上,城墙上有服务器角色,右侧拿购物袋的人被隔在外面。桥与入口比喻共享容量瓶颈;红色面孔是画家的提示,真实流量不会自带攻击者标签。

读图提示
角色与机制
设备大军比喻分布式流量来源,桥与城门比喻带宽和服务处理能力。
风险在哪里
攻击流量耗尽容量后,正常用户即使有合法请求也无法及时获得服务。
防护与边界
结合上游清洗、CDN 与合适的限流和容量预案;单个源站的限流不能解决已被打满的上游带宽。

按 Esc 或点击画面外侧关闭。打开原图 ↗

本课任务 / DDoS 分布式拒绝服务

按瓶颈所在位置选择防护,分别观察攻击负载、资源耗尽与合法业务损失。

  • 说明 DDoS 的分布式来源与可用性目标
  • 区分链路、连接和应用资源耗尽
  • 比较扩容、上游缓解与误伤的边界

DDoS 中的“分布式”是什么?

多个来源协同使目标资源不能正常服务合法用户,常通过过量流量或资源消耗实现。来源多不等于用户多,也不证明每个来源都由本人发起;受控设备和中间服务都可能参与。本课只模拟资源竞争,不生成攻击流量。[1][2]

为什么只看 CPU 容易看错?

瓶颈可能是网络带宽、连接状态、应用工作线程或后端依赖。一处先耗尽,下游即使空闲也无法完成业务。网络层与应用层问题需要不同缓解位置,单看请求总量或服务器数量不够。[3]

访问暴涨一定是攻击吗?

正常活动高峰也会超过容量。结合流量基线、请求特点、服务错误和业务背景调查,不只用一个峰值下结论。本实验提前标记合法与攻击负载以便教学;真实防护无法天然知道每一个请求的意图。[2][3]

亲手探索 / 不同条件,不同结果

从上游到源站,找到最先挤满的那一段。

切换正常与攻击负载、接入链路和源站容量,再比较不防护、源站过滤、上游清洗与双层防护。查看过滤误伤、链路丢失和源站容量损失;固定比例与抽象单位都不是部署参数。

数据与信任工作台 · 封闭离线模型

链路先堵住,源站加锁还来得及吗?

把正常业务与异常负载一起送入容量模型。上游清洗发生在受限链路之前;源站控制发生在链路之后。观察每个瓶颈与误伤,而不是只看拦住多少异常请求。

所有数字都是每轮等成本的“请求单位”,并非真实带宽、包速率或产品性能。模型按比例分配超载容量,不生成、重放或发送任何网络流量。

过滤器没有完美识别能力;切换强度会同时改变异常拦截与正常业务误伤。

尚未检查当前条件。修改选择会清除旧结论,请重新检查。

先用默认源站防护观察链路损失,再把防护移到上游并比较快照。最后切换严格过滤:异常更少不一定代表用户体验更好。真实防护还涉及协议、缓存、攻击成本、容量预案与服务商协作。

随手查 / 把理解带回实际工作

理解机制之后,检查这些细节。

实验是简化模型。真实环境需要明确业务规则、验证失败路径,并持续维护配置与证据。

01 / 实用细节

沿整条业务路径定位瓶颈

分别观察入口链路、连接层、应用以及必要的 DNS、认证和数据库等依赖。外部用户失败时,源站 CPU 没升高也不能排除前面的拥塞。本课把路径压缩为少数阶段,真实排查还需要监测范围与时间对齐。[3][2]

02 / 实用细节

链路先满,源站规则可能来不及

如果不需要的流量已经占满接入链路,在链路后端拒绝它仍不能让已经挤掉的合法流量重来。根据架构与服务商提前准备上游过滤或清洗;这说明缓解位置很重要,不意味着任何清洗服务都能无限承受攻击。[2][3]

03 / 实用细节

扩容只能缓解被扩大的那种资源

增加应用实例可能改善应用处理能力,却不会自动扩大前面的线路或修复共享数据库瓶颈。自动扩容也有配额、启动时间和费用约束,应配合预算、限额与降级策略;不要用“无限加机器”替代容量规划。[3]

04 / 实用细节

缓存与边缘防护要覆盖真正的访问路径

合适的缓存能减少重复内容回源;不可缓存的接口仍需要独立保护。CloudFront 的例子说明边缘处理和请求合并可以保护源站,但效果依赖实际缓存与转发配置,不能把所有私人响应简单共享缓存。[4]

05 / 实用细节

拦得更多,不一定服务得更好

过严的限速或超时可能拒绝合法高频与慢速用户,共享出口也会放大误伤。评估规则时同时看合法完成量、延迟和错误,按批准流程分阶段调整并准备回退。课堂已知标签用于显示误伤,不是现实分类器准确率。[3]

06 / 实用细节

事前约定,事后验证业务恢复

提前保存运营商与防护服务的联络流程,明确监测、启动缓解和对外说明的责任。恢复时检查关键用户路径及依赖,而不是只看流量下降;保留事件记录,并排查是否同时出现其他异常。真实演练必须有范围、容量与停止条件的授权。[2]

从模拟,到验证

找一个获准的环境,实际检查一次。

勾选用于本页自查,不会自动标记整课已学会。练习与清单刷新后重置。

本页已检查 0 / 5 项

实际检查清单
30 秒场景小测

上游链路被攻击流量占满,只加应用服务器够吗?

能解释原因,再标记学会。

小测结果同步错题本;“已学会”沿用原有本地学习记录。

资料与依据

  1. Cloudflare · What Is a DDoS Attack? ↗

    分布式来源、带宽/协议/应用层资源与合法流量;仅引用防御性概念

  2. CERT-EU · DDoS Overview and Incident Response Guide ↗

    分布式可用性攻击、分层缓解、基线与响应;2014 基础资料,不引用旧规模统计

  3. OWASP · Denial of Service Cheat Sheet ↗

    资源与依赖瓶颈、扩容成本、应用限制、上游防护和合法慢客户端误伤

  4. AWS · CloudFront DDoS Resiliency ↗

    边缘缓存、请求合并与回源负载;AWS 产品示例,不是通用容量保证

本页场景、人物与数据均为教学示例。互动选择不会上传;收藏、已学会与错题沿用当前浏览器本地存储。来源正文核对日期:2026-10-11。