攻击流量突然涌入时，网站面临的压力可能完全不同：有时是线路先被占满，有时带宽还够，连接表却已耗尽；还有一些请求能完成握手、通过HTTPS访问，却持续消耗登录接口和数据库资源。

高防CDN要解决这些问题，需要让分布式网络承接流量，在不同处理阶段识别并过滤攻击，再把允许通过的业务请求送往源站。T级描述的是流量规模，毫秒级描述的是某个响应环节的速度，两者需要协同，不能互相替代。

CDN07将T级分布式防护、智能调度、实时分析与多层过滤用于网站加速和安全防护。要理解这套思路为什么有效，可以沿着一个请求从进入防护网络到抵达源站的过程，逐层看它如何工作。

“毫秒级”和“T级”，分别解决什么问题？

DDoS是分布式拒绝服务攻击：攻击者借助大量来源制造流量或请求，消耗目标的网络和计算资源，让正常用户无法使用服务。

“清洗”则是对进入防护网络的流量进行识别、丢弃、限速、验证或放行。它是持续进行的在线处理，不是把全部流量收集起来，再统一处理一遍。

按十进制单位，1Tbps等于1000Gbps。但“网络拥有T级防护容量”“某个区域可用T级清洗资源”“某个业务享有T级保障”，是三个不同口径。

响应时间也需要拆开。攻击开始、系统观察到异常、生成规则、节点执行拦截、业务恢复到稳定状态，并不是同一个时间点。

已经存在的规则可以直接匹配后续流量；新的攻击模式往往需要积累样本、判断特征，再决定如何处置。

因此，快速拦截与准确识别要一起设计。只追求动作快，把正常用户同时挡住，网站依然没有恢复服务。

T级流量为什么需要分布式网络承接？

如果所有攻击先经过同一条容量不足的上游线路，再到达清洗服务器，即使服务器的过滤算法再快，也无法取回在线路拥塞时已经丢失的正常请求。

这就是清洗位置的重要性：过滤应尽量发生在业务瓶颈之前，网络入口、转发链路和处理节点都要有相应承载能力。

分布式调度让流量不必集中到一处

Anycast是一种常见的分布式入口技术，同一服务地址可由多个位置宣告，通过路由系统把流量送往相应节点。 RFC 4786关于Anycast运行的说明 也讨论了节点自治、路由变化和流量分布等问题。

Anycast有助于分散流量，但不保证每个节点均匀分担，也不保证始终选中地理距离最近的节点。攻击来源所在的网络、运营商路由策略和互联容量，都会影响实际落点。

DNS调度同样可以分配入口，但更新解析不会让已经建立的连接立即迁移，生效还受到缓存和客户端行为影响。大型防护网络可以组合使用多种调度方式，具体路径取决于部署。

因此，T级架构需要同时考虑总容量与局部余量。全网还有空闲带宽，不代表正在承受集中攻击的某个入口一定有足够余量。

同样1Tbps，处理难度可能差很多

大包容易消耗带宽，小包则可能让每秒包数迅速上升，先压满网卡队列、CPU或转发设备的包处理能力。

下面是一个简化计算，可直接用Python 3运行。它只演示平均包长与包速率的关系，不是CDN07的实测数据：

attack_bps = 1_000_000_000_000  # 假设攻击速率为1Tbpsfor packet_bytes in (1500, 100):    packets_per_second = attack_bps / (packet_bytes * 8)    print(f"平均每包{packet_bytes}字节：约{packets_per_second / 1_000_000:.2f} Mpps")

输出约为：

平均每包1500字节：约83.33 Mpps
平均每包100字节：约1250.00 Mpps

这里按同一统计层的平均包长计算，未加入额外链路开销。例子说明，即使带宽数值相同，处理的数据包数量也可能相差很大。

真正的承载上限，取决于带宽、包处理能力、连接状态容量以及应用处理能力中，哪一个先成为瓶颈。

流量进入节点后，为什么要分层清洗？

让每个数据包都进入最复杂的应用分析，会浪费计算资源；只做简单的IP封禁，又难以识别使用大量地址、行为接近正常访问的攻击。

更有效的处理顺序，是尽早剔除可以低成本判断的异常，把较昂贵的检查留给需要继续分析的连接和请求。

这是处理逻辑的划分；实际系统可以把多个阶段部署在同一台边缘服务器上，也可以分布到不同组件。

在网络处理早期丢弃明确的攻击包

这一层通常依据数据包自身以及已知流量特征作出判断。例如，目标服务不需要的协议流量、结构异常的报文，或者已经确认的攻击特征，可以尽早过滤。

XDP是Linux网络处理中的一种早期执行机制。Cloudflare在 公开的DDoS清洗技术分析 中介绍过一种实现：利用XDP和eBPF执行包过滤，将样本交给检测系统，识别攻击后再下发相应规则。

这个行业实例说明了早期过滤的价值：在流量进入更昂贵的协议处理之前，就完成一部分丢弃决策。它描述的是Cloudflare的具体实现，其他网络可以采用不同组件完成同类工作。

此时还看不到HTTPS里的完整请求路径和正文。因此，网络层过滤能够承担大量基础清洗工作，却不能代替解密后的HTTP行为分析。

验证连接，避免状态资源先被耗尽

TCP建立连接需要握手。大量未完成握手的连接，可能占用等待队列和相关状态，导致正常用户无法建立新连接。

RFC 4987对SYN Flood及常见缓解方式的分析 介绍了SYN缓存、SYN Cookie、代理等方法及其权衡。以SYN Cookie为例，其思路是在初始响应中编码必要信息，等收到可验证的后续确认后，再建立相应连接状态，减少半连接占用。

但连接验证通过，只能说明对方具备完成相应交互的能力，并不能证明它是真实用户。机器人同样可以正常握手，攻击也可能转向已建立的连接或HTTP请求。

所以，连接防护之后，仍然需要应用层判断。

在HTTP层判断请求是否正在消耗业务

HTTPS在边缘终止并解密后，应用防护才有条件分析URL、请求方法、请求头和相关会话信息。

例如，大量请求访问同一张可缓存图片，与大量请求访问需要数据库计算的搜索接口，即使RPS相近，对源站产生的压力也可能完全不同。接口的计算成本、缓存情况和业务流程，都应该参与判断。

AWS的 DDoS韧性架构说明 将全球网络容量与Web应用层防护分开讨论：前者用于承接大规模流量，后者需要结合WAF、应用承载能力与异常检测。

实际配置中，登录、查询、下载和支付回调应有不同策略。浏览器验证适合的场景，不一定适合移动端API；仅按IP限制请求，也可能影响共享出口下的正常用户。

CDN07关于 WAF、Bot管理与DDoS防护协同 的讨论，重点正是这些控制如何配合。网络清洗、机器人识别与业务规则各有职责，不能把其中一项当成所有问题的统一解法。

毫秒级响应如何实现：让检测分析与逐包执行分工

一个重要的工程思路，是把“分析应该采取什么措施”和“对当前流量执行措施”分开。

负责实际收发、匹配、丢弃和转发的部分，可以理解为数据面；负责分析样本、调整策略和分发规则的部分，可以理解为控制面。

数据面需要足够短、足够稳定的处理路径。已经下发的规则应尽量在节点本地执行，而不是每遇到一个数据包，都等待远端分析系统回复。

控制面则可以综合更多信息：短时间窗口内的包速率变化、连接完成情况、请求集中程度，以及正常业务基线的偏离。确认特征后，再将可执行规则交给数据面。

这种分工带来两个不同的时间尺度：已有规则可以持续快速执行；识别新的攻击，则需要观察和决策。前者的处理耗时不能代替后者的完整响应时间。

AI分析的价值，在于发现组合异常

单一阈值很容易遇到两难：阈值低，促销或游戏开服时误伤用户；阈值高，源站可能先被压满。

智能分析可以综合多个特征，帮助发现“单独看都不突出，组合起来却异常”的流量。但模型结果依然需要转化为明确动作，例如只限制某类高成本请求、调整某个路径的并发，或者对特定风险流量增加验证。

自动化还需要退出机制。临时规则应有有效期和回退条件，业务恢复后能够逐步撤销限制，避免攻击已经结束，用户却继续受影响。

毫秒级执行、持续学习与可回退的策略，共同决定防护是否既快又稳。仅有一个“AI评分”，并不能代替这条完整链路。

为什么清洗之后，还要控制缓存和回源？

前面的处理能减少攻击请求，却不意味着源站已经没有容量压力。真实用户的集中访问、漏过的异常流量，以及大量缓存未命中请求，都可能继续占用后端资源。

能在边缘响应的内容，不必重复交给源站

图片、脚本和符合缓存条件的公开页面，可以由边缘缓存返回。这样既缩短访问路径，也减少重复回源。

但缓存不应越过业务权限。按照 RFC 9111的HTTP缓存规则 ，不带字段参数的 private响应指令禁止共享缓存存储该响应。登录后的个人信息、订单等内容，需要按权限和缓存策略处理，不能为减轻压力而统一设置公共缓存。

还要关注缓存未命中的原因。无效查询参数可能制造大量不同缓存对象；但如果某个参数实际决定商品、语言或用户权限，直接忽略它也会返回错误内容。缓存键应依据业务语义设计。

回源限制需要匹配应用实际容量

清洗后的流量进入源站前，还可以通过回源连接复用、并发控制，以及适用场景下的请求合并，减少瞬时压力。是否支持、如何启用，要看对应服务。

对源站而言，关键不只是每秒来了多少请求，还包括每个请求占用多少CPU、数据库连接和外部服务时间。昂贵接口需要单独设置容量边界，不能套用静态文件的阈值。

此外，流量必须经过防护入口。如果攻击直接打向已暴露的源站IP，CDN上的规则无法替它处理这条旁路。有关历史解析、遗漏子域名和访问限制，可结合 源站IP暴露后的保护方法 逐项检查。

混合攻击到来时，各层怎样一起工作？

假设某个游戏活动页面同时遭遇三类压力：大量网络层攻击包、反复建立连接的异常流量，以及持续访问登录接口的HTTP请求。以下是机制演示，不是实际攻击记录。

分布式入口先承接到达防护网络的流量，网络过滤丢弃已确认的异常包；连接管理减少无效握手对状态资源的占用；能够完成HTTPS交互的请求，再进入应用防护判断。

活动页面的公开图片和脚本由缓存响应，登录接口则按独立规则处理。即便总攻击带宽已经下降，只要登录队列仍在增长，就说明问题还没有结束，需要继续观察接口负载和正常用户成功率。

反过来，如果拦截量上升的同时，正常用户也大量无法登录，应检查规则是否过宽。不能只凭“清洗了多少流量”判断防护效果。

多层协同的意义，是让不同类型的压力在合适的位置被处理，避免把全部成本都留给最后的应用服务器。

CDN07如何把分布式防护用于实际业务？

CDN07高防CDN 将网站加速与DDoS防护结合，并提供节点分布、带宽配置和安全策略的定制。对业务来说，这些能力应围绕同一个目标配置：攻击期间，正常用户仍能完成访问、登录和交易等必要操作。

面向大陆用户的海外网站，需要把入口访问线路与回源线路一起考虑；动态API应重点关注身份验证和接口容量；长连接业务则还需要观察连接持续性与重新连接情况。相同防护带宽下，业务结构不同，合适的策略也会不同。

在容量规划上，应区分网络总体防护资源与所选套餐的具体保障范围。攻击超过约定范围后如何处理、持续攻击期间能否扩展，以及相关费用如何计算，都应落实到实际方案。可以结合 高防CDN套餐与额外费用说明 理解这些口径。

技术效果则应从三个方向一起观察：

P95、P99分别用于观察延迟分布中较慢的一部分请求。记录攻击前、攻击中、攻击后的变化，比只看某一刻的平均响应时间更能说明问题。

毫秒级能力需要精度足够、时间同步的事件记录来衡量；分钟级监控曲线只能反映趋势。需要进行防护验证时，应在授权范围内由相关团队协调，不应向生产业务自行发起未经安排的攻击流量。

常见问题

毫秒级DDoS清洗，是几毫秒就把整个攻击处理完吗？

不是。清洗是持续处理过程，攻击持续多久，系统就可能需要持续过滤多久。毫秒级应对应具体的检测、规则执行或响应环节，不能自动理解为整个事件的恢复时间。

有T级带宽，是不是就能防住所有CC攻击？

不能。CC通常指消耗Web应用资源的攻击，请求可能占用不大带宽，却持续触发数据库、登录或查询操作。它需要应用层识别、接口限流和源站容量控制共同处理。

流量清洗会让网站变慢吗？

可能增加处理开销，挑战验证还可能增加交互。合理架构会通过早期过滤、本地执行和缓存减少不必要的成本，实际影响应看正常用户的成功率和延迟，不能只看清洗节点是否在线。

SYN Cookie能识别真人和机器人吗？

不能。它主要缓解特定的半连接状态消耗问题。能够完成握手的机器人依然可能发起应用层攻击，需要后续检测。

接入高防CDN后，还需要高防服务器吗？

取决于源站暴露情况、网络侧风险和业务协议。CDN主要保护经过相应代理入口的流量；如果还有公网源站直连、独立游戏端口等入口，需要为这些路径配置相应防护。

为什么攻击带宽下降了，业务还没有恢复？

可能仍有应用层攻击，也可能是数据库、线程池或任务队列已经积压。防护效果应结合正常请求成功率与源站恢复情况判断，不能把入口流量下降当作唯一结束标志。

高防CDN的技术价值，体现在整条处理链路：分布式网络承接流量，快速执行规则减少无效消耗，应用防护保护关键接口，缓存和回源控制守住源站容量。

如果正在为网站、API或活动业务规划防护，可以通过 CDN07技术咨询 提供用户地区、业务协议、正常峰值、源站容量及已有攻击记录。让防护方案与真实业务负载匹配，T级容量和快速响应才能转化为用户实际感受到的可用性。