服务器带宽被打满怎么办?先判原因,再分三方处置

带宽突然被打满,先看流量方向、来源分布、接口集中度和业务活动,分清是攻击、爬虫、业务暴增还是内部传输,再按自己、托管机房、上游线路三方分工处置。

要点速览

• 带宽打满先看进出方向、来源IP、请求接口、业务活动四点再动手
• 原因大致分攻击、爬虫、业务暴增、内部大文件传输四类
• 自己管限速关端口缓存扩容,机房管端口流量与带宽调整
• 上游大流量防护通常需另行确认或采购,不要默认已包含
• 托管前问清带宽类型、超峰计费、防护边界、通知流程、临时调整

服务器带宽突然被打满,不要急着扩容,也不要急着认定是被攻击。先花几分钟判断原因:看流量是进方向还是出方向、来源 IP 是集中还是分散、请求是否集中在某个接口、同一时间有没有业务活动。判断清楚之后再分工:自己负责服务器和应用层面的限速、关端口、缓存与临时扩容;托管机房负责端口流量查看、限速或临时调整带宽,以及合同范围内的网络侧协助;上游线路和第三方防护负责超出机房能力的大流量清洗,这部分通常需要另行确认或采购,不能默认已经包含。下面按判断、处置、托管前准备、事后复盘四步展开。

先判断:带宽被打满是哪一类原因

带宽被打满只是一个结果,背后的原因不同,处置方式差别很大。一个常见的错误是看到流量图冲顶就立刻封 IP 或者扩带宽,结果封掉了真实用户,或者扩出去的带宽又被同样的流量吃满。建议先看四个观察点:

1. 进出方向。入方向打满,多见于外部请求或攻击流量涌入;出方向打满,多见于大量下载、视频或文件分发、被爬取,也可能是服务器被入侵后对外发包。方向不同,排查对象完全不同。
2. 来源 IP 是否分散。少数几个 IP 贡献了大部分流量,通常是爬虫、某个合作方的批量调用,或者内部同步任务;来源极度分散、地域杂乱、且大多数连接没有正常业务行为,更接近分布式攻击。
3. 请求是否集中在某个接口。如果流量集中在某个下载地址、某个查询接口或某个图片目录,往往是被定向抓取或某个功能被刷;如果连应用层日志都看不到对应请求,流量可能停在网络层,属于协议层面的泛洪。
4. 同一时间有没有业务活动。先问一圈:有没有刚上线的活动、推送、版本更新、合作方投放,有没有人在做数据库备份、跨机房同步或大文件拷贝。很多次“被打满”最后查下来是自家行为。

把这四点组合起来,大致能落到四类原因里:

• 攻击流量:来源分散、请求无业务意义、与业务活动无关,常伴随连接数异常。
• 爬虫或批量调用:来源相对集中、请求集中在少数接口、多为出方向占用。
• 业务暴增:与活动或推送时间吻合,请求分布与平时相似只是量级放大,转化和登录等业务指标同步上涨。
• 内部大文件传输:来源或目标是自家其他服务器、备份节点,时间点与计划任务吻合。

这一步的意义在于,后面找谁、做什么,都取决于这里的判断。判断不清时,至少把流量图、连接数、访问日志的样本截下来,后面找机房时用得上。

自己能做的:服务器和应用层面的四件事

服务器在自己手里,应用也是自己写的,这一层的动作响应快,也是机房替代不了的。

• 限速。在应用或反向代理层对单 IP、单接口设置请求频率和下载速度上限,优先保住登录、下单等核心接口。对确认的爬虫来源可以单独限流,而不是一刀切封禁。
• 关闭暴露端口。检查服务器上对公网开放的端口,数据库、缓存、管理后台、调试端口不应直接暴露。有些出方向异常流量来自被利用的服务,关掉入口比事后清理更省事。
• 缓存或静态化。如果是业务暴增或被集中抓取,把热点页面、图片、下载文件做缓存或静态化,能明显降低回源压力。能放到分发网络上的大文件,就不要每次都从托管服务器出。
• 临时扩容。确认是真实业务增长,而且限速和缓存仍不够时,再考虑临时增加带宽或服务器。扩容之前先确认费用口径,避免活动结束后账单出乎意料。

如果判断为内部大文件传输,处理就简单得多:把备份、同步任务挪到业务低谷,或者给这类任务单独限速。如果怀疑服务器被入侵后对外发包,先隔离、保留现场,再按安全事件流程处理,不要急于重装。

托管机房能做的:端口、带宽和网络侧协助

服务器托管在机房,带宽和交换端口在机房一侧,有些信息和操作只有机房能提供。联系机房时,建议把情况一次讲清:受影响的 IP、开始时间、进出方向、你的初步判断、已经做过的动作。这样值班人员能更快对上号。

一般可以向机房请求以下几类协助:

• 端口流量查看。机房侧交换端口的流量图,能帮你确认流量是在服务器入口就已打满,还是在应用层才出现瓶颈,也能对照你自己的监控是否一致。
• 限速或临时调整带宽。业务暴增时,可询问能否临时调高带宽;遇到异常流量拖累业务时,可询问能否在端口侧做限速。具体能不能调、多久生效、如何计费,以合同和机房实际能力为准。
• 网络侧协助范围。例如对特定来源做访问控制、在流量过大时对受攻击 IP 采取保护措施等。不同机房能做的事情和边界不一样,有的动作会影响该 IP 的可用性,做之前要和机房确认后果。

需要注意的是,机房的协助是在网络侧,它看不到你的应用逻辑,也不替你判断某个请求是不是正常用户。应用层面的识别和取舍,仍然需要你自己的团队来做。

上游线路与第三方防护:先确认是否另行采购

当攻击流量的规模超过机房入口或你所购带宽能承受的范围时,在服务器和机房端口上做限速已经不够,流量在到达之前就把线路占满了。这时需要在更上游处理,常见做法是借助线路侧的清洗能力,或者把业务入口切换到专门的防护服务上。

这部分有两点要事先想清楚:

• 是否包含在现有服务里。很多托管合同里的带宽并不包含大流量防护,防护通常是单独的服务,有自己的容量、计费和生效方式。不要默认“托管了就有人帮我挡攻击”。
• 切换需要多久。如果需要改解析、换入口 IP 或调整路由,中间会有生效时间。事先准备好切换方案,比事发时临时谈要从容得多。

对业务连续性要求高的系统,建议在托管签约前就把这一层谈清楚,哪些攻击由谁处理、超出范围后的升级路径是什么。

托管前先问机房五个问题

带宽被打满时手忙脚乱,很多是因为签约时没问清。下面五个问题,建议在选机房、签合同前逐条拿到书面答复:

1. 带宽是独享还是共享。共享带宽在高峰时可能受其他客户影响,独享带宽的容量归属更清楚。也要问清标称带宽是指入方向、出方向还是两者。
2. 超出峰值如何计费。是硬限在购买值,还是允许突发后按某种口径结算;结算口径怎么取值,账单能否看到明细。
3. 是否有防护能力及其边界。机房自身能提供哪些防护,能处理到什么程度,超出部分怎么办,是否需要另购。
4. 遇到攻击的通知与工单流程。机房发现异常后是否主动通知,通过什么渠道,夜间和节假日有没有人响应,客户发起工单后多久有人处理。
5. 能否临时调整带宽。活动、促销或应急时能否临时上调,需要提前多久申请,结束后如何恢复。

这些问题没有标准答案,关键是答案要写进合同或服务说明,事发时双方按同一个口径办事。

事后复盘:把这次的经过留成记录

带宽恢复之后,建议在几天内完成复盘,不然细节很快就模糊了。复盘可以按这份清单走:

• 时间线。异常开始、发现、联系机房、采取各项措施、恢复的时间点,各由谁执行。
• 流量图。自己监控的流量图和机房端口流量图放在一起对照,标出各项措施生效的时刻。
• 变更记录。事发前后有没有上线、配置修改、计划任务变化,排除或确认自家原因。
• 判断依据。当时凭什么判断为攻击、爬虫或业务暴增,事后看判断是否准确,哪些信息当时缺失。
• 改进项。限速策略、端口暴露、缓存方案、告警阈值、与机房的联络方式,哪些要调整,谁负责,何时完成。

复盘中经常遇到的难点是:现在大部分业务流量是加密的,流量图能看到量,却很难看清是什么样的连接在占用带宽。对数据中心场景,可以考虑借助加密流量可见性手段辅助定位,在不解密内容的前提下看清连接的分布与行为特征。润迅的洞流 Refract就是用于看清数据中心加密流量的工具,它提供的是辅助观察的线索,哪些流量属于异常、要不要处置,仍由运维和安全人员判断。关于这类手段能看到什么、看不到什么,可以参考加密流量可见性分三层:能看到什么、看不到什么、谁来判断。

行动建议:平时把分工谈清,事发时按步骤走

归纳成可执行的几步:

1. 先为自己的服务器准备好流量、连接数和访问日志的监控,保证事发时能快速看到方向、来源和接口。
2. 写一页应急手册:四个观察点怎么看,自己能做的四件事由谁执行,机房联络方式和需要提供的信息。
3. 和托管机房逐条确认前面的五个问题,把带宽类型、超峰计费、防护边界、通知流程和临时调整写进合同或服务说明。
4. 对业务连续性要求高的系统,提前评估上游防护是否需要单独采购,并准备好切换方案。
5. 每次事件结束后按复盘清单留档,逐步把判断依据和处置动作固定下来。

润迅在深圳自建并运营前海云与田心两个数据中心:前海云位于宝安,按 T3+ 标准建设,有 1400+ 机柜;田心位于罗湖,有 400+ 机柜。两处均提供机柜托管与网络带宽服务,带宽类型、计费口径、网络侧协助范围和防护选项,以具体合同和方案为准。如果你正在评估托管或想核对现有带宽方案,可以先看网络与带宽和机柜托管的说明,也可以拨打业务热线 400-854-5566,把上面五个问题直接拿来问。

→ 联系润迅,聊聊你的场景,获取适合的方案