"这台服务器带宽多少？"商家回答"5M"，很多人会以为每秒能传 5MB 的数据，上线后发现下载速度只有六百多 KB，于是觉得被骗了。其实这里只是单位换算的问题，但带宽这件事远不止换算这么简单：独享带宽和共享带宽的区别、上行和下行的区别、按带宽计费和按流量计费哪个划算、多大的带宽能撑多少访问量、为什么有时候带宽没跑满网站还是慢。这篇文章把这些一次讲清楚，并给出可以直接套用的估算方法。
一、Mbps 与 MB/s：差了八倍
先解决最基本的换算问题。带宽的单位 Mbps 里的小写 b 是 bit（比特），而我们平时说文件大小用的 MB 里的大写 B 是 Byte（字节）。一个字节等于八个比特。除此之外，网络带宽用的是十进制，1 Mbps 等于每秒一百万比特，而文件大小用的是二进制，1 MB 等于 1048576 字节。
所以换算公式是：理论下载速度（MB/s）≈ 带宽（Mbps）÷ 8。更精确一点还要考虑十进制与二进制的差异，但工程上直接用除以八就够用。
1 Mbps 的带宽，理论最大下载速度约等于 1 ÷ 8 = 0.125 MB/s，也就是约 128 KB/s。
10 Mbps 约等于 1.25 MB/s。
100 Mbps 约等于 12.5 MB/s。
1000 Mbps（也就是常说的千兆、1Gbps）约等于 125 MB/s。
反过来验算一个常见场景：你的网页总大小（HTML 加 CSS 加 JS 加图片）是 1 MB，用户在 1 Mbps 的带宽下完整加载需要约八秒；在 10 Mbps 下需要约 0.8 秒。这就是为什么 1 Mbps 的服务器放图片站会非常慢。
还有一层损耗要算进去。网络传输本身有协议开销：以太网帧头、IP 头、TCP 头、TLS 加密的头，加起来每个数据包几十字节的额外开销；TCP 的慢启动和拥塞控制也会让实际吞吐在连接初期低于理论值。所以实际可用的有效吞吐通常是理论值的百分之九十左右，用粗略估算时按八折到九折算比较稳妥。也就是说，1 Mbps 的实测下载速度在 110 到 120 KB/s 是正常现象，不是缩水。
# 在服务器上实测带宽（iperf3，需要另一台机器配合）
# 服务端（在被测机器上）
iperf3 -s
# 客户端（在另一台机器上，替换成服务端 IP）
iperf3 -c 服务端IP -t 30 -P 4 # -P 4 表示 4 个并发流，更容易跑满
# Debian/Ubuntu: apt install iperf3
# RHEL/Rocky: yum install iperf3
# 简单测一下从这台机器下载一个大文件的速度
curl -o /dev/null -w 'speed=%{speed_download} B/s size=%{size_download} B\n' \
http://speedtest.example.com/100mb.bin
iperf3 测的是两台机器之间的最大可用带宽，反映的是网络链路本身的能力。如果担心是业务程序的问题还是网络本身的问题，可以先用 iperf3 跑一遍排除网络因素。
二、独享带宽与共享带宽
这是价格差距最大的一项，也是最容易被含糊其辞的一项。
独享带宽是指这个带宽上限完全归你使用，无论什么时候你都能跑到这个速度（前提是你的机器有能力产生这么多流量，且对端网络正常）。共享带宽是指多台机器共用一条大带宽出口，商家承诺的是"最高可达"或者"端口速率"，实际能跑到多少取决于当前其他用户的占用情况。
举个直观的例子：一台机器接在 100 Mbps 的端口上，但这个端口是几十台机器共享的，高峰期大家都在跑，你能分到的可能只有几 Mbps。所以看到"100M 端口"这种表述时要特别小心，它通常指的是端口速率而不是保障带宽。
判断方法：一是看商家的表述，写"保障带宽""独享"的通常是独享，写"端口速率""最高"的要警惕；二是实测，在业务高峰期和非高峰期各测几次，如果波动很大，很可能是共享；三是看合同条款，正规服务会把带宽保障写进服务水平协议。
云厂商的做法又不一样。多数云服务器采用的是"带宽上限"模式：你买 5 Mbps，就限制在 5 Mbps，超出部分会被限速或者丢包，但这条限制是你独享的，不会被邻居抢走。这种模式介于传统独享和共享之间，它的好处是下限有保障，坏处是峰值无法突破（需要临时升级带宽）。
# 实时查看网卡流量，判断是不是跑到了带宽上限
sar -n DEV 1 # Debian/Ubuntu: apt install sysstat；RHEL 系: yum install sysstat
# 或者用更直观的工具
iftop -i eth0 # Debian/Ubuntu: apt install iftop；RHEL 系: yum install iftop
nload eth0 # Debian/Ubuntu: apt install nload
# 计算当前速率是否接近上限：
# sar 输出里 rxkB/s 是每秒接收的 KB 数，乘以 8 再除以 1000 约等于 Mbps
# 例如 rxkB/s = 600，则速率约 600 * 8 / 1000 = 4.8 Mbps
用 sar 换算是运维中很常用的技巧。看到 rxkB/s 是 600 左右，就知道大约跑到了 4.8 Mbps，如果你买的是 5 Mbps，那就已经接近上限了。这个方法不需要额外工具，随时可用。
三、上行与下行：方向别搞反
带宽是有方向的。从服务器的角度说：
下行（入站、下载、Inbound）是数据从外部流入服务器，比如用户上传文件、服务器从外部下载依赖包、客户端请求报文（请求报文很小，占流量极少）。
上行（出站、上传、Outbound）是数据从服务器流向外部，比如用户下载网页、下载图片、看视频、API 返回 JSON。
对绝大多数网站来说，上行才是主要消耗方向，因为服务器主要是往外发内容。用户在浏览器看到的页面、图片、视频，全都是服务器的出站流量。所以当你说"我的网站用了多少带宽"，通常指的是上行带宽。
这里有个新手常见的误解：很多人在服务器上跑测速，看到下载速度很快，就以为带宽没问题。但测速测的是下行（服务器从外部下载），而你真正需要的是上行。两者在未做特殊配置的情况下通常是对称的，但在很多家庭宽带、部分机房线路上是不对称的，下行远大于上行。这一点在自己用家庭宽带搭建服务时尤其重要，家庭宽带的上行通常被限制得很死。
计费上也要注意：多数云厂商的公网带宽计费只算出方向（出网流量），入方向通常免费，但这不是绝对的，跨区域、跨可用区的流量可能单独计费。做成本预算时要看清楚计费规则。
四、按带宽计费与按流量计费：哪个划算
两种计费模式的本质区别是：按带宽计费买的是"速率上限"，按流量计费买的是"总量"。
按带宽计费（固定带宽）的特点是：付固定的月费，获得一个速率上限，用多用少价格一样。适合流量持续、稳定的业务。优点是成本可预测，不会因为一次流量高峰产生天价账单。缺点是低峰期浪费，高峰期不够用。
按流量计费的特点是：按实际流出的总流量收费，速率上限通常可以设得比较高。适合流量波动大、平均用量低的业务。优点是用多少付多少，弹性好。缺点是成本不可预测，遇到盗刷、爬虫、或者被恶意刷流量时，账单可能非常惊人。
怎么选？可以用一个简单的方法估算临界点。假设按带宽计费是每 Mbps 每月 X 元，按流量计费是每 GB Y 元。如果你买了 5 Mbps 的固定带宽，一个月跑满的理论流量上限是：
5 Mbps ÷ 8 = 0.625 MB/s
0.625 MB/s × 3600 秒 × 24 小时 × 30 天 = 1620000 MB ≈ 1582 GB
也就是说，5 Mbps 的固定带宽，一个月持续跑满理论上能传约 1.5 TB 的数据。当然实际业务不可能持续跑满，通常的实际利用率在百分之十到三十之间。如果你每月实际流量远小于这个量级的三成，按流量计费更划算；如果你长期高负载跑满，按带宽计费更划算。
结合刚才的利用率估算：如果你的平均带宽利用率长期高于百分之三十到五十，固定带宽通常更经济；如果长期低于百分之十，按量计费更省。这个临界值是经验值，具体要用实际账单对比。
防护建议：如果选择按流量计费，一定要配置流量告警和带宽上限。云厂商通常提供带宽封顶功能，设置一个可以接受的上限，超上限后限速，宁可慢一点也不要产生无法承受的账单。同时要注意防范盗刷：静态资源被别的网站盗链、被爬虫反复抓取、被恶意请求攻击，都会让流量暴增。应对措施包括配置防盗链、限制单 IP 请求频率、静态资源走 CDN。
# Nginx 防盗链配置示例（放在 server 或 location 块内）
# 只允许本站和空 Referer 访问图片资源，其他来源返回 403
location ~* \.(jpg|jpeg|png|gif|webp)$ {
valid_referers none blocked server_names *.example.com;
if ($invalid_referer) {
return 403;
}
expires 30d;
}
# 限制单 IP 请求频率，缓解爬虫与恶意刷流量
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
server {
location / {
limit_req zone=perip burst=20 nodelay;
}
}
改 Nginx 配置有风险，建议在修改前备份配置文件，并用 nginx -t 检查语法后再 reload：
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F)
nginx -t && systemctl reload nginx
# 如果 reload 后异常，立即回滚：
# cp /etc/nginx/nginx.conf.bak.$(date +%F) /etc/nginx/nginx.conf && nginx -t && systemctl reload nginx
五、多大的带宽能撑多少访问量
这是最实用的部分，但必须强调：下面所有数字都是经验估算，前提假设是典型的网页站点，页面总大小适中，访问均匀分布。实际情况差异很大，务必以实测为准。
估算的核心公式是：
每秒需要的带宽 = 每秒请求数 × 平均每次响应大小
反过来说，已知带宽反推能支撑的访问量：
每秒可服务请求数 ≈ 带宽（MB/s）÷ 平均响应大小（MB）
具体举例。假设你的页面经过优化后平均响应大小为 200 KB（包含 HTML、CSS、JS 和图片，且图片已经过压缩）。
1 Mbps 带宽，有效速度约 0.11 MB/s（即约 113 KB/s），每秒最多服务约 0.57 个 200 KB 的页面请求。换算成每天：113 KB/s × 86400 秒 ≈ 9.7 GB/天，约能传 5 万个 200 KB 的页面。听起来不少，但这是全天跑满的理论值，实际上访问集中在白天几小时，峰值时刻会非常拥挤。所以 1 Mbps 只适合访问量极小的个人站点或者作为管理通道。
5 Mbps 带宽，有效速度约 0.57 MB/s，每天理论传输约 49 GB，能撑日均几万 PV 的轻量站点，前提是有缓存、页面不大。这是很多小企业官网的起步选择。
10 Mbps，有效速度约 1.14 MB/s，每天理论传输约 98 GB，可以撑日均十万 PV 左右的站点，前提是静态资源做了优化且有缓存。
100 Mbps，有效速度约 12.5 MB/s，每天理论传输约 1 TB，可以支撑相当规模的站点，或者承载较多的文件下载和图片分发。到了这个量级，通常应该考虑用 CDN 分担，而不是继续加大服务器带宽。
上面这些数字要打几个折扣才是现实的：一是访问不均匀，峰值可能是平均值的三到五倍，带宽要按峰值而不是均值配置；二是页面大小差异很大，一个未优化的图片站单页可能几 MB，估算结果会差十倍；三是浏览器会并发请求，一个页面背后有多个资源请求。
反过来有一个很有用的估算角度：先算你的日均 PV 和平均页面大小，得到日流量，再按峰值系数放大，得到需要的带宽。
日流量 = 日均 PV × 平均页面大小
峰值带宽 ≈ 日流量 × 峰值系数 ÷ 峰值时长（秒）
举例：
日均 PV = 50000，平均页面 300 KB
日流量 = 50000 × 300 KB = 15000000 KB ≈ 14.3 GB
假设百分之六十的访问集中在 4 小时内（14400 秒）
峰值带宽 = 14.3 GB × 0.6 ÷ 14400 秒 ≈ 0.0006 GB/s ≈ 0.6 MB/s ≈ 5 Mbps
结论：这个规模选 5 Mbps 起步，留一倍余量选 10 Mbps 更稳妥。
六、为什么带宽没跑满网站还是慢
这是另一个常见困惑。用 sar 看流量远没到带宽上限，但用户反馈网站慢。可能的原因有以下几个，按出现频率排序。
第一，延迟高而不是带宽小。带宽是"管道的粗细"，延迟是"水从一端到另一端的时间"。一个页面如果由几十个资源组成，而每次请求都要几十到上百毫秒的往返，即使总流量很小，累积起来也会很慢。解决方向是减少请求数（合并资源）、开启连接复用（HTTP/2、Keep-Alive）、就近接入（CDN）。
第二，并发连接数受限。服务器或反向代理设置了最大连接数上限，超过的请求要排队。这时候带宽没跑满，但用户要等。
第三，后端处理慢。数据库查询慢、程序逻辑慢，导致请求排队。这时候带宽和 CPU 都不高，但响应时间长。用 curl 测首字节时间（TTFB）就能判断：TTFB 高说明是服务端处理慢，不是带宽问题。
第四，对端网络差。用户在移动网络或者跨运营商访问，链路质量差。这种情况服务器上怎么看都正常，只能通过多地拨测发现问题。
第五，磁盘 IO 瓶颈。静态文件读取慢，导致发送速率上不去。
# 用 curl 区分是带宽问题还是服务端处理慢
curl -o /dev/null -s -w 'ttfb=%{time_starttransfer}s total=%{time_total}s size=%{size_download}B speed=%{speed_download}B/s\n' https://example.com/
# ttfb 高 → 服务端处理慢（数据库、程序逻辑）
# ttfb 低但 total 高、speed 低 → 内容太大或带宽不足
# 查看当前并发连接数与连接状态分布
ss -s
ss -tan state established '( sport = :443 or sport = :80 )' | wc -l
# 查看是否有大量 TIME_WAIT（高并发短连接的常见现象）
ss -tan state time-wait | wc -l
七、带宽优化的实用手段
如果带宽确实成为瓶颈，加大带宽只是最直接也最贵的办法，通常还有更划算的手段。
启用压缩。文本类资源（HTML、CSS、JS、JSON）用 Gzip 或 Brotli 压缩后体积通常能减少百分之六十到八十，这是投入产出比最高的一项。
# Nginx 启用 Gzip（放在 http 块内）
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_compress_level 5;
gzip_types text/plain text/css application/json application/javascript text/xml application/xml image/svg+xml;
配置缓存与过期头。让浏览器缓存静态资源，重复访问就不用再下载。expires 30d 这样的配置能大幅减少重复流量。
图片优化。用 WebP 等现代格式、按显示尺寸生成图片、开启懒加载，往往能把图片流量减少一半以上。图片通常占网页流量的大头。
使用 CDN。把静态资源放到 CDN 上，由 CDN 的边缘节点就近分发，既减少源站带宽压力，又降低用户访问延迟。对于图片站、下载站、以及用户分布广的站点，CDN 的成本通常低于直接加大源站带宽。
动静分离。把静态资源放到独立域名或独立存储上，动态请求留在应用服务器，这样带宽压力和计算压力可以分别优化。
常见问题
Q：1 Mbps 到底有多慢？
理论下载速度约 128 KB/s，扣除协议开销后实际约 110 到 120 KB/s。打开一个 500 KB 的页面大约需要四到五秒，且只能同时服务很少的用户。适合个人学习、管理通道、或者极低访问量的站点，不适合正式业务。
Q：我买了 5M 带宽，为什么测速只有 600 KB/s？
这是正常的。5 Mbps 除以 8 约等于 0.625 MB/s，即约 640 KB/s，再扣除协议开销，实测 600 KB/s 左右完全正常。如果你期待的是 5 MB/s，那是把 Mbps 和 MB/s 搞混了。
Q：带宽大小和 CPU 内存有关系吗？
没有直接关系，但有关联：高带宽通常伴随高并发，高并发需要更多 CPU 和内存来处理连接。所以配了大带宽而 CPU 内存很小，会出现带宽跑不满的情况，因为处理不过来。
Q：按流量计费是不是一定便宜？
不一定。流量持续且量大的业务，固定带宽更划算；流量小且波动大的业务，按量更划算。判断方法是用前面提到的临界点估算，或者先用按量跑一个月看账单，再和固定带宽的月费对比。
Q：怎么防止流量被盗刷导致账单爆炸？
三层防护：一是设置带宽封顶，超上限自动限速；二是配置账单与流量告警，超过阈值立即通知；三是配置防盗链、单 IP 限流、屏蔽恶意爬虫。另外静态资源走 CDN 也能显著降低被刷的风险和成本。
Q：内网带宽和公网带宽要分开看吗？
要。服务器之间的内网通信（比如应用服务器访问数据库、分布式集群内部同步）走内网带宽，通常带宽更高且不计公网费用。只有对外的流量消耗公网带宽。做架构设计时尽量把内部通信放到内网。
总结
带宽的基本换算是除以八：1 Mbps 约等于 128 KB/s 的实际下载速度，扣除协议开销后约 110 到 120 KB/s。看到 Mbps 就除以八换算成 MB/s，这是判断一切带宽问题的起点。
独享带宽有保障但贵，共享带宽便宜但波动大，"100M 端口"这类表述通常指端口速率而不是保障带宽。云服务器的带宽上限模式是下限有保障、峰值需升级，选购时要看清条款。
网站主要消耗的是上行（出站）带宽，因为内容是从服务器发给用户的。测速测的通常是下行，两者在不对称线路上差别很大，这一点在家庭宽带上搭建服务时尤其要注意。
按带宽计费买速率上限、成本可预测；按流量计费买总量、弹性好但成本不可控。判断临界点的经验是：长期平均利用率高于三到五成选固定带宽，低于一成选按量。选按量一定要配带宽封顶和流量告警。
估算访问量的公式是"每秒请求数乘以平均响应大小"，同时要按峰值而不是均值配置，峰值通常是均值的三到五倍。页面大小对结果影响极大，先优化页面往往比加带宽更划算。
带宽没跑满但网站慢，通常是延迟、并发限制、后端处理慢或者磁盘 IO 问题，而不是带宽不足。用 curl 的首字节时间可以一秒判断瓶颈在服务端还是传输环节。
优化手段按性价比排序：启用压缩、配置缓存过期头、图片优化、上 CDN。这些通常比直接加大带宽便宜得多，效果也更明显。
企业QQ咨询
