带宽评估需聚焦瞬时峰值而非平均值，重点监控95分位带宽值、1秒粒度峰值速率和并发连接数突增幅度；应分级限速、软硬结合缓冲突发流量，并通过运营错峰引导缓解压力。
带宽评估不能只看平均值，得盯住瞬时峰值。视频直播和大文件下载这类场景的冲击不是“持续高”，而是“突然炸开”——比如开播前30秒涌入500人、课程结束瞬间200人同时下载课件，这种脉冲式流量最容易击穿带宽底线。
抓准真实峰值指标，别被平均数骗了
路由器后台显示的“日均带宽占用40%”，对这类场景几乎没参考价值。重点要看三个实时指标：
- 95分位带宽值：剔除每月最高5%的尖峰后，剩下的最高值。这是IDC和云厂商计费依据，也最贴近你实际要扛住的压力
- 1秒粒度峰值速率：普通监控工具默认采样是5秒或30秒，会平滑掉真实爆发。要用支持1秒采样的工具（如SmokePing或Zabbix自定义脚本）捕获那一瞬间的MB/s飙升
- 并发连接数突增幅度：直播推流+观众拉流+后台上传，三股连接同时涌进来。单看带宽数字容易误判，比如6000kbps码率×500人=3Gbps，但若这500人集中在8秒内建立连接，TCP三次握手和首帧加载会带来额外2–3倍瞬时负载
区分流量类型，做分级限速而非一刀切
QoS策略在这里不是用来“卡死”，而是“理顺”。把不同业务按优先级划档，让关键链路不被挤爆：
- 最高优先级：直播推流上行（保障主播不卡顿）、核心API调用（登录、支付）——固定预留带宽，不参与争抢
- 中优先级：观众拉流（可接受轻微缓冲）、课件预加载——用WRED（加权随机早期检测）在拥塞前主动丢包，避免全局TCP重传风暴
- 低优先级：后台自动备份、员工非工作视频下载——直接限速到1Mbps以下，让其“能连但难用”，既不断网也不抢资源
留出弹性冗余，但别盲目堆带宽
纯靠买更大带宽来扛冲击，成本高且治标不治本。更有效的做法是“软硬结合”：
- 硬件侧：在出口网关部署带宽突发缓冲池（Burst Buffer），允许短时超限（如10秒内允许达承诺带宽的200%），系统自动平滑释放，避免瞬时丢包
- 软件侧：直播端启用分片预加载+边缘节点就近分发；大文件下载强制走断点续传协议（HTTP Range），并限制单IP并发连接数≤3
- 运营侧：错峰引导——直播预告里明确“前10分钟高清画质优先保障”，大文件下载页面加提示“推荐非高峰时段获取”，把部分压力从技术层转移到用户行为层
不复杂但容易忽略。
