美国高防服务器中，“防御带宽”和“业务带宽”通常指向网络链路上的两个不同能力：前者用于承载、识别并清洗攻击流量，后者用于承载清洗后到达服务器的正常业务流量。两者不是简单相加的关系，也不能仅凭“防御带宽更大”判断网站实际可用吞吐量。

对采购或技术负责人而言，最重要的选择原则是：如果主要担心攻击流量压垮入口，应重点核对防御能力的作用位置、触发方式和覆盖范围；如果更关心文件下载、接口并发或网页访问速度，则必须单独确认业务带宽、端口上限和清洗后的可用带宽。只有攻击规模、业务峰值和服务商口径处于同一比较维度时，参数才有可比性。

先区分两个带宽的作用范围

防御带宽：处理攻击流量的能力

防御带宽通常表示高防节点或清洗网络能够接收、识别和处理的攻击流量规模。它主要针对以下类型的网络压力：

• 以大量请求或数据包为特征的流量型攻击；
• 通过多个来源同时发起的分布式攻击；
• 以连接、协议或异常请求为特征的部分网络层、传输层攻击。

在典型的高防架构中，外部访问不会直接全部进入服务器，而是先经过高防入口或清洗节点。系统对流量进行识别，将被判定为攻击的部分拦截或丢弃，将相对正常的部分转发至源服务器。

因此，防御带宽的关注点是“入口能够处理多大规模的异常流量”，而不是“服务器能够持续向用户发送多少正常数据”。

需要注意的是，服务商对“防御带宽”的定义可能并不完全一致。有的按清洗中心可承载的峰值描述，有的按单个业务实例、IP、端口或防护组描述，也有的区分基础防护和临时扩容能力。采购时不能只看一个数字，必须追问该数字对应的统计对象和实际生效位置。

业务带宽：正常业务到达服务器或用户的能力

业务带宽通常指服务器用于正常业务通信的网络资源，例如：

• 用户访问网站时的页面、图片和接口数据传输；
• 应用向客户端返回文件或视频内容；
• 客户端向服务器提交表单、上传文件或调用接口；
• 源站与其他业务系统之间的正常数据交换。

它更接近业务实际能使用的网络吞吐能力，但“业务带宽”在不同服务商的产品说明中也可能存在不同口径。有些方案按公网端口速率描述，有些按带宽包、峰值带宽、共享带宽或流量计费描述。还要确认该带宽是源服务器直连公网的能力，还是经过高防清洗后转发到服务器的业务通道能力。

在高防场景下，用户最终感受到的访问速度，往往取决于清洗后可转发的业务带宽，而不是防御带宽本身。防御带宽很大，并不代表业务下载速度一定同样大。

两者为什么不能直接相加

可以把一次访问路径简化为：

用户请求 → 高防入口 → 流量识别与清洗 → 业务转发 → 美国高防服务器

在这条路径中，防御带宽和业务带宽处于不同环节：

例如，一个方案声称具备较高的防御带宽，但业务转发通道存在单独上限，那么攻击被清洗后，正常流量仍然需要通过业务通道进入服务器。反过来，业务带宽较大，也不意味着遭遇大流量攻击时入口一定能够稳定处理攻击流量。

更准确的理解是：

• 防御带宽决定“攻击流量进入防护体系后，系统能处理到什么范围”；
• 业务带宽决定“被允许通过的正常流量，能够以什么规模继续传输”。

如果服务商明确表示两者共享同一出口资源，也不能直接将两个参数相加，而应确认在攻击状态和非攻击状态下各自的可用上限。

判断参数时要先统一口径

先确认统计对象

同样写成“带宽”，可能分别指：

• 单个公网IP；
• 单个端口；
• 一组防护IP；
• 单台服务器；
• 一个业务实例；
• 多个实例共享的防护资源；
• 整个清洗集群的理论能力。

这些对象不在同一层级。将“整个防护集群的能力”与“单台服务器的业务端口”直接比较，会得出错误结论。

采购时应要求对方明确回答：

1. 防御带宽是针对单个IP、单个端口，还是整个防护资源池？

2. 业务带宽是独享、共享，还是按实际使用动态分配？

3. 多个业务是否共用同一防御和转发资源？

4. 参数是峰值、保证值、端口速率，还是计费口径？

5. 攻击期间，业务带宽是否会被单独限制或动态调整？

再确认方向和测量位置

带宽存在方向差异。用户访问服务器是入站请求与出站响应的组合，上传业务和下载业务的流量方向也不同。部分产品只对某一方向设置上限，或者使用双向合计口径。

因此不能只问“带宽是多少”，还要确认：

• 是入站、出站，还是双向合计；
• 是高防入口处测量，还是服务器网卡处测量；
• 是清洗前流量，还是清洗后流量；
• 是瞬时峰值，还是某一统计周期内的平均值；
• 是否包含攻击流量，还是只统计正常业务流量。

对于文件下载、图片分发、接口返回等出站占比较高的业务，重点通常是确认清洗后的出站业务带宽。对于上传、数据采集或大文件接收业务，则还要确认入站方向的限制。

最后确认单位和计费含义

带宽参数可能以网络速率表达，也可能以流量额度表达。前者描述某个时刻能够传输的速率上限，后者描述统计周期内可以传输的数据总量。两者不能相互替代。

例如，固定速率较高但存在流量超额规则的方案，和按流量使用但没有固定速率承诺的方案，适合的业务类型并不相同。比较美国高防服务器时，应把以下内容分别列出来：

按业务场景判断优先级

以网站和API访问为主

这类业务通常同时需要攻击防护和稳定的正常请求转发。判断时不能只看防御带宽，还要确认：

• 清洗后能够保留多少正常连接；
• 业务转发是否有独立上限；
• 高峰期间是否会对连接数、并发请求或带宽进行限制；
• 攻击流量被拦截后，正常请求是否继续走同一业务通道。

如果业务请求本身数据量不大，带宽可能不是唯一瓶颈，连接处理、请求速率和应用层防护同样需要核验。但这不意味着可以忽略业务带宽，因为页面资源、接口返回或批量请求仍会形成实际吞吐压力。

以文件下载或大流量分发为主

这类业务更应优先确认清洗后的业务出站能力。防御带宽主要解决“攻击是否会把入口打满”，而业务带宽解决“正常文件能否持续发送给用户”。

如果只提高防御带宽，却没有同步确认业务转发能力，可能出现攻击可以被清洗，但正常下载仍受业务通道限制的情况。此时应询问是否存在单连接、单IP、单端口或全实例级别的发送限制，并区分持续吞吐与短时峰值。

以高频攻击风险为主、正常业务流量较小

如果业务访问量不大，但经常面临大规模异常流量，防御带宽、清洗能力和攻击状态下的业务保留策略会更重要。此时不宜用业务带宽大小替代防御能力评估。

不过，仍需确认高防入口是否覆盖实际使用的IP和端口，以及清洗后的流量是否能够回源。只有攻击拦截范围与业务暴露面一致，防御参数才有实际意义。

常见的错误理解

“防御带宽越大，服务器下载越快”

不成立。防御带宽主要描述攻击处理能力，下载速度还受到业务带宽、服务器端口、应用处理能力、文件读取能力以及用户侧网络条件影响。没有在相同测试节点、相同文件、相同并发和相同时间条件下进行实测，不能从防御参数推导下载性能。

“业务带宽越大，就不需要高防能力”

也不成立。业务带宽解决正常通信的吞吐问题，不能自动替代攻击识别和清洗能力。异常流量可能在业务通道、服务器连接资源或上游入口处形成压力。

“防御带宽加业务带宽就是总带宽”

通常不成立。两者往往处于不同的处理环节，可能还存在共享出口、转发上限或策略限速。正确做法是分别确认攻击状态和正常状态下的有效能力。

“标注的防御数字就是一定能防住的攻击规模”

不能这样理解。防御效果还取决于攻击类型、协议特征、攻击持续时间、目标端口、清洗策略和防护覆盖范围。防御带宽是容量指标，不等同于对所有攻击的结果承诺。

用同一维度进行方案比较

比较两个美国高防服务器方案时，可以建立一张内部对照表，但每一项都要使用相同口径：

这里的关键不是寻找参数最大的方案，而是避免比较“不同定义下的数字”。如果一个方案提供的是清洗集群峰值，另一个提供的是单实例业务端口速率，直接排列大小没有决策意义。

采购前的核对路径

第一步：列出业务真实流量

先记录业务的主要通信方向和峰值特征，包括：

• 正常访问主要是网页、API、下载还是上传；
• 峰值发生在短时间突发，还是长时间持续；
• 是否存在大文件、批量接口或高并发连接；
• 需要保护的是哪些IP、域名和端口；
• 攻击时最不能中断的是哪些业务。

如果没有实际监控数据，可先以业务日志、服务器网卡统计和应用监控作为基础，但不能把单次短时观察直接当成长期性能结论。

第二步：分别询问两个带宽的定义

要求服务商将防御带宽和业务带宽分开说明，并明确单位、方向、统计位置和限制条件。尤其要确认“防御带宽”是否只是理论清洗容量，“业务带宽”是否为清洗后的实际转发能力。

第三步：核对攻击状态下的行为

重点询问发生攻击后：

• 防护是否自动生效；
• 是否需要人工切换；
• 清洗后是否仍保留正常业务；
• 是否会触发限速或临时封禁；
• 超出能力范围时如何处理；
• 业务恢复和解除防护的条件是什么。

这些问题决定了防御参数能否转化为可用的业务连续性能力。

第四步：在可控条件下验证业务带宽

如果进行性能测试，应记录测试节点所在网络、测试时间、服务器配置环境、测试文件或接口、并发方式、测试持续时间和样本数量。还要分别记录正常状态与防护状态，避免把不同条件下的数据放在一起比较。

测试结果只能说明特定时间、特定节点和特定环境下的表现，不能直接推导所有用户、所有地区或所有攻击场景的长期结果。若服务商无法说明测试口径，单一峰值截图也不适合作为采购的唯一依据。

适用与不适用的选择边界

更适合优先关注防御带宽的情况，是业务对异常流量敏感、攻击可能造成入口拥塞，而正常业务吞吐要求相对有限。此时应把防御范围、清洗策略和攻击期间的业务保留能力放在前面。

更适合优先关注业务带宽的情况，是业务以持续下载、文件传输或大响应接口为主，且攻击风险可控或已有其他防护体系。此时应重点核对清洗后转发速率、出站方向和共享资源限制。

如果两类需求同时存在，不能在两者之间简单二选一，而应采用“双条件核对”：防御能力必须覆盖实际暴露面，业务带宽也必须满足正常峰值；任何一项只看宣传数字、不确认作用范围，都可能造成方案错配。

最终可以按以下路径做判断：先用实际业务流量确定业务带宽需求，再确认防御带宽对应的防护对象和攻击处理范围，随后核对清洗后的转发上限，最后用相同测试条件验证正常状态与防护状态的差异。这样比较美国高防服务器时，看到的就不再是两个容易混淆的带宽数字，而是分别对应“能否处理攻击”和“能否承载业务”的完整能力边界。