互联网服务提供商（ISP）和电信公司（如 T-Mobile 或 British Telecom）容易受到网络 DDoS 攻击，这些攻击通常针对最终客户——例如，试图攻击通过宽带互联网服务提供商接入互联网的企业或远程工作者。历史上，为保护这些客户，服务提供商依赖在本地托管自己的缓解系统。这种方式需要大量投资才能有效应对不断演变的攻击，而面对日益增大的攻击规模，本地容量是有限的。
Cloudflare 以其保护公共网站和 API 的 DDoS 缓解服务而广为人知，同样的技术也可用于保护整个网络。在 Cloudflare，我们目睹了超大容量攻击的激增 ↗以及高度复杂的攻击，这在我们的季度 DDoS 攻击报告 ↗中有所体现。这些攻击由于其庞大的体量，可能压垮并击败本地 DDoS 缓解系统。因此，这些本地缓解系统需要持续维护和升级以跟上更大规模的攻击，导致持续投入，且由于攻击规模不可预测，成本难以控制。
Cloudflare Magic Transit 以服务形式提供基于云的网络 DDoS 缓解。服务提供商正在使用 Cloudflare Magic Transit 按需服务，或作为其现有方案的补充，或作为替代，以保护其网络基础设施免受这一不断演变的威胁。
部署此解决方案主要分两步。首先，设置 Cloudflare 以监控 ↗和检测网络上的 DDoS 攻击。然后，在观察到 DDoS 事件时，通过 Cloudflare 重新路由流量，由 Cloudflare 进行 DDoS 缓解。
注意：此图像中的标签可能反映以前的产品名称。
第一步是获取对服务提供商网络所受攻击的可见性。上图显示：
- Cloudflare 获悉需保护的网络。服务提供商确定其希望保护的前缀（例如 203.0.113.0/24），并启动一次性任务将这些前缀加入到 Cloudflare Magic Transit 服务；此步骤是先决条件，不影响实际网络流量。Cloudflare 建议加入比服务提供商向互联网宣告的前缀更精确的子前缀。如本例，若 203.0.113.0/24 是加入 Cloudflare 的受保护前缀，则涵盖 112.0/24 和 113.0/24 两个前缀的更不精确的 203.0.112.0/23，可向您的上游 ISP 宣告。
- 服务提供商网络设备将所有流量数据（Netflow、IPFIX 或 sFlow）发送至网络流量（前身为 Magic Network Monitoring）服务。Cloudflare 分析这些流量数据以检测 DDoS 攻击。
- Cloudflare 建议尽可能通过在我们的互联设施 ↗建立冗余的Cloudflare 网络互联（CNI）来连接至 Cloudflare 网络，这允许路由用户流量的最大传输单元（MTU）保持 1500 字节。或者，您也可以通过互联网上的通用路由封装（GRE）隧道连接至 Cloudflare 网络。
- 在平时，流量如常在 ISP 网络与其上游传输和对等网络之间流动，绕过 Cloudflare 网络。
注意：此图像中的标签可能反映以前的产品名称。
上图展示了 Cloudflare 如何监控服务提供商流量，并在检测到可能的容量型 DDoS 攻击时，自动从 Cloudflare 全球网络向互联网宣告最精确的受保护前缀。这确保流向该受保护前缀的所有流量都被重新路由至 Cloudflare 网络，在那里恶意流量得到缓解。
- 检测到可能的容量型 DDoS 攻击后，Cloudflare 自动生成警报。服务提供商可通过电子邮件和/或 Webhook 接收警报通知。此外，根据服务提供商的 Magic Transit 配置，该警报可触发从 Cloudflare 网络到互联网的前缀自动宣告。
- Cloudflare 从所有 Cloudflare 存在点宣告受保护前缀。由于 Cloudflare 宣告的是更精确的前缀，因此只有流向被攻击前缀的流量才会被重新路由至 Cloudflare 网络。
- Cloudflare 网络缓解攻击流量，同时让合法流量通过至服务提供商网络。使用Cloudflare 网络互联（CNI）时，服务提供商接收 MTU 为 1500 字节的原始数据包。
- 受保护前缀的出站流量以及其他前缀的流量不受影响，继续通过服务提供商的上游链路路由至互联网。
- 与受信任网络的私有对等互联不受影响，来自这些内容提供商（如 Facebook、Netflix、YouTube）的流量不会通过 Cloudflare 重新路由。