突发带宽需求不能按固定倍数或总流量平均来拍脑袋，必须按业务类型拆出并发峰值、平均传输对象大小、突发时间窗口和地域分布，才能算出真实需要的带宽数字。
为什么突发带宽按业务评估比按总流量估算更可靠
按总流量反推带宽看起来简单：一天跑了多少GB，除以86400秒，这个算法在稳定下载场景勉强能用，但突发场景会严重失真，突发流量不是均匀分布在24小时里，多数业务突发集中在晚上或者活动开始的前几分钟，同一时间段内，用户请求的对象大小可能相差几百倍，只看总量，会把峰值削平，结果就是带宽买少了扛不住,买多了白花钱。
- 总流量平均会忽略并发尖峰。
- 不同业务的连接数、传输时长、重传率完全不同。
- 按业务拆开评估,能直接对应到扩容动作和计费模式。
突发带宽需求怎么评估？先看业务峰值模型
突发带宽不是玄学，是业务指标的函数，先回答三个问题：谁在什么时间发起请求？请求的对象有多大？必须多久传完？把这三个问题套到具体业务上,带宽需求自然就浮出来。
企业带宽突发需求如何计算：三个关键指标
计算突发带宽，核心指标就三个：并发连接数、平均对象大小、传输时间窗口，公式可以简化为：带宽 ≈ 并发连接数 × 平均对象大小 × 8 / 传输时间窗口，注意单位统一，对象大小按MB或KB，带宽按Mbps，时间按秒，这个公式看起来粗，但对直播、下载、API突发都适用，关键在于并发连接数不能取日平均,必须取峰值时段的连接数。
- 并发连接数：用监控系统取95峰值,不要取均值。
- 平均对象大小：从一个业务周期里抽样,别只看最大或最小文件。
- 传输时间窗口：直播是持续码率，下载是任务完成时限,API是响应超时上限。
把这三个数填进公式，得到的就是该业务的理论带宽底限，再乘一个冗余系数，多数情况下取1.2到1.5之间,用来吸收协议开销和瞬时抖动。
业务场景拆解：直播推流、文件下载、API突发
不同业务，三个指标取值方式完全不一样,下面这张表能帮助快速定位评估重点。
| 业务类型 | 突发特征 | 评估重点 | 带宽估算要点 |
|---|---|---|---|
| 直播推流/视频会议 | 码率跳变，持续时间长 | 上行带宽、同时在线路数 | 峰值码率 × 并发推流数 + 协议开销 |
| 文件下载/软件分发 | 新版本发布时瞬间打满 | 安装包大小、下载完成时限 | 并发下载数 × 包大小 × 8 ÷ 窗口 |
| API接口调用 | 连接数瞬间爆发，对象很小 | 每秒新建连接数、响应体大小 | 峰值QPS × 平均响应体 × 8 |
直播推流和视频会议
直播类的并发连接数相对稳定，但单连接码率可能因为清晰度变化而跳变，评估视频直播突发带宽估算时不要用标称码率，要用实际推流码率峰值，业内专家指出，直播业务的带宽突发通常出现在画面切换和弹幕互动叠加时段,实操上可以这样查：
- 登录流媒体服务器，执行
netstat -an | grep :1935 | wc -l统计当前RTMP连接数。 - 用
iftop -i eth0观察实时网卡流量,找到码率峰值。 - 把峰值码率乘以同时在线推流路数，再加10%到20%的协议开销。
文件下载和软件分发
下载业务的突发更有规律：新版本发布、安装包推送、游戏更新，开始几分钟会集中打满，对象大小通常明确，比如一个安装包2GB，如果1万人在10分钟内同时下载，带宽需求会非常夸张，按业务评估时，先统计历史下载日志里的并发峰值，再看下载完成率要求，如果允许用户排队或P2P分流,带宽需求会大幅下降。
API接口突发调用
API类的对象大小很小，但连接数可能瞬间爆发，比如秒杀、抢票、验证码下发，这种场景只看带宽总量容易误判，更危险的是连接数打满导致端口耗尽，评估时要同时看带宽和每秒新建连接数,可以用Nginx日志统计：
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f2,3 | sort | uniq -c | sort -rn | head
这条命令能看出请求集中在哪几秒,再结合响应体大小算带宽。
按业务评估带宽需求与CDN带宽价格对比
很多企业纠结：突发带宽是自己买服务器带宽硬扛，还是用CDN分流？这里涉及价格对比和业务匹配度，CDN适合静态文件、图片、视频点播、安装包分发，能分散回源压力，价格通常比单独扩容BGP带宽低，但对于直播推流、实时通信、动态API，CDN只能做边缘加速,源站带宽仍然要留足。
- 静态下载型业务：优先CDN,突发越高越划算。
- 动态API型业务：CDN帮助有限,源站带宽和连接数要重点保障。
- 混合型业务：按静态动态比例拆分，静态走CDN,动态走源站。
以北京服务器带宽费用为例，BGP多线带宽是成本大头，突发购买固定大带宽会造成长期闲置，把可缓存的静态流量切到CDN后，源站只需要保留动态部分加回源带宽,回源带宽可以按CDN日志里的回源请求数和对象大小计算。
北京服务器带宽费用和按业务评估的关系
地域对带宽价格影响很大，北京机房BGP带宽单价高于单线，但业务如果集中在华北用户，延迟优势不可替代，按业务评估后，可以把必须低延迟的交互流量放在北京BGP，把可延迟下载的大文件放CDN或单线机房，这样既满足业务，又不为突发部分支付过高的固定带宽费用，行业共识认为，带宽成本优化的前提是先把业务突发模型算清楚,否则容易省了单价亏了体验。
实操步骤：从业务日志到带宽数字的路径
别一上来就算带宽，先做三件事：收集日志、找峰值、拆对象。
- 收集业务日志：Web服务器、流媒体服务器、CDN控制台都打开访问日志，确认日志里有时间、对象大小、状态码、客户端IP。
- 找峰值时段：用日志统计每5分钟请求数和流量总和，画出24小时曲线,多数业务的突发集中在曲线最陡的那一段。
- 拆对象大小：把传输对象按大小分桶，比如0-100KB、100KB-1MB、1MB-10MB、10MB以上,看看突发时段里哪个桶占流量大头。
- 算并发连接数：取峰值5分钟的活跃连接数，可以用
ss -s查看TCP连接总数,或者用日志里同一时间窗口去重IP和会话。 - 套公式验证：带宽 = 并发连接数 × 平均对象大小 × 8 / 传输时间窗口,再用监控流量图交叉验证。
- 确定冗余系数：协议开销、TCP慢启动、重传会吃掉一部分带宽，多数情况下加20%到30%比较稳妥。
容易踩的几个坑
- 用月流量直接除以30天再除以86400秒，这个结果只能算日均带宽,和突发带宽差很远。
- 只看95计费峰值，不分析峰值是由什么业务造成，可能一个大文件下载任务拉高了整体计费,但业务上完全可以限速。
- 把CDN流量和源站带宽混在一起算,回源带宽才是源站真正要扛的量。
- 忘记计算上传带宽，直播推流、文件上传、监控回传的突发往往在上行方向。
- 忽略连接数上限，有些业务带宽没满，连接数先满了,服务照样不可用。
把突发带宽按业务拆开算，不是为了得到完美数字，而是为了知道该买多少、该切多少到CDN、该在哪里限流，抓住并发连接数、对象大小、时间窗口这三个变量,突发带宽就不会成为玄学。
Q&A
突发带宽需求按业务评估时最容易漏掉什么？
最容易漏掉上传方向和连接数上限，很多估算只盯着下行带宽，但直播推流、文件上传、摄像头回传的突发在上行，带宽没满但连接数耗尽也会导致服务不可用,特别是API突发调用场景。
企业带宽突发需求如何计算回源带宽？
回源带宽 = 单位时间内回源请求数 × 平均回源对象大小 × 8 / 时间窗口，先打开CDN回源日志，过滤状态码为200和206的请求，统计峰值5分钟内的请求数和对象大小，回源流量通常远小于边缘流量,但对源站是实打实的压力。
按业务评估带宽需求与CDN带宽价格对比，哪种业务不适合CDN？
动态API、实时通信、数据库交互这类业务不适合完全依赖CDN，CDN主要缓存静态内容，动态请求回源后延迟增加，还可能引入一致性问题，这类业务应按源站带宽评估，CDN只做连接加速，事实是，多数企业采用混合方案：静态对象走CDN，动态交易走源站,最终带宽成本比全源站方案低一截。