10M带宽的服务器能支持多少人同时观看视频？

这是一个非常经典但也非常“坑”的问题。直接给一个数字是不负责任的，因为“10M带宽”和“同时观看视频”这两个概念背后，藏着大量的变量。

作为在云计算和运维领域摸爬滚打多年的人，我见过太多人因为低估了带宽需求，导致服务器崩盘、用户投诉不断。

先说结论：
如果是指国内主流云厂商（如阿里云、腾讯云）的公网带宽，且视频为普通清晰度（720P左右），10M带宽大约能支撑 5-8 人 同时流畅观看。如果是高清（1080P），可能只有 2-3 人。如果是超清或4K，基本只能支持 1 人 甚至无法流畅播放。

下面我从技术角度拆解为什么是这个数，以及你需要注意的“陷阱”。

1. 核心计算公式：带宽 vs 码率

首先，你要搞清楚单位。

• 带宽（Bandwidth）：通常云厂商说的“10M”，指的是 10 Mbps (Megabits per second)。注意是 bit（比特），不是 Byte（字节）。
• 下载速度：10 Mbps ≈ 1.25 MB/s（兆字节每秒）。这是理论极限值。
• 视频码率（Bitrate）：视频文件播放时每秒需要传输的数据量。

关键公式：
$$ text{并发人数} = frac{text{总带宽}}{text{单路视频码率}} $$

不同清晰度的典型码率参考：

• 360P/480P（手机看大概够用）：码率约 0.5 – 1 Mbps
• 720P（主流清晰度）：码率约 2 – 3 Mbps
• 1080P（高清）：码率约 4 – 6 Mbps
• 4K（超清）：码率约 15 – 25 Mbps+

代入计算：

• 场景A（720P，码率取3Mbps）：$10 / 3 approx 3.3$ 人。考虑到TCP/IP协议开销、网络抖动，实际稳定在 3人 左右。
• 场景B（480P，码率取1Mbps）：$10 / 1 = 10$ 人。但考虑到头部信息、重传机制等损耗，实际可能 8-9人。
• 场景C（1080P，码率取5Mbps）：$10 / 5 = 2$ 人。

所以，别指望10M带宽能搞个大直播，它更适合小范围的内部分享或低并发的点播。

2. 你必须知道的“隐形杀手”：协议开销与HTTP头

很多新手会算：10M / 2Mbps = 5人，然后自信满满地部署上去，结果发现3个人就开始卡。为什么？

1. TCP/IP 协议开销：数据包在网络传输中不仅仅是视频数据本身，还有IP头、TCP头、以太网帧头等。这部分通常会占用 10%-15% 的有效带宽。
2. HTTP 请求开销：如果是普通的 HTTP 直出（没有做CDN提速），每个客户端连接都需要建立 TCP 握手、TLS 握手（HTTPS）、发送 HTTP 请求头。这些元数据虽然单次不大，但在高并发下会消耗大量 CPU 和内存，间接影响带宽吞吐效率。
3. 缓冲与重传：网络不可能完美。丢包会导致重传，这会瞬间挤占可用带宽。为了保证不卡顿，播放器通常会预加载几秒的视频，这也会临时占用更多带宽。

因此，安全系数建议打 0.7-0.8。即：有效可用带宽约为 $10 times 0.8 = 8$ Mbps。

3. 架构层面的真相：你是怎么提供视频的？

这个问题最容易被忽视的一点是：你的视频是从哪里发出来的？

情况一：源站直出（最惨的情况）

如果你的视频文件存在服务器本地磁盘，通过 Nginx/Apache 直接响应请求：

• 瓶颈不仅是带宽，更是 I/O 和 CPU。
• 10M 带宽对于现代多核 CPU 来说很小，但如果并发稍高，Nginx 的文件读取 I/O 会成为瓶颈。
• 更致命的是，静态文件服务不适合做视频流分发。即使带宽够，用户体验也会很差，因为没有断点续传、没有自适应码率。

情况二：使用对象存储 + CDN（推荐方案）

如果你把视频放到 OSS/COS，并开启 CDN：

• 带宽不在你的源站服务器上，而是在 CDN 节点上。
• 你的源站只需要处理少量的控制信令（如鉴权、列表查询），实际的大流量由 CDN 边缘节点承担。
• 这时候，10M 带宽对你来说毫无意义，因为你几乎不产生大流量。你需要关注的是 CDN 的带宽套餐和回源带宽。

情况三：私有化部署视频流媒体服务（如 SRS, ZLMediaKit）

如果你是在搭建自己的直播平台：

• 10M 带宽依然受限于上述的物理限制。
• 但你可以采用 FLV/HLS 分片传输 的方式。HLS 将视频切成多个小片段（TS文件），客户端按需加载。这种方式对带宽的瞬时压力较小，但增加了延迟。

4. 国内云厂商的特殊限制

在国内，云服务器的带宽策略非常特殊：

1. 按固定带宽计费：你买的 10M 是峰值带宽。一旦超过，要么限速，要么产生高额流量计费（取决于套餐类型）。
2. 上行带宽限制：有些云服务器默认只保障下行带宽，上行带宽可能被限制或需要单独购买。视频上传和推流主要吃上行带宽，务必确认你的实例是否支持满速上行。
3. QoS 与公平共享：在某些廉价机型或共享型实例上，云厂商可能会对你的网络进行 QoS 限制，导致你在深夜网络空闲时速度快，白天高峰期速度慢。

5. 给开发者的实用建议

如果你真的需要让多人同时观看视频，请不要试图用一台 10M 带宽的 ECS/CVM 硬扛。以下是更专业的做法：

1. 转码与多清晰度：

   • 不要只提供一份原始视频。使用 FFmpeg 或云转码服务，生成 360P、480P、720P、1080P 多个版本。
   • 前端播放器根据当前带宽自动切换清晰度。这样，10M 带宽可以支撑更多人看低清晰度视频。

2. 启用 CDN：

   • 这是解决带宽问题的终极方案。CDN 节点遍布全国，用户就近获取内容，极大降低源站压力。
   • 对于视频业务，CDN 几乎是必需品。

3. 使用流媒体协议而非 HTTP 直链：

   • 不要用 <video src="movie.mp4"> 直接链接。
   • 使用 HLS (.m3u8) 或 FLV 直播协议。它们支持分片、断点续传、自适应码率，体验好得多。

4. 监控与告警：

   • 设置带宽使用率告警。当带宽使用率达到 80% 时，及时扩容或优化策略。

总结

10M 带宽的服务器，在纯源站直出的情况下，保守估计只能支持 3-5 个 720P 用户同时观看。

如果你想做得更专业、更稳定、用户体验更好，请立刻转向 对象存储 + CDN + 多清晰度转码 的架构。不要在小带宽上纠结人数，那是架构选型的问题，不是带宽计算的问题。