在线教育平台带宽分配：卡顿、抢流、学生掉线，背后其实是这套逻辑

上周帮朋友的网校调服务器，学生一上直播课就卡成PPT，后台看带宽利用率才60%，可视频流就是断断续续。查了一圈发现，不是带宽不够，是分配方式太‘憨’——所有请求一股脑塞进同一条管道，高清课、文档下载、弹幕、签到API全挤在一块儿抢带宽。

带宽不是越宽越好，而是要‘分得巧’

比如一个500人同时在线的直播课，假设平均每人需要1.2Mbps（720p中等画质），理论峰值要600Mbps。但实际中，只有约30%学生真正在看高清流，其余人在切屏、看回放、传作业或网络本身就不稳。硬按峰值配带宽，成本翻倍，还浪费资源。

常见分配策略怎么落地？

我们团队在三个网校项目里试过几种轻量级方案，不依赖昂贵CDN调度系统，靠Nginx+Lua+基础QoS就能见效：

http {
    limit_rate 200k;  # 默认限速200KB/s，防大文件下载霸占通道
    map $arg_type $rate_limit {
        "live"     1500k;
        "vod"      800k;
        "doc"      100k;
        default    200k;
    }

    server {
        location /stream/ {
            limit_rate $rate_limit;
        }
    }
}

这段配置让不同业务走不同速率通道：直播流放开到1500k，点播回放控在800k，PDF课件下载压到100k。上线后，直播卡顿率从12%降到2.3%，学生反馈‘终于能看清老师写板书了’。

更进一步：按用户状态动态调速

有次遇到晚高峰，大量学生用手机连WiFi上课，但路由器信号弱，TCP重传多。我们加了个小判断：检测客户端RTT > 300ms 或丢包率 > 5%，自动把该连接的视频码率从1200k降到600k，并推送‘已为您切换流畅模式’提示。没加新硬件，只是在信令服务里加了十几行Go代码：

if rttMs > 300 || lossRate > 0.05 {
    client.SetBitrate(600)
    client.PushNotice("流畅优先已启用")
}

这招对三四线城市家庭宽带特别管用——他们不是没带宽，是WiFi穿墙后只剩一半有效吞吐。

带宽分配不是玄学，它藏在Nginx日志里、藏在学生掉线前3秒的TCP窗口大小变化里、也藏在你给教务系统API悄悄限流50QPS的那个下午。别总盯着总带宽数字，低头看看流量是怎么被‘喂’出去的。