"1Mbps 能撑多少人"是买服务器时被问得最多的问题，也是最容易得到错误答案的问题。常见的回答有两种，都不靠谱：一种说"能撑几百人"，那是把"日访问人数"当成了"同时在线"；另一种说"只能撑一个人"，那是把"严格同时下载"当成了常态。真实答案取决于你怎么定义"人"——是同一秒钟正在传输数据的人，还是一天内来过的独立访客，还是挂着页面在慢慢看的人。
这篇文章把三种口径分别算一遍，给出口径明确、可以自己代入数字重算的方法。所有结论都是量级估算，不是任何形式的承诺，实际承载量一定要用自己的页面体积和访问曲线去代公式。
一、先把单位换算算准
所有推导都建立在这个换算上，算错了后面全错。
1 Mbps 指的是每秒 1,000,000 个比特（注意运营商用的是 1000 进制，不是 1024）：
1 Mbps = 1,000,000 bit/s
= 125,000 Byte/s （除以 8）
≈ 122 KiB/s （按 1024 进制折算）
≈ 125 KB/s （按 1000 进制折算）
行业里常说的"128 KB/s"是把 1 Mbps 粗略按 1024 Kbit 计算（1024 ÷ 8 = 128）得到的近似值，日常估算完全够用。
但实际可用于传输页面内容的速度还要再打折扣。 因为链路上跑的不只是你的网页内容：
- 以太网帧头、IP 头、TCP 头，合计约 40 到 54 字节每个包
- 开启 HTTPS 后还有 TLS 记录层开销，每个记录约 20 到 30 字节
- TCP 慢启动、丢包重传也会吃掉一部分
综合下来，有效载荷大约是标称带宽的 88% 到 95%。做保守估算时，1 Mbps 取 110 KB/s 是个合适的数字。
| 带宽 | 标称字节速率 | 扣除开销后（约 90%） |
|---|---|---|
| 1 Mbps | 125 KB/s | 约 110 KB/s |
| 2 Mbps | 250 KB/s | 约 220 KB/s |
| 5 Mbps | 625 KB/s | 约 550 KB/s |
| 10 Mbps | 1.25 MB/s | 约 1.1 MB/s |
| 50 Mbps | 6.25 MB/s | 约 5.5 MB/s |
| 100 Mbps | 12.5 MB/s | 约 11 MB/s |
二、核心计算：1MB 的页面在 1Mbps 下要多久
这是整个问题里最关键的一个数字，也是最容易让人对"1Mbps 到底有多大"建立直觉的例子。
一个页面完整加载需要传输 1 MB（这里按 1024 进制，1 MB = 1,048,576 字节）：
传输时间 = 1,048,576 字节 ÷ 110,000 字节/秒 ≈ 9.5 秒
如果按标称的 125 KB/s 算：
1,048,576 ÷ 125,000 ≈ 8.4 秒
所以"1MB 的页面在 1Mbps 带宽下大约需要 8 到 10 秒"这个说法是成立的，取中间值可以说约 8 到 9 秒。这还没算服务端生成页面的时间（TTFB）和浏览器解析渲染的时间，实际用户感知会更久。
不同页面体积在 1 Mbps 下的加载耗时：
| 页面体积 | 理论耗时（110 KB/s） | 用户体验 |
|---|---|---|
| 100 KB | 约 0.9 秒 | 流畅 |
| 300 KB | 约 2.8 秒 | 可接受 |
| 500 KB | 约 4.7 秒 | 偏慢 |
| 1 MB | 约 9.5 秒 | 明显慢 |
| 2 MB | 约 19 秒 | 不可接受 |
| 5 MB | 约 48 秒 | 基本不可用 |
这张表比"1Mbps 能撑几人"更有价值，因为它揭示了一个事实：在小带宽下，决定体验的不是并发数，而是单个页面的体积。 把页面从 2 MB 压到 300 KB，同一条 1 Mbps 的线，体验差距是十几倍。
三、三种口径下的承载量
口径一：严格并发（同一瞬间都在下载）
假设 N 个用户同一秒点开页面，带宽被均分，每人拿到 110 ÷ N KB/s。要给每个人都能接受的体验（比如 3 秒内出完），需要：
每人速率 ≥ 页面体积 ÷ 3秒
1MB 页面：需要 ≥ 350 KB/s
1Mbps 只提供 110 KB/s
结论很残酷：在严格并发的口径下，1 Mbps 连一个 1MB 页面的"3 秒内完成"都满足不了，只能是 1 个用户在 9.5 秒内加载完。
如果页面优化到 200 KB：
200 × 1024 ÷ 3 ≈ 68 KB/s 每人
110 ÷ 68 ≈ 1.6
也就是 1 Mbps 大约能同时服务 1 到 2 个正在全速下载 200 KB 页面的用户。这是最保守的口径，对应的是"所有人同时点刷新"这种极端情况。
口径二：阅读型并发（更接近真实）
真实用户不会一直下载。他打开一个页面，花 9 秒加载，然后花几分钟阅读，看完再点下一页。真正占用带宽的时间占比通常只有 5% 到 20%。
设一个用户平均每 3 分钟（180 秒）翻一页，每页 500 KB，那么单个用户的平均速率是：
500 KB ÷ 180 秒 ≈ 2.8 KB/s
1 Mbps 有效 110 KB/s，能支撑：
110 ÷ 2.8 ≈ 39 人
也就是说，在这种"边看边翻"的阅读型场景下，1 Mbps 大致能支撑 30 到 50 个同时在线的用户（这里"同时在线"指 15 到 30 分钟内有活动的用户）。
翻页频率变化对结果影响很大：
| 用户行为 | 单用户平均速率 | 1 Mbps 可支撑在线人数 |
|---|---|---|
| 每 30 秒翻一页（刷资讯） | 约 17 KB/s | 约 6 人 |
| 每 1 分钟翻一页 | 约 8.3 KB/s | 约 13 人 |
| 每 3 分钟翻一页（正常阅读） | 约 2.8 KB/s | 约 39 人 |
| 每 10 分钟翻一页（挂机） | 约 0.85 KB/s | 约 130 人 |
这就是为什么同一个带宽，论坛站能撑上百人在线，而图片瀑布流站几个人就卡。
口径三：日 PV 总量（最常被问到的那个"多少人"）
先把 1 Mbps 满跑一整天能传输多少数据算出来：
1,000,000 bit/s × 86400 秒 ÷ 8 = 10,800,000,000 字节 ≈ 10.8 GB
扣掉协议开销按 90% 算，约 9.7 GB/天。
再除以页面体积得到理论日 PV 上限：
| 页面体积 | 理论日 PV 上限（满跑 24 小时） | 经验日 PV（按 30% 利用率） |
|---|---|---|
| 1 MB | 约 9700 次 | 约 3000 次 |
| 500 KB | 约 19400 次 | 约 5800 次 |
| 300 KB | 约 32000 次 | 约 9700 次 |
| 100 KB | 约 97000 次 | 约 29000 次 |
注意"满跑 24 小时"是做不到的，真实站点有明显的波谷，白天集中夜里清淡，所以经验值按 30% 左右的利用率折算更贴近现实。
如果换算成独立访客（UV），假设每人每次访问看 5 个页面：
3000 PV ÷ 5 ≈ 600 UV/天（1MB 页面）
9700 PV ÷ 5 ≈ 1900 UV/天（300KB 页面）
所以"1Mbps 能支持多少人访问"这个问题，在日 PV 口径下的答案是：优化良好的轻量化站点每天几百到两千独立访客；未经优化、页面动辄 1MB 以上的站点，每天只有几百人就会开始卡。
四、不同带宽档位的经验承载量
把上面的方法推广到各档位，按"页面 300 KB、已开压缩和缓存、峰值系数 5"的假设给出量级参考：
| 带宽 | 峰值并发下载数（约） | 经验日 PV（300KB/页） | 典型适用场景 |
|---|---|---|---|
| 1 Mbps | 1 ~ 3 | 3000 ~ 10000 | 个人博客、API、后台管理、探针 |
| 2 Mbps | 3 ~ 6 | 6000 ~ 20000 | 小型企业官网、低流量应用 |
| 5 Mbps | 8 ~ 15 | 15000 ~ 50000 | 中小型资讯站、论坛 |
| 10 Mbps | 15 ~ 30 | 30000 ~ 100000 | 中型站点、有一定图片的内容站 |
| 50 Mbps | 80 ~ 150 | 15万 ~ 50万 | 较大站点、图片站（需配 CDN） |
| 100 Mbps | 150 ~ 300 | 30万 ~ 100万 | 大型站点、有 CDN 的源站 |
这些数字是量级估算，误差可能达到两倍。它们的用途是选型时排除明显不合适的档位，不能当作容量承诺。真正准确的方法是用你的实际页面体积和访问曲线代入第二节的公式。
五、影响实际承载量的因素
同样的带宽，实际能撑的人数可能相差十倍。下面这些因素按影响力排序。
页面体积（影响最大，线性关系）
承载量与页面体积成反比，这一点没有任何取巧空间。压缩、图片转 WebP、懒加载、去掉不必要的第三方脚本，每减少 100 KB，承载量就提升一截。在小带宽场景下，优化页面的收益远大于加带宽。
CDN 命中率（可以带来数量级的变化）
上了 CDN 之后，源站的带宽需求变成：
源站带宽需求 = 总带宽需求 × (1 - CDN 命中率) + 回源开销
如果静态资源命中率能做到 90%，源站只剩 10% 的流量加少量回源请求，1 Mbps 的源站带宽就能支撑原本需要 10 Mbps 的流量。这是小带宽服务器唯一能做到"以小博大"的手段。
要注意的是：CDN 缓存的是静态内容。如果你的瓶颈是动态页面生成（TTFB 高），CDN 帮不上忙，那属于服务端性能问题。
HTTP/2 与 HTTP/3 的多路复用
HTTP/2 不减少传输的总字节数，但它解决了 HTTP/1.1 的队头阻塞：HTTP/1.1 下浏览器对同一域名通常只有 6 个并发连接，几十个小资源要排队；HTTP/2 在一个连接上多路复用，所有请求并行。
对小带宽的实际意义是：减少排队等待时间，提高带宽利用率，让"水管"被填得更满。 在 1 Mbps 这种小水管上，这个改善是可感知的。
Keep-Alive 长连接
长连接避免了每次请求都做 TCP 三次握手和 TLS 握手，节省的是 RTT 而不是带宽。但对小带宽服务器有个副作用：长连接会占用连接槽位，如果并发连接数上限设得低，用户会遇到"连不上"而不是"慢"。要合理设置 keepalive_timeout，一般 15 到 65 秒，并配合足够的 worker_connections。
动态请求占比
动态请求（PHP、Java、Python 生成的页面）通常响应体不大（几十 KB），但会消耗 CPU 和数据库连接。在 1 Mbps 这种配置下，带宽和 CPU 往往同时是瓶颈：带宽跑满之前，CPU 可能已经先撑不住了。这也是为什么小带宽机器跑动态站更容易"卡死"而不只是"变慢"。
峰值集中程度
前面算的日 PV 是总量，但用户体验由峰值决定。如果 1 万 PV 均匀分布在 24 小时，1 Mbps 完全够；如果 1 万 PV 集中在晚上 8 点那一小时，峰值 QPS 会达到均值的十几倍，1 Mbps 必崩。
峰值系数 = 峰值小时 PV ÷ (日PV ÷ 24)
用自己日志统计这个系数，比套用任何经验值都准：
awk '{print $4}' /var/log/nginx/access.log | cut -c2-15 | sort | uniq -c | sort -rn | head -n 5
其他因素
用户自身的网络。 移动网络下丢包率高，TCP 频繁降窗，同样的带宽传输效率明显更低。
TTFB 占比。 页面加载时间 = TTFB + 传输时间 + 渲染时间。1 Mbps 下传输时间占大头，但如果你的 TTFB 本身就有 2 秒，那瓶颈根本不在带宽。
是否启用懒加载。 首屏之外的图片延迟加载，用户实际触发的传输量可能只有页面总量的 40%，等效于把页面体积砍了一半。
压缩是否生效。 用这条命令确认：
curl -H 'Accept-Encoding: gzip,br' -sI https://www.example.com/ | grep -i content-encoding
没有输出说明压缩没开，白白浪费一半以上带宽。
六、1 Mbps 到底适合什么业务
基于上面的计算，可以给出比较明确的适用边界。
适合的场景：纯 API 服务（响应体几十 KB 的 JSON）、个人博客（文章配图少且已压缩）、企业内部管理系统（用户数固定且少）、监控探针或跳板机、已经把静态资源全部交给 CDN 的站点、开发与测试环境。
不适合的场景：图片站和相册、下载站、视频站、有大量未优化图片的电商站、以及任何单页体积超过 1 MB 且没有 CDN 的站点。
边缘场景的判断方法：如果单页体积能压到 300 KB 以内且上了 CDN，1 Mbps 撑日访问几百到一两千 UV 是可行的；如果单页超过 1 MB 又没 CDN，哪怕每天只有几十个人也会觉得卡。
一个实用的判断流程：
# 1. 测出自己页面的实际传输量
curl -o /dev/null -sS -w '下载字节: %{size_download} B\n总耗时: %{time_total}s\n' \
https://www.example.com/
# 2. 看服务端生成页面的时间（排除服务端瓶颈）
curl -o /dev/null -sS -w 'TTFB: %{time_starttransfer}s\n' https://www.example.com/
# 3. 看带宽是否成为瓶颈（对比 time_total 与 TTFB + 传输耗时）
如果 time_total 远大于 time_starttransfer，说明时间花在传输上，确实是带宽问题；如果两者接近，瓶颈在服务端，加带宽无用。
常见问题
1Mbps 能支持多少人同时在线？
取决于口径。严格同时全速下载：1 到 2 人；正常阅读型并发（几分钟翻一页）：30 到 50 人；按日 UV 算：轻量化站点几百到两千，未优化站点几百就可能卡。问这个问题时一定要先说清是哪种"在线"。
为什么我的站只有几个人访问就很卡？
大概率是页面体积问题而非人数问题。用浏览器 DevTools 看一次访问的总传输量，如果超过 1 MB，在 1 Mbps 上单页就要 8 到 10 秒，一个人也觉得卡。先压缩图片、开 gzip、加缓存头、上 CDN，再考虑加带宽。
加了带宽为什么没变快？
可能是三个原因：瓶颈在服务端（TTFB 本身就有几秒）、存在丢包（用 mtr 看，1% 丢包就能让吞吐大幅下降）、或者页面体积大到加带宽也填不满（2 MB 页面从 1 Mbps 提到 5 Mbps 仍然要 4 秒）。先用 curl -w 分解时间再决定。
并发连接数和带宽是一回事吗？
不是。TCP 连接本身几乎不消耗带宽，1 Mbps 也能维持几千个空闲连接。但一旦这些连接同时传数据，带宽立刻成为瓶颈。所以"能连上但很慢"是带宽问题，"连不上"是连接数或端口问题，两者排查方向完全不同。
1Mbps 跑动态网站是不是完全不行？
不是不行，但要控制页面体积并加缓存。PHP、Python 生成的 HTML 通常只有几十 KB，传输本身很快，真正的风险是 CPU 和数据库。这类站点在小带宽机器上更常见的失败模式是 CPU 跑满、内存吃紧，而不是带宽跑满。
这些估算数字准吗？
是量级参考，误差可能达到两倍，不能作为容量承诺。准确做法是用自己的页面平均体积、峰值系数和期望加载时间代入本文公式，并且上线后持续观察云监控的带宽曲线，按实测数据调整。
总结
- 单位换算是地基：1 Mbps = 125 KB/s 标称，扣掉 TCP/TLS 等协议开销后有效约 110 KB/s（行业常说的 128 KB/s 是 1024 进制的粗略近似）。
- 关键数字要记住：1 MB 的页面在 1 Mbps 下需要 8 到 10 秒；页面压到 300 KB 则约 2.8 秒，压到 100 KB 约 0.9 秒。在小带宽下决定体验的是单页体积，不是人数。
- 三种口径分别算：严格并发 1 到 2 人、阅读型并发 30 到 50 人、日 PV 口径轻量化站点 3000 到 10000 PV（约几百到两千 UV）。1 Mbps 满跑一天约 9.7 GB 有效流量。
- 影响因素按权重排序：页面体积（线性反比）> CDN 命中率（可带来数量级变化）> 峰值集中度 > HTTP/2 多路复用与长连接 > 动态请求占比 > 用户网络质量。
- 上 CDN 是小带宽服务器唯一能"以小博大"的手段，90% 命中率等于把源站带宽放大十倍；但它只缓存静态内容，动态页面慢属于服务端问题，加带宽和 CDN 都解决不了。
- 选型时用本文公式代入自己的实际数字，上线后以云监控带宽曲线为准，使用率超过 70% 就该扩容或优化。所有表格中的承载量都是量级估算，不是承诺。
企业QQ咨询
