高防IP防护上限详解：带宽、清洗能力与防御类型三重约束

做高防这一行的朋友应该都有同感买高防 IP 最怕的不是贵而是买了之后业务照挂钱花了骂没少挨。早几年我帮一个游戏客户接入高防对方上来就问“最大能防多少 G”销售也拍胸脯说“500G 随便打”。结果上线第二周一场 SYN Flood 把源站打趴了查了半天才发现问题根本不在清洗节点而是回源带宽只有 5Mbps正常流量都挤不回去。这类案例看多了我越来越觉得大家对“防护上限”的理解过于单一。很多人把它当成一个数字实际上高防 IP 的防护上限是一组由带宽、清洗能力、防御类型共同决定的约束条件。任何一个维度匹配不上业务需求哪怕标称的防御数值再高也是空中楼阁。这篇就把这三个维度拆开讲清楚并且给出从评估到落地的完整思路适合正在选型或已经买了高防但总觉得不放心的运维、架构师和业务负责人参考。1. 高防 IP 的“防护上限”到底限在哪1.1 高防 IP 的工作原理牵引、清洗、回源想理解防护上限必须先搞清楚高防 IP 的工作链路。理论上它并不神秘正常情况下用户请求先到高防节点高防节点把流量转发到源站当攻击发生时攻击流量同样会被引导到高防节点由清洗设备把恶意流量过滤掉再把剩下的合法流量送回源站。整个过程可以类比成小区门口的保安亭所有访客先过保安认识的人放行闹事的人拦下。这里有个关键点高防 IP 并不是把攻击“消灭”了而是把攻击流量“牵引”到自己身上然后“消化”掉。如果消化能力不够或者消化完之后合法流量送不回源站业务照样中断。这个链路里有三个物理环节分别是入口带宽、清洗处理能力和回源通道它们正好对应标题里的三个维度——带宽、清洗能力、防御类型决定清洗设备怎么处理不同特征的攻击。链路中任何一环成为短板防护上限就由那一环决定。1.2 防护上限不是三个数字而是三条约束很多朋友选高防的时候习惯盯着厂商页面上的“最高可防 300G”“最高可防 500G”这类数字觉得这就是上限。其实这是三条约束叠加后的结果。第一是带宽约束。攻击流量再大清洗节点入口带宽如果只有 100G那标称 300G 也扛不住 300G 的流量因为流量在入口就已经打满了。第二是处理能力约束。有些攻击不是靠流量大小取胜而是靠每秒海量的小包淹没设备比如 TCP SYN Flood跑满带宽可能只需要几十 G但每秒上百万元的包就能把设备的 CPU 打满。第三是功能覆盖约束。清洗设备再快如果只做了四层防护面对七层 CC 攻击就无计可施。所以“防护上限”不是一个值而是一个多维度的性能包络线。选型的时候只问“多少 G”等于只看了包络线的一个轴另外两个轴全是盲区。1.3 为什么标称“最高可防 XXXG”会误导人除了维度单一标称值本身也有几个容易误读的地方。首先是资源池共享。厂商宣传的“集群总清洗能力 2T”不等于你这条 IP 独享 2T。实际攻击发生时IP 会调度到某个清洗节点节点的处理能力才真正决定你这单业务的上限。单 IP 防护规格和集群总容量是两码事一定要分开确认。其次是封堵策略。绝大多数高防产品有“防护峰值”和“封堵阈值”两个概念。攻击流量持续超过购买规格后服务商不会无限扛而是触发黑洞或者封堵策略把被攻击的 IP 隔离一段时间。换句话说超过阈值的那一瞬间业务就已经断了后面就算集群还有能力也不会继续给你扛。所以“最高可防 XXXG”在实操中应该理解为“最多扛到 XXXG超了就下线”。还有就是攻击类型的适配。同样是 100G 流量100G 的大包 UDP Flood 和 100G 的 SYN 小包 Flood对清洗设备的压力完全不是一个量级。前者考验带宽后者考验报文处理速率。只按带宽选型忽略了攻击类型很容易掉坑。2. 带宽维度业务带宽和攻击带宽是两笔账2.1 高防 IP 涉及的三个带宽口径带宽这个词在高防场景里特别容易混淆因为至少存在三个口径。第一个是业务带宽指你的源站在正常运营时实际需要的带宽由用户请求、下载、上传等真实流量组成。第二个是防御带宽指高防节点入口能承接并清洗的流量上限也就是厂商标称的“可防多少 G”。第三个是回源带宽指高防节点把清洗后的合法流量送回源站时使用的链路带宽。这三个口径里业务带宽和防御带宽是最容易被记住的回源带宽几乎没人会主动问。但根据我的经验回源带宽恰恰是导致“买了高防还被打挂”的头号隐藏原因。前面提到的游戏客户就是典型例子攻击流量被清洗得干干净净结果合法流量全堵在回源链路上用户体验跟被攻击时没有任何区别。2.2 回源带宽为什么是隐藏瓶颈回源链路的上限通常取决于高防服务商到源站机房之间的专线或隧道带宽以及源站出口本身的带宽。假设源站接入的是 10Mbps 云主机带宽而业务高峰期正常流量需要 80Mbps那么哪怕高防清洗了所有攻击流量回源链路也会被 80Mbps 的正常流量打满。还有一种情况比带宽打满更隐蔽回源链路的并发连接数超限。清洗之后大量合法用户请求会同时通过隧道回源如果后端的负载均衡或者源站防火墙的连接数上限设置过低回源通道就会拒绝新的连接表现就是访问超时、连接重置。我的建议很朴素回源带宽至少按“业务峰值带宽 × 1.5”来预留并且要持续观察一段时间确认业务突发流量不会把回源链路打满。特别是做活动、上线大促之前这一步绝对不能省。2.3 如何估算业务带宽需求估算业务带宽没有想象中复杂核心公式是并发用户数 × 单用户平均带宽 业务带宽需求。不同业务形态的单用户平均带宽差异很大。视频点播场景以 1080P 为例单路码率大约在 4Mbps 到 8Mbps 之间100 个同时在线用户就是 400Mbps 到 800Mbps。普通网站的页面请求平均每个请求几十 KB按每分钟几百万请求规模推算可能只需要几百 Mbps。游戏保持连接的在线用户并发高但实际流量不一定大真正的高峰往往是版本更新时的补丁下载瞬时带宽会非常夸张。再强调一次估算时必须看监控数据而不是拍脑袋。建议连续采集源站出入口七天以上的流量曲线取高峰时段的均值作为基准再额外增加 30% 到 50% 的突发冗余。如果是电商这类流量呈脉冲式增长的业务冗余比例还要更高。2.4 带宽选型建议防御带宽的选择思路是“够用且有余量”而不是越大越好。高防 IP 的价格随着防御规格呈指数级上升从 20G 升到 50G 可能费用翻倍从 100G 升到 300G 更是天价。在选择规格前先评估业务面临的现实风险。历史上有没有被打过峰值大约多少行业是否有周期性攻击倾向如果历史攻击峰值最高 80G那选 100G 规格差不多如果完全没有记录但业务本身容易招黑那 120G 到 150G 会更稳妥。封堵阈值建议至少比历史攻击峰值高出 20%留出应激反应的时间。另外现在很多业务采用“高防 IP 云主机”组合即高防 IP 在前面扛清洗后端是云上的源站服务器。这种情况下不能只看高防的带宽云主机自身的带宽规格也必须同步升级。源站带宽不扩容高防回了半天流量源站一秒也咽不下去。注意带宽选型有一个常见误区就是把“正常业务带宽”和“防御带宽”混在一起。有人觉得业务只需要 50Mbps于是选了个 50Mbps 的 IP 带宽规格却想要它扛 300G 攻击。首先要明白 IP 带宽和防御带宽是两个参数其次源站出口规划时回源链路要按业务实际需求来而不是按高防标称的防御值来。3. 清洗能力不是更大而是更快、更准3.1 清洗能力的三个关键指标BPS、PPS、QPS清洗能力是三个维度里最容易被忽略的因为它牵涉的指标不止一个。BPS每秒处理字节数衡量带宽吞吐对应大流量攻击PPS每秒处理包数衡量报文转发能力对应小包高频攻击QPS每秒查询数衡量应用层处理能力对应 CC 类攻击。一台清洗设备同时有这三个上限任何一个被打穿防御就破了。举个例子假设一台设备标称处理能力 100GBPS 上限是 100Gbps但 PPS 上限只有 100 万。如果攻击方用小包打 SYN Flood一个包只有几十字节100Gbps 的带宽大概需要几百万甚至上千万的 PPS设备可能在带宽还没满的时候就已经因为 PPS 超限而瘫痪。所以选型时要根据业务可能遭受的攻击特征确认清洗设备的这三项指标。游戏行业既怕大流量冲击又怕 SYN 小包所以 PPS 指标必须重点看。Web 业务则要重点看 QPS 和会话处理能力。3.2 集群清洗能力与单 IP 防护峰值的区别很多厂商会把“集群清洗能力达 2T”“单 IP 最高可防 1T”并列展示这里容易产生误解。集群清洗能力是整张清洗网络的总吞吐单 IP 防护峰值是你这一条 IP 所能调用的最大清洗规格。当攻击发生时服务商通过调度策略把你这条 IP 引到某个清洗节点节点自身的处理能力、当时是否正处于被其他大攻击占用的状态都会影响实际防御效果。极端情况下如果同机房同时出现多个大流量攻击节点容量被占满你可能实际享受到的清洗能力远低于标称的单 IP 规格。这并不意味着产品不合格而是资源调度的常态。准确做法是大促、上线、关键活动前提前向服务商提交流量保障申请明确那天需要保障的清洗规格让对方给你预留资源。不打招呼就指望攻击来临时自动调度到位风险很高。3.3 CC 攻击是对清洗能力的真实考验很多人以为高防就是抗大流量其实 CC 攻击才是清洗能力的照妖镜。CC 攻击不走带宽一个攻击者用很少的流量就能发数千个请求目标是把后端应用打挂。前两年我遇到一个电商客户正常 QPS 峰值大概在 2000 左右大促期间突然升到 3 万而且请求格式完全合法UA、Cookie 都伪装得像真实用户。清洗设备的规则匹配和会话跟踪瞬间压力暴增CPU 跑到 90%正常请求延迟从 200ms 涨到 3 秒。那一次我们被迫开启了更严格的频率限制虽然挡住攻击但也误伤了一部分真实用户。这类经历让我意识到CC 防御不能只看设备性能还要看规则引擎的智能程度。设备每秒能处理多少条规则、能维护多少会话状态、能不能快速识别低频慢速攻击这些才是真正的“清洗能力”。选型时一定要问清楚支持哪些七层防护策略是否有人机识别、JS 挑战、Cookie 验证等功能而不是只问“能防多少 QPS”。3.4 怎么判断清洗是否生效、有没有误杀接入高防之后不能只看攻击报告还要做独立验证。我习惯在源站侧同时观察两组数据一是高防控制台里的清洗报表看攻击流量趋势、清洗流量占比、封堵事件二是源站自身监控看正常业务流量是否平稳、错误率是否升高。如果控制台显示“清洗了 XX G”但源站监控里业务时延明显上升那要看是不是回源链路出问题或者清洗策略过于激进。判断误杀有一个简单办法攻击前后源站接收到的正常请求成功率应该基本一致。如果攻击结束后正常请求的失败率反而高了大概率是清洗规则把正常请求误判为攻击比如把某些地区的 IP 段、使用特定浏览器的用户、或者某些高频接口请求全部拦了。这时候需要用白名单和精细规则逐步放行而不是一键切换“严格模式”就完事。4. 防御类型四层和七层是两种完全不同的打法4.1 四层防御带宽与报文处理的战场四层防御对应网络层和传输层攻击典型代表包括 TCP SYN Flood、UDP Flood、ACK Flood、ICMP Flood 等。这类攻击的目标是耗尽带宽、连接表或中间设备的处理资源让合法的 TCP 连接无法建立。清洗设备处理四层攻击的手段主要是流量牵引、源认证、畸形报文分析和限速。以 SYN Flood 为例设备收到 SYN 连接请求后不会立刻转发给源站而是先代答 SYN-ACK客户端回应 ACK 之后才建立真实连接这就是 SYN Proxy 机制能够有效屏蔽大量握手不完整的虚假连接。对于游戏、服务端长连接等业务四层防护是底线。裸奔的服务器暴露在公网上哪怕没有任何价值也会被扫描器盯上每天都可能收到几 G 到几十 G 的流量。这个层面建议“基础规格常开”不需要太高端但要确保清洗链路随时在线。4.2 七层防御应用层的攻防博弈七层防御针对的是 HTTP/HTTPS 请求最常见的就是 CC 攻击也叫 HTTP Flood。它的特点是流量不大但请求频率极高或者请求本身消耗大量后端资源比如慢速 POST、频繁查询复杂接口、大量触发搜索和短信接口等。七层防御必须结合业务特征来做。通用规则只能防住明显异常的请求比如同一 IP 每秒请求超过阈值则限速或者用验证码拦截机器人。但真实攻击往往会做 IP 轮换、UA 随机化、模拟正常访问路径单靠限速远远不够。这时候需要更综合的手段包括会话关联分析、浏览器指纹验证、行为模式建模、WAF 规则联动等。4.3 不同业务的防御组合参考防御类型不是配置得越多越好贴合业务才有意义。我把常见业务类型和对应的配置思路整理成一张表业务类型主要攻击风险核心关注指标建议配置方向游戏业务SYN Flood、UDP Flood、登录接口 CC 攻击BPS、PPS、回源带宽四层高规格防护、充足的回源带宽、登录接口七层限速电商/APICC 攻击、爬虫、业务逻辑攻击QPS、会话保持七层 WAF、频率控制、人机验证、业务接口颗粒度限速视频/下载站UDP 大流量、恶意下载流量BPS、带宽成本大带宽接入、四层基础防护、CDN 联动错峰金融/政企混合攻击、低慢速攻击、定向渗透全指标独立清洗节点、定制防护策略、安全团队值守我发现很多团队有一个共同误区把高防 IP 当成“万能盾牌”买了之后既不做 WAF 配置也不做访问控制认为流量进来高防就全挡住了。实际上高防处理的是 DDoS 层面的流量清洗应用层的漏洞利用、逻辑漏洞、数据窃取还需要 WAF、主机防护、数据库审计等多层机制一起协同。高防能挡住大规模洪水但挡不住化了妆的小偷。5. 匹配业务需求的实操路径5.1 第一步梳理业务流量特征和资产清单在向服务商提需求之前先把自家底数摸清楚。你至少需要回答以下问题业务入口是域名还是 IP哪些端口对外开放正常流量的日峰值和时段分布是怎样的请求的潜在地域分布如何历史上有没有被攻击的记录峰值量级多大。这块工作建议由运维主导拉取网关、负载均衡、云监控三处的数据交叉验证。混淆的地方在于前端打了 CDN入口流量看清洗节点流量跟源站实际流量并不一致要分开统计。5.2 第二步确定带宽和清洗规格有了流量基线就可以定规格了。我的经验公式是这样的业务带宽需求取高峰均值 × 1.5 倍冗余防御带宽规格取历史攻击峰值 × 1.2 倍以上如果防御规格低于 100G回源带宽至少不低于业务带宽需求如果防御规格在 100G 以上回源带宽建议直接按业务带宽需求的两倍预留。同时要确认清洗节点的三项指标BPS、PPS、QPS都够用而不是只盯着其中一个。如果业务是游戏类重点确认 PPS如果业务是 Web 类重点确认 QPS 和 CC 防护策略。5.3 第三步配置防护策略、告警和联动接入高防 IP 后需要实际配置的不仅仅是“把流量指过来”。我梳理了几个必须执行的配置项。第一防护对象和端口要完整添加不要只护 80/443把 22、3306、3389 等管理端口和业务端口也纳入防护否则攻击者会直接打裸端口。第二回源方式要提前测试不管是 IP 回源还是域名回源都要确认白名单设置正确避免把源站 IP 暴露在公网解析中。第三清洗模式要从宽松开始运行一段时间后根据误杀率逐步调严。第四告警阈值要单独设置建议设在单 IP 规格的 60% 左右例如购买了 100G 规格则流量达到 60G 就触发最高级别告警留出人工介入的时间。“高防 云主机”组合的团队还要多做一步确认云主机的安全组、防火墙是否放行了高防节点 IP 段别在高防清洗完了之后源站安全组又把合法流量拒之门外。5.4 第四步验证和压测很多团队接入高防后只在控制台看“状态正常”就放心了这是不对的。必须做一次真实流量演练验证三个结论清洗规则是否有效、合法流量回源是否通畅、黑洞触发后的恢复流程是否顺畅。正规做法是通过服务商提供的压测窗口或者在非业务高峰期做受控的测试。不建议在没有任何授权的情况下利用外部工具对业务发起攻击测试既可能违反服务条款也可能殃及同机房其他用户。最稳妥的方案是申请高防服务商协助通过平台内置的模拟攻击功能或联动安全团队进行小规模验证确认防御链路完整可用。5.5 避坑经验五条上面的流程跑完之后我再分享五条从实战里攒出来的经验每一条都是踩过坑的。第一源站 IP 保密是生命线。高防再怎么防如果源站 IP 泄露攻击者可以直接绕过清洗节点打源站。常见泄露途径包括邮件里的网页链接、历史 DNS 解析记录、第三方网站扫描、错误日志中暴露源站 IP。接入高防后务必更换源站 IP并确保回源域名不被公网解析。第二黑洞不是免责牌。当攻击超过防护规格触发黑洞时业务会整体不可用 30 分钟甚至更久。如果业务对连续性要求极高就必须在合同中明确黑洞恢复时间并准备备用 IP 和快速切换 DNS 的预案。第三清洗规则宁可漏杀、不要误杀。误杀带来的损失往往比攻击本身更大因为误杀会直接波及真实用户。我见过一个政务网站因为把扫描器的 UA 全封了结果正常用户中大量使用老旧浏览器的也进不来了投诉电话打爆。默认采用宽松模式根据日志慢慢加规则是更稳妥的节奏。第四CC 防护要回归业务本身。每一个接口、每一种业务场景能承受的请求频率不同。登录接口和商品详情页的限速阈值不应该是一样的。建议建立接口 QPS 基线把高频接口单独设置阈值不要用一个全局规则套所有接口。第五高防不能替代纵深防御。DDoS 清洗只是安全体系的一环WAF、主机安全、入侵检测、备份恢复同样重要。特别是把核心业务放在云上时云安全组件要同步开启形成从网络层到应用层再到数据层的完整防线。最后说回我自己的教训。当初那个游戏客户如果把回源链路当成选型的关键参数来对待后面足以绕一大圈先是被业务高峰期戳穿回源瓶颈然后花了两周时间重新规划源站带宽和专线中间还因为调整 IP 产生了一次版本更新事故。现在每次做高防方案我都会用同样的顺序去核对带宽、清洗能力、防御类型三件事缺一不可防护上限不是纸面数字而是整条链路在压力下真实兜住业务的能力。这套思路对正在评估高防 IP 的团队来说值得直接抄作业。