4、测试工具链（中）：Netperf 详解——批量传输、请求响应、流式测试
聊完了 iperf3，咱们今天来啃另一块硬骨头——Netperf。
说实话，我个人觉得 Netperf 比 iperf3 要「重」一些，但它的能力边界也宽得多。iperf3 主要测的是流吞吐，而 Netperf 能测的东西就多了：批量数据传输、请求响应、流式测试，甚至还能模拟数据库、Web 服务器的交互模式。
嗯，咱们今天就把这三个核心模式掰开揉碎讲清楚。
4.1 Netperf 的「三驾马车」
Netperf 的测试模式，说白了就三种：
- 批量传输（Bulk Transfer）：类似 iperf3，测 TCP/UDP 的吞吐上限。
- 请求响应（Request/Response）：模拟一问一答，比如 HTTP、数据库查询。
- 流式测试（Stream）：连续发送数据，看接收端能不能跟上。
这三种模式覆盖了绝大多数网络应用的场景。我在项目中遇到过很多次，光看吞吐量觉得网络没问题，一上请求响应测试就原形毕露——延迟高得吓人。
核心观点：吞吐量高 ≠ 网络好。请求响应模式才是真实应用的照妖镜。
4.2 批量传输测试：测带宽上限
先看最简单的——批量传输。命令长这样：
# TCP 批量传输，默认 60 秒
netserver -p 12865 # 服务端先启动
netperf -H 192.168.1.100 -p 12865 -l 60 -t TCP_STREAM参数说明：
-H：服务端 IP-p：端口号，默认 12865-l：测试时长，单位秒-t：测试类型，TCP_STREAM就是批量传输
输出结果里，最关键的是这一行：
87380 16384 16384 10.00 941.78从左到右分别是：
- 本地 Socket 缓冲区大小（87380 字节）
- 远端 Socket 缓冲区大小（16384 字节）
- 消息大小（16384 字节）
- 测试时长（10 秒）
- 吞吐量（941.78 Mbps）
你想想看，这个吞吐量是不是真实带宽？不一定。如果缓冲区太小，或者 CPU 有瓶颈，结果会偏低。我曾经在虚拟化环境里测过一次，吞吐量只有物理机的 60%，查了半天发现是 vCPU 的调度策略问题。
小技巧：批量传输测试时，建议把 -m 参数（消息大小）调大，比如 64KB，能减少 CPU 中断开销，测出更真实的带宽上限。
4.3 请求响应测试：测延迟与事务处理能力
这才是 Netperf 的杀手锏。命令：
# TCP 请求响应，模拟一问一答
netperf -H 192.168.1.100 -p 12865 -l 60 -t TCP_RR输出结果：
Local / Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes bytes bytes bytes secs. per sec
16384 87380 1 1 60.00 45231.45关键指标是 Trans. Rate——每秒完成的事务数（TPS）。这里 45231 次/秒，意味着每次请求响应的平均延迟是 1/45231 ≈ 22 微秒。
嗯，这里要注意：请求和响应的大小可以调。比如模拟 HTTP 请求：
# 请求 256 字节，响应 4096 字节
netperf -H 192.168.1.100 -p 12865 -l 60 -t TCP_RR -- -r 256,4096-r 参数指定请求和响应的大小。我在做数据库中间件性能测试时，就经常用这个模式——模拟客户端发一条 SQL（几百字节），服务端返回结果集（几 KB）。
避坑指南：我曾经遇到过一个问题：请求响应测试结果忽高忽低。后来发现是服务端开启了 Nagle 算法，小包被延迟合并了。解决方案是在服务端设置 TCP_NODELAY，或者用 TCP_RR 的 -D 参数禁用 Nagle。
4.4 流式测试：测持续吞吐能力
流式测试和批量传输有点像，但更强调「持续发送、持续接收」的能力。命令：
# TCP 流式测试
netperf -H 192.168.1.100 -p 12865 -l 60 -t TCP_STREAM等等，这和前面的批量传输命令一样？对，Netperf 里 TCP_STREAM 既是批量传输也是流式测试。但 UDP 的流式测试就不同了：
# UDP 流式测试
netperf -H 192.168.1.100 -p 12865 -l 60 -t UDP_STREAMUDP 流式测试会输出丢包率：
87380 110592 65507 60.00 941.78 0.000最后一个数字是丢包率。如果丢包率 > 0，说明网络或接收端处理不过来。我曾在弱网环境下测过，丢包率飙到 15%，视频通话直接卡成 PPT。
关键区别：TCP 流式测试会自动重传丢包，所以你看不到丢包率；UDP 流式测试会如实反映丢包情况，适合评估实时音视频、游戏等场景。
4.5 三种模式的对比与选择
咱们用一张表总结一下：
| 测试模式 | 命令参数 | 核心指标 | 适用场景 |
|---|---|---|---|
| 批量传输 | TCP_STREAM |
吞吐量（Mbps） | 文件传输、备份、CDN |
| 请求响应 | TCP_RR |
事务速率（TPS） | Web 服务、数据库、API |
| 流式测试 | UDP_STREAM |
吞吐量 + 丢包率 | 音视频、游戏、IoT |
我个人习惯是：先跑批量传输看带宽上限，再跑请求响应看延迟表现，最后用流式测试验证极端情况。三步走下来，网络性能的底裤基本就扒干净了。
4.6 知识体系图
下面这张图帮你理清 Netperf 的核心逻辑：
这张图把 Netperf 的三种模式、核心指标和适用场景串起来了。你照着这个思路去测，基本不会漏掉关键点。
最后提醒一句：Netperf 的测试结果受很多因素影响——CPU 频率、内存带宽、网卡队列、中断亲和性。如果结果异常，别急着骂网络，先看看系统配置。我曾经花了一整天排查一个「网络慢」的问题，最后发现是网卡的 RSS 队列没开。
公众号:蓝海资料掘金营，微信deep3321