吞吐测试基础概念：从一次故障说起

我记得刚入行那会儿，遇到过一个挺头疼的问题。客户投诉说我们提供的网络设备「跑不动」，但 CPU 和内存占用都不高。我折腾了两天，最后用 iPerf 一测——吞吐量只有标称值的 60%。说白了，设备在「能通」和「能跑多快」之间，差着十万八千里。

从那天起，我就养成了一个习惯：任何网络设备上线前，必须先过吞吐测试这一关。今天咱们就来聊聊吞吐测试最基础的东西。

什么是吞吐量？

吞吐量（Throughput），简单说就是单位时间内成功传输的数据量。单位通常是 bps（bit per second），或者更直观的 Mbps、Gbps。

你想想看，一条高速公路限速 120 km/h，但实际能跑多快？得看车流量、收费站、红绿灯。网络也一样——带宽是理论上限，吞吐量才是真实能跑出来的速度。

我在项目中遇到过不少工程师把「带宽」和「吞吐量」混为一谈。其实区别很明显：

概念	含义	典型值
带宽	链路理论最大传输速率	1 Gbps（物理层）
吞吐量	实际有效数据传输速率	940 Mbps（实测）
Goodput	应用层有效数据速率（去掉协议头）	~900 Mbps

嗯，这里要注意：吞吐量永远小于带宽。因为协议开销、处理延迟、重传这些因素，都会吃掉一部分性能。

吞吐测试的目的与意义

为什么要做吞吐测试？我总结了三层目的：

1. 验证设备性能——看看设备到底能不能达到标称值。我见过不少交换机，小包（64字节）吞吐量直接腰斩。
2. 定位性能瓶颈——是 CPU 扛不住？还是网卡中断太多？还是驱动有 bug？吞吐测试能帮你把问题「逼出来」。
3. 建立性能基线——设备上线前测一次，出故障时再测一次，对比数据就知道哪里出了问题。

从工程角度看，吞吐测试的意义在于：它给了你一把尺子。没有这把尺子，你只能凭感觉说「好像有点慢」；有了它，你能精确地说「UDP 吞吐量 980 Mbps，TCP 只有 850 Mbps，问题出在 TCP 协议栈」。

常见吞吐测试工具介绍

工具不在多，在于会用。我日常用得最多的就两个：iPerf 和 netperf。下面分别说说。

iPerf

iPerf 是目前最流行的吞吐测试工具，没有之一。它分两个版本：iPerf2（经典版）和 iPerf3（重写版）。我个人习惯用 iPerf3，因为它的报告更清晰，单线程性能也更好。

基本用法很简单：

# 服务端（先启动）
iperf3 -s -p 5201

# 客户端（发起测试）
iperf3 -c 192.168.1.100 -p 5201 -t 30

这条命令的意思是：客户端连到 192.168.1.100 的 5201 端口，测 30 秒。默认用 TCP，结果会显示带宽、传输数据量、重传次数。

iPerf 的几个常用参数：

参数	作用	示例
-u	切换为 UDP 模式	iperf3 -c 目标IP -u -b 100M
-b	设置目标带宽（UDP 模式）	-b 500M
-P	并行流数量	-P 4（4 个流同时发）
-l	设置缓冲区大小（影响包长）	-l 1460
-R	反向测试（服务端发数据）	iperf3 -c 目标IP -R

netperf

netperf 比 iPerf 更「老派」，但它的优势在于测试场景更丰富。除了基本的 TCP/UDP 吞吐，还能测：

• TCP RR（请求-响应）延迟
• TCP CRR（连接-请求-响应）
• UDP 丢包率
• 流媒体模拟

基本用法：

# 服务端
netserver -p 12865

# 客户端（TCP 流吞吐）
netperf -H 192.168.1.100 -p 12865 -l 30

# 客户端（UDP 流吞吐）
netperf -H 192.168.1.100 -p 12865 -l 30 -t UDP_STREAM

netperf 的测试类型通过 -t 参数指定：

测试类型	说明	适用场景
TCP_STREAM	TCP 单向流吞吐	大文件传输
UDP_STREAM	UDP 单向流吞吐	视频流、VoIP
TCP_RR	TCP 请求-响应延迟	数据库查询
TCP_CRR	TCP 连接+请求-响应	HTTP 短连接

我个人觉得，iPerf 适合快速验证带宽，netperf 适合深入分析应用层性能。两个工具互补，建议都装上。

本章知识体系

下面这张图，帮你把本章的核心逻辑串起来：

好了，这一章的内容就这些。记住一句话：吞吐量是网络的「真实速度」。后面我们会拿着 iPerf 和 netperf 这两个工具，一步步深入抓包分析，看看数据到底是怎么「跑」的，又是在哪里「卡」住的。