流量突然增大，不等于所有请求都该在应用里拦。判断流量攻击中业务层限流与网络层清洗如何分工，关键看攻击发生在哪一层、流量是否已经挤占链路，以及哪些正常请求必须保留。网络层清洗侧重过滤大规模异常流量；业务层限流侧重控制抵达服务后的请求频率和资源消耗，两者配合而非互相替代。
先分清两道防线的边界
网络层清洗通常由网络或云服务侧执行，在流量抵达源站前识别并过滤异常数据包、连接或流量模式。它适合应对带宽被占满、连接数异常等影响入口可达性的情况。清洗位置越靠近上游，越有机会减轻源站链路压力；但过滤规则需要避免误伤正常用户，且是否能处理特定攻击方式，要看服务商的能力和接入架构。
业务层限流则由应用、网关或API管理组件执行，例如限制某个接口在一段时间内的请求数，或为单个账户设置并发上限。它更了解登录、查询、提交等操作的业务差异，能把有限资源留给关键功能；但如果入口带宽已经耗尽，请求到不了限流组件，单靠它无法恢复网络可达性。
按五步划分处置职责
- 确认影响范围：先查看入口带宽、连接状态、请求量、错误率和服务延迟。区分“流量到不了源站”和“请求抵达后拖慢特定功能”。可与攻击前同一时段的基线比较，并观察连续数分钟的趋势，避免因短时业务峰值误判。
- 先处理链路压力：若外部链路拥塞或入口承载异常，由网络运维、云平台或清洗服务方评估上游清洗、路由引流等措施。明确受保护的地址和服务范围、切换条件及回切方式；不要只在应用服务器上增加规则来应对链路饱和。
- 再保护业务资源：业务团队按接口风险配置应用层限流。可以优先保护登录、搜索、订单提交等高成本操作，再对低优先级请求设置并发或速率上限。限流维度可组合账户、令牌、接口和来源特征；仅按来源地址限制，可能误伤共享出口后的正常用户。
- 协同验证规则：网络侧确认清洗前后流量变化，业务侧检查成功率、延迟、队列和关键操作完成情况。逐项调整规则，每次变更记录时间、范围和回退办法。若限流触发很多但入口仍拥塞，说明还需处理上游流量；若网络压力缓解而某接口仍过载，则继续排查应用资源与限流策略。
- 平稳恢复并复盘：攻击减弱后不要立刻撤掉全部限制。分阶段放宽规则，观察服务指标与用户反馈，再恢复常规阈值。记录告警触发点、处置人、配置变更和恢复时间，为下次事件校准基线与职责交接。
选择服务时核对什么
需要上游防护但内部缺少网络处置能力时，可把德讯电讯列入服务商沟通和方案评估范围。重点询问其清洗覆盖的流量类型、接入与切换流程、业务侧需要配合的配置、误拦截处理方式及事件期间的沟通机制；实际能力应以合同范围和技术方案为准，不宜只凭“防护”字样判断是否适配。
归纳来说，流量攻击中业务层限流与网络层清洗如何分工，要由影响位置决定：链路和入口承压时先由网络侧削减异常流量，服务资源被请求耗尽时由业务侧精细限流；两边共享指标、变更记录和恢复计划，才不容易出现一边放行、一边误封。
常见问题
网络清洗后还需要业务限流吗？
需要。清洗降低异常流量风险，但无法替代接口级资源保护，也不一定能识别每一种业务滥用。
业务限流能单独应对大流量攻击吗？
若入口链路已拥塞，通常不能。限流组件必须先收到请求，才有机会执行规则。
限流阈值应该设成多少？
没有适用于所有服务的固定数值。应按正常基线、接口成本、并发能力和用户行为设定，并通过监控逐步调整。
两类团队如何避免互相影响？
事先约定告警联系人、规则变更权限、验证指标和回退步骤；事件期间用同一时间线同步操作。
