CDN回源月流量怎么算？用播放时长、下载量和峰值系数推算带宽需求

一个视频与文件下载站点，每天产生10万次视频播放，平均每次观看12分钟，实际平均码率为3Mbps；同时每天完成2万次下载，平均每个文件800MB。按30天计算，用户侧月交付流量约为1290TB。若视频和下载的字节缓存命中率分别为95%、90%，且未命中的内容直接由源站提供，基础回源月流量约为88.5TB，而不是1290TB。

这88.5TB对应约273Mbps的月平均回源带宽。用4倍峰值系数、再预留30%容量，初步得到约1.42Gbps的源站出口需求。不过，这个结果只适用于峰值时缓存命中率没有明显下降的情况。新内容发布、缓存失效或下载集中爆发，都可能让实际回源峰值超过这一估算。月流量决定传输了多少数据，峰值带宽决定源站能否及时把这些数据送出去，两者必须分别计算。

以下数据均用于容量规划示例，不代表具体业务实测或产品承诺。

一、先用播放时长和下载量算出用户侧月流量

统一单位，避免把Mbps和MB/s混用

本文采用十进制口径：1GB＝1000MB，1TB＝1000GB；1字节＝8比特。因此，100Mbps理论上对应12.5MB/s的数据传输速率，但实际应用吞吐还受协议开销、网络质量和服务端处理能力影响。

如果文件大小来自操作系统显示的GiB，应先换算成GB：1GiB约等于1.074GB。不能把800MiB直接当成800MB，也不能把100MB/s当成100Mbps。

本例的业务条件如下：

“有效播放次数”需要与平均观看时长采用同一统计口径。如果次数包含刚打开就退出的会话，观看时长却只统计完整观看用户，乘出来的流量会偏大。

视频月流量：码率乘以实际观看时间

单次视频播放的数据量可以按以下公式估算：

单次播放流量GB＝平均码率Mbps × 实际观看秒数 ÷ 8 ÷ 1000

本例中，12分钟为720秒：

单次播放流量＝3 × 720 ÷ 8 ÷ 1000＝0.27GB。

因此：

• 每日视频流量＝100000 × 0.27＝27000GB，即27TB。
• 每月视频流量＝27 × 30＝810TB。

这里应使用实际交付的平均码率，而不是某一档清晰度的标称码率。采用自适应码率时，可以按各档实际播放时长加权；音频也应包含在平均媒体码率中。

播放器提前下载了用户最终没有观看的分片，这部分仍会产生网络流量。如果已经采用CDN实际交付字节数，就不需要再次添加预加载系数；如果只按观看时长推算，则应单独估计预加载、拖动播放和重复请求的影响。

下载月流量：文件大小乘以实际传输次数

下载业务的基础公式是：

下载月流量GB＝月完成下载次数 × 平均文件大小GB

800MB为0.8GB，本例下载月流量为：

20000 × 30 × 0.8＝480000GB，即480TB。

两类业务合计如下：

对下载业务，“完成下载次数”只是基础估算。用户下载到一半取消、重新下载、断点续传发生重复区间，都可能使实际传输量高于“文件大小×成功次数”。

视频与下载还存在一个重要区别：视频通常由码率决定单用户即时需求，下载则由文件大小和允许完成时间共同决定需求。 同样是800MB文件，要求一分钟内下载完成，与允许十分钟完成，对带宽的要求明显不同。

二、CDN回源月流量要按字节命中率计算

用户收到的流量，不等于源站发送的流量

CDN缓存命中时，内容由缓存节点提供；未命中时，CDN需要向上游获取内容。在“边缘节点未命中就直接访问源站”的简化模型下：

基础回源月流量＝视频月流量 × 视频字节未命中比例＋下载月流量 × 下载字节未命中比例

本例视频字节命中率为95%，下载字节命中率为90%：

• 视频回源量＝810 × 5%＝40.5TB。
• 下载回源量＝480 × 10%＝48TB。
• 合计回源量＝40.5＋48＝88.5TB。

值得注意的是，下载业务的用户侧流量小于视频业务，但其回源量反而更大。原因不是下载次数多，而是下载文件的字节命中率较低。

容量规划不能只看业务流量占比，还要看各业务的回源比例。

为什么请求命中率不能直接代入流量公式

请求命中率按请求个数统计，字节命中率按数据量统计。两者可能差很多。

例如，一个统计窗口内有990个10KB小文件请求命中，另有10个1GB文件请求未命中。请求命中率达到99%，但命中的数据只有约9.9MB，未命中的数据却达到10GB。若用99%推算回源流量，会严重低估大文件带来的压力。

因此，两类指标应分别使用：

源站可能出现“流量不高，但QPS很高”，也可能出现“请求不多，但大文件把出口占满”。这两种情况需要不同的容量配置。

多级缓存和额外拉取会改变回源比例

如果CDN在边缘节点与源站之间还有上级缓存，边缘未命中不一定真正触达源站。多个节点对同一内容的请求，也可能通过回源合并减少重复拉取。

反过来，全文件回源、预取、缓存刷新、重试和多个节点重复填充缓存，可能增加源站实际发送的数据量。用户只读取一段文件，源站却提供了更大的数据范围，简单公式也会出现偏差。

实际规划宜按以下方式校准：

回源月流量≈同口径业务交付量 × 实际触达源站的字节比例＋未包含在前项中的额外回源量

这里的字节比例应在源站边界核对，不能把边缘命中率直接当成整个CDN体系的卸载比例。如果已经统计了源站实际发出的字节数，预取、重复拉取等流量通常已经包含其中，不应重复加算。

例如，在本例88.5TB基础回源之外，另有相当于基础值5%的独立预热和重复拉取流量，则月回源约为92.93TB。这个5%只是演示修正方法，真实业务应由日志和流量计量确定。

三、把月流量换成Mbps，再估算峰值

月平均带宽只表示长期平均负载

30天共有2592000秒。按十进制口径：

月平均带宽Mbps＝月流量GB × 8 × 1000 ÷ 2592000

本例88.5TB为88500GB：

88500 × 8 × 1000 ÷ 2592000≈273.15Mbps。

同理，用户侧1290TB对应约3981.48Mbps，即3.98Gbps的月平均交付带宽。

还可以反向记住一个换算：

持续1Mbps传输30天，约产生324GB流量；持续1Gbps传输30天，约产生324TB流量。

这意味着月平均273Mbps的业务，并不需要全天保持273Mbps。它可以在夜间较低、晚间较高，只要整月传输总量一致。

峰值系数适合初筛，但必须说明口径

初步预算可以使用：

规划带宽＝月平均带宽 × 峰值系数 × 容量预留系数

峰值系数应定义为“指定时间粒度下的峰值带宽÷同周期平均带宽”。一分钟峰值、五分钟峰值和一小时峰值不是同一个指标，不能混用。

在本例中，以4倍峰值、30%容量预留计算：

273.15 × 4 × 1.3≈1420.37Mbps，即约1.42Gbps。

没有历史数据时，可以把2倍、4倍、8倍作为不同压力情景进行推演，但它们只是试算参数，不代表所有视频或下载业务都适用。

30%预留是出口容量余量，并不是实际流量增加30%。它不会让88.5TB自动变成115.05TB，也不能替代故障切换、链路限速和突发拥塞分析。

更可靠的峰值计算：分别估算业务峰值与忙时命中率

“月平均回源带宽×峰值系数”隐含了一个条件：忙时的回源比例没有明显变化。新片上线、软件更新集中发布时，这个条件往往不成立。

可以先分别计算用户侧业务峰值，再使用忙时字节未命中比例。以同一源站承接两类业务为例：

如果两类业务峰值重叠，合计回源峰值约为1666.67Mbps。再预留30%：

1666.67 × 1.3≈2166.67Mbps，即约2.17Gbps。

这比前面的1.42Gbps高出约53%。差异来自业务峰值系数和忙时命中率，而不是单位换算。

月流量按整月回源比例算，源站带宽按同一峰值窗口内的实际回源比例算。月度高命中率不能替代忙时命中率。

若视频与下载峰值并不重叠，可以用同一时间轴上的合计曲线确定需求，不必机械相加；但只有月报、没有同步监控数据时，不宜直接假设峰值错开。

四、比较缓存、集中发布和增长空间带来的变化

命中率改善，对回源的影响并不线性直观

保持用户侧1290TB月流量不变，并统一使用4倍峰值系数和30%预留，可以比较不同缓存状态：

这张表只用于同口径比较，并不代表实际峰值一定按4倍变化。

其中一个容易忽略的关系是：视频命中率从95%提高到98%，只提高了3个百分点，但未命中比例从5%降至2%，对应视频基础回源量减少60%。在高命中区间，少量百分点变化也可能显著影响源站负载。

缓存优化还要结合内容形式判断。视频分片的缓存键、过期时间、个性化地址，下载文件的版本路径、Range请求处理，都可能影响命中效果。不能只为了提高命中率而忽略更新及时性和访问权限要求。

集中发布：月流量不大，短时带宽仍可能很高

某个800MB更新包在20分钟内被下载1万次，这一窗口的交付量为：

10000 × 0.8＝8000GB。

20分钟为1200秒，窗口平均用户侧带宽为：

8000 × 8 × 1000 ÷ 1200≈53333Mbps，即53.33Gbps。

如果这一窗口有20%的交付字节需要源站提供，则窗口平均回源带宽约为10.67Gbps；如果实际触达源站的比例降到2%，则约为1.07Gbps。

这里算出的仍是20分钟平均值，窗口内更短时间的峰值可能更高。相同下载量、相同文件大小，发布集中程度和缓存状态不同，源站需求就可能相差一个数量级。

因此，更新包、热门视频等发布型业务，应单独建立发布窗口模型，核对预热覆盖、实际回源比例和请求合并效果，而不是只按日均下载量规划。

业务增长应加在对应变量上

以较细化计算得到的2.17Gbps为当前规划值，如果播放量、下载量都增长50%，而码率、文件大小、峰值分布和命中率不变，规划带宽约增长至3.25Gbps。

但增长未必只来自用户数：

• 播放次数不变，平均观看时间从12分钟增加到18分钟，视频月流量增加50%。
• 视频平均码率从3Mbps增加到4.5Mbps，观看时长不变，视频流量同样增加50%。
• 下载文件从800MB增加到1.2GB，下载次数不变，下载流量增加50%。
• 业务量不变，但发布更集中，月流量可能几乎不变，峰值带宽却明显上升。

增长空间应分别考虑业务量、单次数据规模和时间集中度，不能统一用一个用户增长比例替代。

五、据此选择源站带宽、计费方式与服务器容量

固定带宽、流量计费和峰值计费关注点不同

完成流量与峰值估算后，才能比较不同交付方式。具体能力和计费规则应以服务商合同及产品说明为准。

95计费一般依据合同约定的采样值排序处理，但它不等于可以随意免费使用短时高峰，也不表示物理链路没有上限。账单统计方式与实际吞吐能力必须分开核对。

固定1.5Gbps出口如果持续满速运行30天，理论传输量约486TB；业务实际回源88.5TB时，不能把486TB当成月账单流量。前者是容量上限推算，后者是实际用量估算。

比较成本时，还应分清源站公网出流量、CDN向用户交付流量、存储读取请求和预热等费用，不能只比较一个带宽单价。

针对视频点播和大文件下载的CDN源站需求，A5数据提供香港、美国、日本等地区的物理服务器资源，涵盖不同带宽与线路方案。Xeon、AMD EPYC平台搭配大内存及SSD或NVMe存储，可用于内容分片读取、回源请求处理和业务后台运行；香港存储系列与日本CTG的大容量硬盘方案，则为视频库、安装包和历史版本文件提供存储基础。

源站出口够大，不代表内容一定送得出去

源站还可能受网卡、公网链路、磁盘、连接数和应用处理能力限制。购买2Gbps带宽，但虚拟网卡或共享出口只能提供更低吞吐，容量模型就无法兑现。

不同源站形态应核对不同瓶颈：

以2Gbps为例，应用有效吞吐大约对应250MB/s的数据读取。热文件可能由内存缓存提供，冷文件则可能依赖存储读取；单块磁盘顺序读取的结果，也不能直接代表大量文件混合读取的能力。

下载并发还可以转换成出口需求。500个并发下载，每个平均需要4Mbps，用户侧合计约2Gbps；其中究竟多少落到源站，仍要看忙时实际回源比例。

直播则不能直接照搬本文点播模型。多节点可能复用同一路直播内容，也可能因频道数、分片更新和缓存策略形成不同回源负载，需要另算源流数量、码率及节点拉取方式。

带宽档位应围绕可交付能力选择

若初步需求为1.42Gbps，而细化忙时模型达到2.17Gbps，直接选1.5Gbps可能不足。应根据可提供的档位，比较覆盖2.17Gbps以上需求的方案，并核对余量是否已包含在计算中，避免重复加余量或完全不留余量。

若业务同时有更新包集中发布，还应单独验证发布窗口。稳定状态下的2Gbps级需求，不代表冷缓存发布时也只需要这一水平。

“共享大带宽”是否适用，取决于能否接受忙时吞吐变化；对完成时间敏感、发布窗口明确的业务，应优先核对可保障吞吐，而不是只看端口标称速率。

六、交付验收要让流量、峰值和业务效果对应起来

一套可用的验收口径，至少应覆盖以下步骤：

1. 核对计量方向。 明确回源流量是源站向CDN发送的数据，还是包含其他公网出流量；确认GB、GiB口径，以及是否包含协议开销。
2. 同时记录月度与忙时数据。 分别观察视频、下载的交付字节量、实际回源字节量和请求数，使用一致的时间窗口计算峰值。
3. 验证热缓存与冷缓存。 热缓存场景检验稳定期能力，冷缓存或内容发布场景检验缓存填充时的源站压力。
4. 核对源站瓶颈。 同时观察出口吞吐、磁盘读取、CPU、连接数和请求错误，判断限制来自带宽还是服务器处理能力。
5. 以业务结果验收。 视频关注启动时间、卡顿和分片响应；下载关注完成时间、有效吞吐和失败重试，不能只看带宽曲线达到多少。

对于“CDN回源月流量怎么算”，可先用播放次数、实际观看时长和平均码率计算视频流量，用下载次数和文件大小计算下载流量，再分别乘以实际回源字节比例，并补入尚未覆盖的额外拉取量。对于“需要多大带宽”，则应进一步使用忙时并发、集中发布窗口和峰值回源比例计算。

本例的88.5TB月回源、1.42Gbps初步规划值，以及细化后的2.17Gbps忙时规划值，都依赖既定条件。播放时长、码率、文件大小、峰值重叠程度、缓存层级和忙时命中率中的任何一项变化，都可能改变带宽结论。 扩容或发布前重新代入这些变量，比只沿用上个月的总流量更有判断价值。