上周帮朋友的网校查问题，学生一到下午三点就集体卡在视频加载页——不是服务器宕了，也不是数据库慢了，是带宽被撑满了。后台一看，直播课占了92%的出向流量，而点播回放和文档下载挤在剩下的8%里抢资源，连PPT加载都转圈。
带宽不是越宽越好，而是得会分
很多运营者以为“升级带宽”是万能解药，结果花了三倍钱，卡顿照旧。问题不在总量，而在分配逻辑。比如：一场500人同步直播，1080P码率按3Mbps算，光视频流就要1.5Gbps；如果再混入实时白板、弹幕、语音连麦，实际峰值可能冲到2Gbps以上。这时候，若把所有流量扔进一个出口队列，连后台管理界面的HTTP请求都可能被压住，运维登录都慢半拍。
实战中管用的几招
我们给某K12平台调过一次策略，没加带宽，只改了三处：
- 用Nginx的
limit_rate对非直播类静态资源（PDF、课件ZIP）限速到200KB/s，避免大文件下载瞬间吃光缓冲区； - CDN层按URL路径区分优先级：
/live/走高优先级队列，/vod/走中优先级，/api/走低延迟保障队列； - 在负载均衡器上启用基于连接数的动态权重，当某台边缘节点CPU超75%或丢包率＞0.3%，自动降权30%，把新进直播流导到健康节点。
改完当天，直播首帧延迟从4.2秒压到1.1秒，点播平均加载时间缩短60%。
别忘了“人”的因素
有次凌晨两点收到告警，带宽利用率突升至99%。查日志发现是教务老师批量导出上月所有课堂录像（共2.7TB），任务没设并发上限，一口气发起800个下载连接。后来加了个简单脚本：
#!/bin/bash
if [ $(netstat -an | grep :443 | wc -l) -gt 500 ]; then
echo "High connection detected, throttling export job" >> /var/log/bw-guard.log
systemctl stop class-record-export.timer
fi带宽分配不是纯技术活，它得懂教学节奏——早八点是录播预热高峰，晚七点是直播密集时段，周末白天是家长查报告集中期。把网络资源当成排课表来管，比堆硬件实在得多。