TG咨询做直播时，日常平均流量往往最容易误导决策。凌晨或非活动时段看起来只用了很少带宽，并不代表晚间开播、多人连麦或活动开始时仍然够用。合理的服务器带宽选择，应先看单路视频码率，再看同时推流数量、协议开销、重连情况以及观众流量由谁承担。
先分清：推流带宽和观看带宽
直播系统通常包含推流端、接入服务器和分发端。主播使用 OBS Studio 等软件，通过 RTMP 或 SRT 将视频发送到服务器，这部分主要消耗服务器的上行带宽。如果服务器还直接把视频发送给每位观众，则会额外消耗下行带宽；如果使用专门的分发网络，源站通常负责接收和转发，观众流量则由边缘节点承担。
举例来说，一路 1080p 直播的实际视频码率可能在约 4—8 Mbps，取决于帧率、画面运动量、编码器和平台限制。若有 4 路同时推流，基础上行需求约为 16—32 Mbps，还要为协议封装、音频、重传和瞬时波动预留空间。这里的数值只是估算范围，体育画面、游戏画面通常比固定机位讲话更容易出现码率波动。
按峰值而不是平均值估算
计算推流端需求
- 列出最高同时开播数，而不是一个月平均开播数。
- 记录每路视频的目标码率、音频码率和分辨率，分别计算总和。
- 在总和基础上增加约 20%—40% 的缓冲，用于连接抖动、协议开销和重连。
- 再检查网卡、虚拟化平台和机房线路是否存在共享带宽限制。
计算公式可以写成：所需上行带宽≈同时推流数×单路码率×安全系数。比如 6 路、每路约 6 Mbps 的直播，基础值是 36 Mbps；若按 1.3—1.5 的安全系数估算，接入端最好准备约 47—54 Mbps 的稳定上行，而不是只购买刚好 36 Mbps 的套餐。
考虑突发时段
开播瞬间、广告投放、赛事开始和大量用户同时进入房间，都会形成短时峰值。可以在业务高峰连续观察至少一个完整活动周期，重点记录 95 分位带宽、最高瞬时带宽、丢包率和重传次数。若只有月平均值，没有峰值记录，服务器带宽选择就缺少关键依据。
自建分发与接入转发，配置完全不同
| 架构 | 主要带宽压力 | 适用条件 | 注意事项 |
|---|---|---|---|
| 仅接收推流 | 服务器上行 | 平台或其他系统负责播放分发 | 重点检查接入稳定性和并发推流数 |
| 源站转发到分发节点 | 源站上行与节点回源 | 有多个播放区域或多平台输出 | 需评估回源连接数和跨地域线路 |
| 服务器直接服务观众 | 下行带宽随观众数增长 | 观众规模较小、架构简单的场景 | 高并发时成本和稳定性压力明显 |
如果每位观众都从源站获取一条约 5 Mbps 的视频流，100 位同时观看就可能带来约 500 Mbps 的理论下行需求，实际还要考虑播放器码率切换、多个清晰度和协议开销。此时仅增加推流接入带宽并不能解决播放卡顿，必须重新检查分发架构。
协议、编码和线路也会改变结果
RTMP 兼容性较好，适合常见推流接入；SRT 对不稳定网络和较远距离传输更有容错空间，但仍会受到延迟、丢包和缓冲设置影响。选择协议时，不应只比较带宽套餐，还要确认服务器端软件、推流工具和播放链路是否支持。
同一分辨率下，H.264、H.265 或 AV1 的编码效率不同，画面内容也会影响实际码率。压缩效率提高可能减少网络压力，却会增加编码端或服务器的计算负担。若服务器需要转码多个清晰度，还要单独评估处理器、显卡加速和磁盘读写，不能把所有问题都归结为带宽不足。
上线前的执行检查
- 按照最高同时推流数制作码率表，并把音频和安全余量计入总量。
- 在预计高峰前进行持续推流测试，观察丢包、延迟、重连和带宽曲线。
- 分别测试单路推流、多人同时推流以及源站向分发节点转发的情况。
- 为带宽使用率设置告警，例如接近购买上限、连续丢包或重连次数异常时通知管理员。
- 保留升配或临时扩容方案，避免把长期套餐容量按最理想状态固定下来。
常见问题
平均带宽只有峰值的一半，可以按平均值购买吗？
不建议。直播更怕短时拥塞和重连，至少应按高峰同时推流数计算，并预留合理余量。
增加观众后，推流带宽一定要同步增加吗？
不一定。若观众通过分发网络获取内容，源站主要承受推流和回源压力；若服务器直接向观众发送视频，下行带宽会随并发连接明显增加。
带宽足够但画面仍然卡顿，问题可能在哪里？
还可能是丢包、抖动、编码器过载、转码资源不足、线路跨地域延迟或播放器缓冲策略导致。
怎样判断服务器带宽选择是否合理？
看高峰期的带宽利用率、丢包率、重连次数和端到端延迟，而不是只看账单中的月平均流量。结论应来自完整高峰测试。
因此，直播业务的服务器带宽选择不能只围绕日常平均流量，而应以最高同时推流数、实际码率、分发架构和峰值余量共同决定。
