3. 带宽与吞吐量：概念、关系与测量方法
带宽和吞吐量，这两个词在通信领域天天见。但说实话，能把它们彻底说清楚的人，并不多。
我见过不少刚入行的工程师，一上来就问：“我这链路带宽是1Gbps，为什么实际传文件只有500Mbps？” 嗯，这个问题背后，就是带宽和吞吐量的区别。今天咱们就把这事掰扯明白。
3.1 带宽概念
带宽，英文叫Bandwidth。从物理层面讲，它指的是信道能传输信号的频率范围，单位是Hz。但在咱们网络工程师的日常里，带宽通常指链路的最大数据传输速率，单位是bps（bit per second）。
打个比方：带宽就像高速公路的车道数。8车道的高速，理论上能同时跑8辆车。1Gbps的带宽，理论上每秒能传1Gbit的数据。
核心要点：带宽是理论最大值，是链路能力的上限。它由物理层决定，比如网线类别、光纤模式、无线频段等。
我个人习惯把带宽理解为“额定容量”。就像你家水管的管径，决定了最大水流能有多大。但实际流多少水，还得看水压、阀门、有没有堵塞——这就引出了吞吐量。
3.2 吞吐量概念
吞吐量，英文Throughput。它指的是实际成功传输的数据量，单位也是bps。注意“成功”两个字——重传的、丢失的、被协议开销吃掉的，都不算。
还是那个高速公路的比方：带宽是车道数，吞吐量是实际每分钟通过收费站的车辆数。为什么会有差距？因为收费站要减速、要交费、偶尔还有车抛锚。网络也一样。
我在项目中遇到过一件事：客户买了10Gbps的链路，结果跑业务时发现只有2Gbps。排查下来，是防火墙的会话处理能力跟不上。你看，链路带宽是10G，但防火墙成了瓶颈，吞吐量就上不去。
我的经验：吞吐量才是用户真正感知到的性能。带宽再大，如果吞吐量上不去，用户体验就是卡顿。所以做性能优化，盯的是吞吐量，不是带宽。
3.3 带宽与吞吐量的关系
它们的关系，说白了就是一句话：吞吐量 ≤ 带宽。带宽是天花板，吞吐量是实际到达的高度。
为什么会小于？影响因素太多了：
- 协议开销：TCP/IP头部、以太网帧头、确认包等，这些都要占用带宽
- 重传与丢包：网络不稳定时，数据包丢失需要重传，有效吞吐量下降
- 延迟与抖动：高延迟会导致TCP窗口无法充分打开，吞吐量受限
- 中间设备处理能力：路由器、交换机、防火墙的CPU和内存限制
- 应用层效率：应用程序读写缓冲区大小、系统调用开销等
你想想看，1Gbps的链路，去掉以太网帧头（约7%开销），再去掉TCP/IP头部（约2%），再考虑TCP慢启动和拥塞控制，实际能跑700-800Mbps已经算不错了。
避坑指南：我曾经见过一个团队，买设备时只看带宽参数，结果部署后发现吞吐量只有标称值的60%。后来才发现，设备厂商标注的“线速转发”是在特定小包条件下测的，实际大流量场景根本达不到。所以，采购时一定要问清楚：这个带宽是在什么条件下测的？
下面这张图，是我自己总结的带宽与吞吐量的关系，以及影响吞吐量的关键因素：
3.4 如何测量吞吐量
理论说完了，来点实际的。怎么测吞吐量？我常用的工具就两个：iperf 和 netperf。它们都是业界标准，免费开源，几乎所有的Linux发行版都自带或可以轻松安装。
3.4.1 使用 iperf 测量吞吐量
iperf 是我用得最多的工具。它支持TCP和UDP，可以单线程也可以多线程，还能设置窗口大小、缓冲区大小等参数。
基本用法：
首先，在服务端启动监听：
# 服务端（接收端）
iperf -s -p 5001然后，在客户端发起测试：
# 客户端（发送端）
iperf -c 192.168.1.100 -p 5001 -t 30这个命令的意思是：向192.168.1.100的5001端口发送数据，持续30秒。输出结果会显示带宽、吞吐量、丢包率等信息。
我的习惯：测试时一定要加 -t 参数，默认只测10秒，太短了不够稳定。我一般设30秒到60秒，让TCP进入稳定状态后再看数据。
常用参数：
| 参数 | 说明 | 示例 |
|---|---|---|
-s |
服务端模式 | iperf -s |
-c |
客户端模式，后跟服务器IP | iperf -c 10.0.0.1 |
-t |
测试时长（秒） | -t 60 |
-P |
并行线程数 | -P 4（4个线程同时发） |
-w |
TCP窗口大小 | -w 256K |
-u |
UDP模式 | -u -b 100M（UDP下指定带宽） |
UDP测试特别说明：
# 服务端
iperf -s -u -p 5001
# 客户端（发送100Mbps的UDP流）
iperf -c 192.168.1.100 -u -b 100M -t 30UDP测试会显示丢包率和抖动。我在项目中用UDP模式来模拟视频流或语音流，看网络能不能扛住。
注意：UDP测试时，-b 参数指定的是目标发送速率，不是带宽上限。如果设得过高，网络会大量丢包。我曾经有一次设了1Gbps的UDP流，结果把交换机打挂了……嗯，从那以后我都是从小速率开始慢慢往上加。
3.4.2 使用 netperf 测量吞吐量
netperf 是另一个老牌工具，比 iperf 更早出现。它的特点是测试场景更丰富，支持TCP、UDP、SCTP，还能测单向延迟和请求响应时间。
基本用法：
启动服务端（netserver）：
# 服务端
netserver -p 12865客户端发起TCP流测试：
# 客户端
netperf -H 192.168.1.100 -p 12865 -l 30-l 参数指定测试时长，单位秒。
常用测试类型：
| 测试类型 | 参数 | 说明 |
|---|---|---|
| TCP流 | -t TCP_STREAM |
标准吞吐量测试（默认） |
| TCP请求响应 | -t TCP_RR |
模拟请求-响应模式，如HTTP |
| UDP流 | -t UDP_STREAM |
UDP吞吐量测试 |
| UDP请求响应 | -t UDP_RR |
UDP下的事务处理能力 |
一个实际案例：
我记得有一次帮客户排查数据库同步慢的问题。用 netperf 的 TCP_RR 模式一测，发现请求响应时间高达5ms。正常应该在0.5ms以内。后来定位到是网卡中断合并参数没调优，导致小包延迟过高。调整后，吞吐量直接翻倍。
我的建议：测吞吐量时，不要只测TCP流。一定要测一下请求响应模式（TCP_RR），因为很多业务场景是短连接、小包交互，这种场景下吞吐量往往比大流场景差很多。
3.4.3 测量注意事项
测吞吐量看着简单，但坑不少。我列几个常见的：
- 两端时间要同步：iperf和netperf都依赖时间戳计算速率，时间不同步会导致结果偏差
- 关闭防火墙和流量整形：测试时最好关掉iptables、tc等，否则测的是防火墙性能，不是链路性能
- CPU不能跑满：如果测试过程中CPU达到100%，说明瓶颈在CPU，不在网络
- 多轮测试取平均：网络有波动，至少测3次取平均值
- 注意MTU设置：MTU大小会影响吞吐量，特别是大文件传输场景
一个小技巧：我习惯在测试时同时开两个终端，一个跑iperf，另一个用 sar -n DEV 1 实时观察网卡流量。这样能交叉验证，看iperf报的吞吐量和实际网卡收发包是否一致。如果不一致，说明有丢包或驱动问题。
好了，带宽和吞吐量这块就讲到这里。记住一句话：带宽是理论，吞吐量是现实。做性能优化，就是不断缩小这两者之间的差距。下一节咱们聊聊延迟和抖动，这两个家伙对吞吐量的影响，比你想象的大得多。