带宽、吞吐率、速率、利用率：网络性能四指标一次讲清

先想一个特别常见的场景：你家宽带套餐写的是500M，可你用下载工具拉文件，撑死也就跑个45MB/s。这时候有人告诉你是路由器不行，有人说是服务器限速，还有人说是运营商偷偷限了带宽。到底谁说了算？答案不是你猜的任何一个，而是这四个指标共同决定的：带宽、吞吐率、速率与利用率。这篇文章就用大白话把这四个概念拆开揉碎，讲清楚它们分别是什么、单位怎么换算、实际怎么测、出问题怎么查，全程不堆公式，尽量让你看完就能用。

这是给谁看的？刚学网络基础的小白、做运维想补理论的同学、以及被各种“网络术语”绕晕的普通人。你要是已经能随手算出TCP窗口和延迟的关系，那这篇文章对你来说偏基础，但用来查漏补缺也合适。我尽量用“高速公路”和“水管”这类生活类比来解释，保证你即使没有任何网络基础，也能在几分钟内把这几个高频概念装进脑子里。

1. 四兄弟是谁：从一条高速公路说起

1.1 带宽：道路的设计通行能力

带宽这个词，在计算机网络里指的是链路能够承载的最大比特速率，单位通常是bps（bit per second，每秒比特数）。它是一根网线、一个光口、一段无线信道在物理层面上的“设计上限”，这个值由介质、调制方式、信号编码等因素决定，几乎是固定的。你去看光猫或者路由器的包装盒，写的100M、1000M、2.5G，指的就是这个口能支持的最大带宽。

把它理解成一条高速公路的设计参数就特别容易记。带宽不是“车速”，而是这条路的车道数和设计通行能力的组合。车道越多、路面越好，单位时间内能通过的车就越多。就算这是一条限速120km/h的八车道高速，同一个时刻能容下的车流总量也是有限的，这个“单位时间能通过的最大车流量”就是带宽。注意，我说的是“能通过”，而不是“实际通过了”——带宽是一个理论值，是链路宣称自己最多能提供多少容量。

带宽的数值在物理层就基本定死了。比如一条千兆链路，带宽就是1000Mbps（准确说是1000,000,000 bps）。你没法通过软件把它“调高”，除非换设备、换线缆、换标准。所以很多人在路由器后台看到“带宽控制”就觉得能突破物理带宽，这是个很常见的误解。这里的“带宽控制”只能做队列调度和流量整形，把有限容量按策略分给不同设备，并不能改变链路本身的能力上限。一会儿在常见问题里我再详细说。

这里还要补一个容易撞上的概念混淆点：模拟通信时代，“带宽”指频带宽度，单位是Hz；数字通信时代，大家口里的“带宽”更常指比特速率，单位是bps。考试题里偶尔会拿老定义来考你，看到“信道带宽为1kHz”这种表述，要知道它和我们现在聊的“千兆带宽”不是同一个维度。

1.2 速率：设备本身的额定速度

速率这个概念比带宽要“窄”一点，通常指的是某个设备端口或链路标准的名牌参数。比如你网卡上是10/100/1000Mbps自适应，这个“1000Mbps”就是网卡端口的速率；比如路由器LAN口标着2.5G，这个2.5G也是速率。带宽和速率在很多场合会被混着说，但在考试和严格的技术文档里，它俩不是一个层面的东西。

带宽是“整条链路能承载多少流量”的能力描述，速率是“某个具体端口/设备标称能跑多快”的额度描述。打个比方，带宽像是这条路的“总设计车流量”，而速率是“每一辆车出厂铭牌上写的最高时速”。你可以有一辆车极速能到300km/h，但它上面那条路设计车流量就那样，堵起来照样走不动；反过来，路再宽，你开一辆小排量面包车，也跑不出跑车的速度。

实际使用中，链路两端设备的速率必须匹配。路由器口是千兆、网卡也是千兆，协商出来的速率才能到千兆。如果一端是百兆口、另一端是千兆口，那这条链路最终只按百兆跑，这是硬件协商的结果，不是哪一方的软件可以改变的。同理，网线质量差也可能导致千兆协商失败，自动降级到百兆。很多家用路由器标称千兆口，但随机附送的网线是百兆线，用户跑不满千兆，问题其实就在这根线上。

1.3 吞吐率：真实跑出来的数据量

吞吐率（throughput）是最有“含金量”的指标，它说的是在真实环境下，单位时间内实际成功传输的数据量。单位同样是bps、Mbps或MB/s。我们平时说的下载速度、上传速度，本质上都是吞吐率。你千兆带宽为什么要跑不满？因为吞吐率受协议、延迟、丢包、设备性能、对端服务能力等一堆因素影响，它代表的是端到端的“实际交付能力”。

继续用高速路类比：带宽是这条路的设计通行能力，吞吐率是你今天开车从A到B，扣除红绿灯、堵车、收费站排队之后，每小时实际开过的公里数。只要路上有任何一个环节在限流，实际跑出来的数字就一定小于设计上限。甚至可以说，吞吐率是端到端真实体验最直接的反映。用户不会关心链路标称多少，只关心文件到底多久能传完。

举个例子，两个城市之间有一条10Gbps的专线，但如果两台服务器之间TCP窗口没调优、往返时延又高，实际能跑出来的吞吐率可能只有几百Mbps。这时候链路带宽是10G，但吞吐率就是几百M，差了一个数量级很正常。研究网络性能的人天天在跟吞吐率较劲，因为它是衡量优化效果最客观的标尺。

1.4 利用率：已经用掉的那部分容量

利用率是个百分比，指的是链路或网络中实际传输的数据量与其最大容量的比例。它不是一个独立的“速度”，而是把“吞吐率÷带宽”算出来的占用程度。比如一条千兆链路，当前实际吞吐率是300Mbps，那这条链路的利用率就是30%。

利用率分两类。一是链路利用率，只看某一段物理链路的占用情况；二是网络利用率，指整张网络中链路的平均占用情况。教学里常考的一个结论是，网络利用率越高并不代表质量越好，因为当利用率超过一定阈值（实践中大约70%到80%），排队延迟会急剧上升，拥塞概率大幅增加，丢包和重传开始出现，实际传输效率反而下降。这就好比高速路车一多，大家反而都走不快。

利用率是一个“状态量”，它会随着时间剧烈波动。看的时候一定要看峰值和持续时间，别只盯着平均值。很多搞运维的朋友盯着网管系统里“平均利用率20%”就觉得链路挺空，结果一到业务高峰就卡顿，原因往往是瞬时突发流量早就打满了链路，只是平均下来看着不高。这背后的坑，后面第五章会专门讲。

2. 单位换算：为什么有人写bps，有人写Bps

2.1 bps、Bps、pps，三兄弟先分清

这四个概念的背后全是单位问题，很多人明明懂了概念，一换算还是错。这三组单位一旦分不清，后面所有的数字计算都会出问题。尤其是面试和考试题里，出题人最喜欢在这里埋坑，给出一个1.5MB/s的结果，选项全是Mbps，不会换算就直接丢分。先说最基础的三组：

• bps（bit per second）：每秒传输的比特数，是带宽、速率、吞吐率最常用的单位。
• Bps（Byte per second）：每秒传输的字节数，下载软件、文件复制显示的一般是它，注意大写B。
• pps（packet per second）：每秒转发的数据包数量，交换机和路由器的包转发能力常用这个单位。

1字节（Byte）等于8比特（bit），所以1MB/s等于8Mbps。千兆网口理论极限 1000Mbps ÷ 8 = 125MB/s，再扣除以太网帧头、IP头、TCP头的开销，实际能跑到的最大大约在112MB/s到118MB/s之间，换算成Mbps大概是900到950Mbps。如果你拿iperf3测出940Mbps左右，那就是一条千兆链路非常健康的标准数值。

pps的坑更隐蔽。一个以太网帧最短是64字节，加上8字节前导码和12字节帧间隙，物理上传输一个最小包要占84字节。如果按最小包算，一个千兆口每秒能转发的包数理论上限也就1488095包/秒左右，很多设备标称的pps上限就是这么来的。吞吐率不是只看bps就完事，小包场景下要先看pps是否能扛住。

带宽和存储的进制也不一样，网络领域习惯用十进制：1 Mbps = 1,000,000 bps，1 Gbps = 1,000,000,000 bps。而内存、硬盘容量常见的是二进制或混用，1MB存储有时是1024×1024字节。硬要换算不同进制，会再次引入约2.4%的差异。大多数情况下网络设备用十进制，磁盘厂商也用十进制，但操作系统显示存储容量时常用二进制，于是又多了个“标称500G硬盘实际只有465G”的经典场面。网络这行很多数字差异，说到底都是单位口径没对齐。

2.2 500M宽带下载为何只有45MB/s

运营商说的带宽，单位默认是Mbps。你办500M宽带，物理上就是500Mbps，换算成字节是500÷8=62.5MB/s。这是什么概念？这是理论极值，你必须在没有任何协议开销、服务器刚好在你家附近、链路全程不拥塞的理想情况下才能摸到。

现实里你下载一个几百MB的文件，先要经过服务器出口、主干网、运营商接入网，最后才进你家光猫。每一段的带宽都可能是不同的，整条链路遵循“木桶效应”，哪一段最小，吞吐率就被卡在哪一段。再加上TCP窗口、往返时延、服务器限速、WiFi信号波动，最终能跑45MB/s已经算是相当健康的状态。45MB/s换算成Mbps，是360Mbps，相当于500M宽带实际利用率到了72%左右，这个数字放在公网环境里，已经不错了。

顺便说一句，很多测速软件默认显示MB/s，你拿它和套餐的Mbps直接对比，数字上会差8倍，这是小白最容易踩的第一个坑。记住一个原则：看到速度先看单位，再决定要不要惊讶。

2.3 一个公式把四兄弟串起来

利用率 = 吞吐率 ÷ 带宽 × 100%。

这是最核心的关系式。带宽是分母，吞吐率是分子，利用率是除出来的比值。举个数字例子：

带宽是1000Mbps，当前吞吐率350Mbps，利用率就是35%。如果这时候加一个下载任务，吞吐率涨到700Mbps，利用率变成70%；再往上加，接近100%的时候延迟开始暴涨，TCP会通过拥塞控制自动降速，吞吐率反而可能回落。

所以这四个指标不是一个孤立概念，而是一个完整的观察链条。看到利用率高，第一反应不是“链路好满”，而是“会不会已经过了拥塞临界点”；看到吞吐率低，也不要急着怪带宽，先看看利用率到底高不高——如果吞吐率低、利用率也低，说明瓶颈根本不在链路上，而在上层应用或对端。

3. 四个指标怎么测：从路由器到iperf3

3.1 带宽和速率去哪看

带宽和协商速率是最容易查的。家用场景，登录光猫或路由器的后台，端口状态页面基本都会显示“WAN口：1000Mbps全双工”、“LAN口：1000Mbps全双工”，这里的1000Mbps就是链路协商速率，它代表了物理层当前能达到的最大速率。如果这里显示的是100Mbps，那不管宽带套餐多大，你家里的内网链路都只按百兆在跑，这是最常见的一个硬件瓶颈。

Linux服务器上可以用ethtool查。命令很简单：

ethtool eth0

输出里Speed: 1000Mb/s、Duplex: Full，就是当前协商出来的速率和双工模式。看到Speed: 100Mb/s而网卡明明是千兆卡时，先查网线是不是老化，水晶头是不是没压好，或者对端设备端口是不是百兆。一根劣质网线会让千兆协商直接掉到百兆甚至十兆，这是排障时非常容易忽略的点。另外，很多交换机的管理页面上会直接列出“当前端口速率：Auto / 1000Mbps / Full”，对照一下就行。有些设备支持日志查询协商失败记录，端口速率不停在10M和100M之间跳变，基本就是网线质量不行或水晶头接触不良。先把物理层稳住，再谈后面。

3.2 吞吐率实测：iperf3一分钟出结果

测吞吐率别用下载文件的方式猜，因为公网速度和服务端限制会干扰结果。最靠谱的办法是在你控制的两台机器之间用专业工具打流。iperf3是目前最常用的开源测速工具，跨平台支持Windows、Linux、macOS。

第一步，在作为服务端的机器上启动：

iperf3 -s

默认监听5201端口，可以加-p指定端口。第二步，在客户端机器上运行：

iperf3 -c 192.168.1.10 -t 30

意思是向服务端发起30秒的TCP流。跑完会输出sender和receiver两个方向的数据，通常看receiver的SUM这一行，那里的Transfer和Bitrate就是你这条链路实测的吞吐率。

如果要测多线程效果，加-P参数：

iperf3 -c 192.168.1.10 -t 30 -P 4

4条并发流同时打，能更充分地占满带宽，也更贴近实际多连接下载的场景。测上行方向加-R即可，让客户端只接收数据。局域网测出来如果是900多Mbps，说明你的网络设备和链路非常健康；如果只有三四百Mbps，赶紧检查网线、交换机端口和网卡驱动，问题基本不在本机性能上。

3.3 利用率观察：从计数器到实时流量

利用率不需要额外打流，它是从设备计数器上抠出来的。Linux下先看总的收发字节数：

cat /proc/net/dev

这个文件里每一行是一个网卡接口，rx_bytes和tx_bytes是累计值。间隔10秒再读一次，用差值除以10秒，就得到这10秒的平均吞吐率，再除以端口速率，就是这10秒的平均利用率。

更省事的方式是用现成工具。iftop能像top命令一样实时显示各连接的流量；nload能直接显示进出的带宽占用；网管系统里常见的SNMP监控，本质也是周期性地抓接口的ifInOctets和ifOutOctets计数器，算差值再除以时间。所有图形化监控面板，背后都是这一套计数逻辑，没有魔法。

交换机上如果支持端口镜像，也可以把流量镜像出来用Wireshark抓包分析，看协议分布、重传比例、TCP窗口大小。不过那属于更深的排障手段了，新手先用命令把数字抠出来，比啥都实在。

4. 实战排障：千兆网卡下载却只有30MB/s

4.1 先别急着怪运营商

场景是这样的：公司电脑是千兆网卡，宽带套餐是千兆，直接从HTTP链接下载一个大文件，速度稳定在30MB/s左右。这个速度换算成Mbps，是240Mbps，只有千兆的两成多。遇到这种情况，第一步不是投诉运营商，而是按顺序拆。

先确认链路协商速率。登录路由器或交换机看端口协商速率，确保电脑和接入设备之间是1000Mbps。可以用ethtool查，如果电脑网卡显示千兆，但交换机端显示百兆，说明网线或端口有问题。很多交换机的管理页面上会直接列出“当前端口速率：Auto / 1000Mbps / Full”，对照一下就行。有些设备支持日志查询协商失败记录，端口速率不停在10M和100M之间跳变，基本就是网线质量不行或水晶头接触不良。先把物理层稳住，再谈后面。

再确认局域网内的最大吞吐率。用iperf3在电脑和局域网服务器之间打流，如果iperf3能跑到900多Mbps，说明电脑网卡、网线、交换机这一段完全没问题，瓶颈一定在外网链路上。如果局域网也只有三四百Mbps，那问题在你自己家里或办公室内部，和运营商没有一毛钱关系。

4.2 木桶效应：磁盘和CPU也可能是凶手

局域网iperf3跑满千兆，但公网下载还是30MB/s，这时候就要往链路的“木桶短板”上想。公网下载链路由很多段组成：服务器出口带宽、主干网拥塞情况、运营商接入段、家里光猫、路由器、WiFi或网线、电脑磁盘。

磁盘是很容易被忽略的一环。机械硬盘的持续写入速度通常只有80到150MB/s，看着好像比30MB/s大不少，但如果同时有别的程序在写盘，或者文件被写成大量碎片，实际写入速度可能跌到几十MB/s。强烈建议看任务管理器里的磁盘利用率，如果磁盘已经接近100%，那网络再好数据也落不了盘，下载速度自然被压住。

CPU也不可忽视。Windows下下载时CPU占用率如果长期飙高，可能是杀毒软件在做实时扫描，每次写入都要过一遍引擎，CPU成了瓶颈，网络吞吐率也跟着降。遇到这种场景，把下载目录加入杀毒软件白名单，速度往往立刻就能上来。

4.3 用计算还原现场

先做一组基础计算。千兆理论极值是1000Mbps ÷ 8 = 125MB/s。为什么达不到这个数？因为以太网帧有帧头，IP和TCP还各有头部，这些开销大约占6%到10%，所以千兆链路的实际物理上限大约在112到117MB/s。iperf3在局域网内测出940Mbps，对应940 ÷ 8 = 117.5MB/s，已经非常接近这个天花板。这等于拿到一个核心证据：电脑到路由器这一段链路完全健康。

公网下载稳定30MB/s，意味着吞吐率只有240Mbps，链路利用率只有240 ÷ 1000 = 24%。注意这个利用率并不高，链路不拥塞，所以瓶颈不在“带宽容量”上，而在端到端的某个环节。结合前面查过的磁盘、CPU和应用限速，马上就能锁定方向。

有些时候下载软件默认连接数太少，TCP窗口又小，单连接上限就那么多，手动把并发连接数调上去，速度立刻会有改善。典型的例子是迅雷这类工具，你不开多线程，单连接可能就只有几个MB/s，开启多线程后能明显看到吞吐率往上走，这就是绕开了“单连接受限于带宽延迟积”的问题。

4.4 高延迟高带宽场景：为什么带宽再大也跑不满

前面都是“链路挺空但速度不高”的场景，还有一个经典场景是带宽很大、利用率很低，但吞吐率就是上不去——长肥管道问题。两地之间的专线带宽10Gbps，物理距离几千公里，单向时延50ms，TCP窗口如果默认只有64KB，那最大吞吐率就卡在窗口除以时延这个数，大约只有10Mbps左右。64KB的接收窗口在实际TCP连接中可能还会被路径上的瓶颈设备进一步缩小，所以数值只会更难看。

有个经典的计算公式，带宽延迟积 = 带宽 × 往返时延，代表链路里最多能容纳多少数据在“飞行”。如果TCP窗口小于带宽延迟积，发送方永远填不满管道，再宽的链路也白搭。实际中解决思路是调大TCP窗口、开启窗口缩放、使用多连接并发，或者换成更激进的拥塞控制算法。这个场景适合有基础的同学进一步学习，这里先把结论给出来：大带宽不等于高吞吐率，设备配置、协议参数、网络时延，全是变量。

5. 常见误区与避坑清单

5.1 六个经常翻车的高频误区

第一个误区也是最常见的误区：带宽越大，下载就一定越快。带宽只代表链路容量上限，它决定的只是“最多能装多少”，至于实际装了多少，要看这条链路最窄的那一段、要看两端机器的协议栈配置、要看时延和丢包。一条高带宽但高时延的国际链路，如果TCP窗口没调优，实测吞吐率可能只有几十Mbps；反过来，一条百兆低时延、窗口调优过的链路，跑上90Mbps都轻轻松松。所以别拿套餐数字当作体验数字。

第二个误区是混淆Mbps和MB/s。这两个单位之间差8倍，但很多人换算时总是想当然。你看运营商宣传单上写的“500M宽带”，秒懂这是500Mbps，也就是每秒500兆比特；可下载工具显示的是MB/s，是每秒字节数。500Mbps÷8=62.5MB/s，这才是理论下载上限。如果测速软件显示50MB/s，那你已经用掉了400Mbps带宽，利用率八成。这个坑不填，后面所有数字都容易算错。

第三个误区是把协商速率当实际速率。网卡属性里写着1.0Gbps，很多人就觉得网速应该每秒100多MB，实际跑下来只有几十MB，于是到处投诉。问题出在概念上：协商速率只是物理层在握手时达成的“能力上限”，而真正的端到端吞吐率还要被协议开销、对端性能、链路拥塞层层打折。协商速率是前提，不是承诺。

第四个误区是认为链路利用率越高越好。很多教材里会强调一个现象：链路利用率超过70%到80%之后，排队延迟会急剧上升，数据包开始在缓冲区里堆积，TCP探测到拥塞就开始降窗口、重传，吞吐率不升反降。这就跟高速路一样，车流多到一定程度，所有车都只能龟速挪动。所以利用率接近100%并不是“带宽用得很值”，更可能是网络已经不健康的信号。

第五个误区是忽略小包场景下的pps瓶颈。网络设备有两条性能曲线，一条是吞吐率（bps），一条是包转发率（pps）。64字节小包是转发性能最苛刻的场景，千兆链路理论上限约1.48Mpps，如果交换芯片的包处理能力只有1Mpps，那么就算线路带宽再大，小包场景下也顶多跑到六七成。很多人只盯带宽数字，结果在语音、小包高频等场景里被打个措手不及。

第六个误区是只看平均利用率，忽略瞬时峰值。平均利用率20%的链路，完全可能在某一秒被打到100%并产生丢包，用户感受到的卡顿正是发生在那几秒。监控网关时，除了平均值，一定要把最大利用率或95峰值也画出来。网络优化判断“是否需要扩容”，看的基本是峰值而不是均值，这个习惯直接影响决策质量。

5.2 知识速查表

把四个概念放到一张表里，方便随时翻。这张表也是我平时给团队新人做培训时的第一页材料，信息密度不高，但每次排障都靠它把思路拉回正轨。

5.3 排障优先级口诀

实际干活的时候，别东一榔头西一棒子，按顺序来。先确认链路协商速率，再测局域网吞吐率，然后看公网链路，最后查磁盘、CPU和应用。链路协商不正常，后面全白搭；局域网iperf3能跑满，问题就不在内网；公网吞吐率低但利用率不高，瓶颈在端到端某一环；磁盘和CPU顶不住，网络再快也落不了地。

如果一上来就怀疑运营商，往往会错过真正的根因。我见过太多案例，用户花了一整天跟宽带客服扯皮，最后发现是自家路由器用了五年的百兆网线。先把本地能查的查完，把证据摆出来，再去和外部沟通，效率会高得多。

最后分享一个我自己的使用习惯。我只要新装一套网络设备，第一件事不是在后台点“测速”，而是先拿iperf3在局域网里打一次流，确认物理链路本身没问题，再谈优化。等局域网吞吐率已经能稳定跑到900多Mbps，我才把注意力放到公网链路上，用下载任务做第二道验证。这个习惯帮我在排障时省掉了大量冤枉路。

四个概念之间的关系，说白了就一句话：带宽是上限，速率是标签，吞吐率是现实，利用率是状态。它们既不矛盾，也不该被混用。分析网络问题时，把这四个数字同时摆出来，几乎八成的问题当场就能定位到方向。学网络不神秘，先把这几个基础指标吃透，很多“玄学”其实都是清清楚楚的物理事实。