【网络工程】网络性能基准测试：iperf3、netperf 与测试方法论

“我们的网络带宽是 10G”——这句话几乎没有提供任何有用信息。带宽是单流还是多流？TCP 还是 UDP？有多少 CPU 参与？MTU 是多少？延迟是多少？测量了多长时间？基准测试的价值不在于得到一个数字，而在于用可复现的方法得到有上下文的数据。

一、网络性能指标

1.1 四大核心指标

指标	定义	单位	测量工具
带宽（Bandwidth / Throughput）	单位时间传输的数据量	Gbps / MBps	iperf3, netperf
延迟（Latency）	数据包从发送到接收的时间	ms / μs	ping, hping3, sockperf
丢包率（Packet Loss）	传输中丢失的包占总包的比例	%	iperf3 -u, ping
包速率（PPS）	每秒处理的数据包数	pps	pktgen, MoonGen

1.2 带宽 vs 吞吐量

带宽（Bandwidth）和吞吐量（Throughput）经常被混用，但有区别：

• 带宽：物理链路的理论最大传输速率
  例如：10GbE 网卡的带宽是 10 Gbps

• 吞吐量：实际测量的数据传输速率
  受协议开销、CPU、缓冲区等影响

• Goodput：应用层实际有效数据的传输速率
  去除 TCP/IP 头部、重传等开销后的净吞吐

     ┌─────────────────────────────────┐
     │          物理带宽 10 Gbps        │
     │  ┌───────────────────────────┐  │
     │  │    TCP 吞吐量 9.4 Gbps     │  │
     │  │  ┌─────────────────────┐  │  │
     │  │  │  Goodput 9.2 Gbps   │  │  │
     │  │  └─────────────────────┘  │  │
     │  └───────────────────────────┘  │
     └─────────────────────────────────┘

1.3 延迟的多个维度

# 延迟不是单一数字——它有多个维度

# 1. RTT（Round-Trip Time）
# 数据包往返时间
ping -c 10 target_host

# 2. 单向延迟（One-Way Delay）
# 需要精确时间同步（PTP/GPS）
# OWD = RTT / 2 只是近似值（上下行可能不对称）

# 3. 抖动（Jitter）
# 延迟的变化量
ping -c 100 target_host | tail -1
# rtt min/avg/max/mdev = 0.5/0.8/2.1/0.3 ms
# mdev = 0.3ms 就是抖动

# 4. 尾延迟（Tail Latency）
# P99/P999 延迟——比平均延迟更重要
# 需要收集足够多的样本做百分位统计

二、iperf3 带宽测试

2.1 基本用法

# 服务端
iperf3 -s -p 5201

# 客户端——TCP 带宽测试
iperf3 -c server_ip -p 5201 -t 30
# -t 30: 测试 30 秒

# 典型输出
# [ ID] Interval           Transfer     Bitrate         Retr  Cwnd
# [  5]   0.00-1.00   sec  1.10 GBytes  9.41 Gbits/sec    0   3.12 MBytes
# [  5]   1.00-2.00   sec  1.09 GBytes  9.40 Gbits/sec    0   3.12 MBytes
# ...
# [  5]   0.00-30.00  sec  32.8 GBytes  9.40 Gbits/sec    0         sender
# [  5]   0.00-30.00  sec  32.8 GBytes  9.40 Gbits/sec              receiver

# 关键指标：
# Bitrate  — 实测吞吐量
# Retr     — TCP 重传次数
# Cwnd     — 拥塞窗口大小

2.2 多流测试

# 单流 TCP 往往无法跑满高带宽链路（受限于 RTT 和拥塞窗口）
# 多流测试模拟真实的多连接场景

# 8 个并行流
iperf3 -c server_ip -P 8 -t 30

# 输出会显示每个流和总和
# [SUM]   0.00-30.00  sec  32.8 GBytes  9.40 Gbits/sec  sender

# 单流 vs 多流的常见差异
# 10GbE, RTT=1ms:  单流可能 9.4 Gbps（足够）
# 10GbE, RTT=50ms: 单流可能只有 2-3 Gbps，多流可以跑满
# 原因：BDP = 10Gbps × 50ms = 62.5 MB，需要很大的窗口

2.3 UDP 测试

# UDP 带宽测试——需要指定目标速率
iperf3 -c server_ip -u -b 10G -t 30

# 输出包含丢包率
# [ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total
# [  5]   0.00-30.00  sec  34.9 GBytes  10.0 Gbits/sec  0.010 ms  0/1000000 (0%)

# 逐步增加速率找到丢包阈值
for rate in 1G 2G 5G 8G 9G 9.5G 10G; do
    echo "=== Testing $rate ==="
    iperf3 -c server_ip -u -b $rate -t 10 2>&1 | \
        grep "receiver" | awk '{print $7, $8, $12}'
done

2.4 反向测试与双向测试

# 反向测试（服务端 → 客户端）
iperf3 -c server_ip -R -t 30

# 双向同时测试
iperf3 -c server_ip --bidir -t 30

# JSON 输出（便于自动化处理）
iperf3 -c server_ip -t 10 -J > result.json
jq '.end.sum_sent.bits_per_second / 1e9' result.json
# 输出：9.4 （Gbps）

2.5 iperf3 高级选项

选项	说明	使用场景
`-w 128K`	设置 TCP 窗口大小	调试缓冲区影响
`-M 1400`	设置 TCP MSS	模拟 VPN/隧道环境
`-l 8K`	设置发送缓冲区块大小	调试分段影响
`-C bbr`	指定拥塞控制算法	对比不同算法性能
`-A 0,1`	设置 CPU 亲和（客户端,服务端）	避免 NUMA 影响
`-Z`	使用 zero-copy（sendfile）	测量最大吞吐能力
`--logfile`	输出到文件	长时间测试
`-O 3`	忽略前 3 秒	排除慢启动影响

三、netperf 请求-响应测试

3.1 netperf vs iperf3

iperf3 主要测量大块数据传输的吞吐量。但很多真实应用是请求-响应模式——一个小请求、一个小响应、反复往返。netperf 的 TCP_RR / UDP_RR 测试正是为此设计的。

# 安装 netperf
apt-get install -y netperf

# 启动服务端
netserver -p 12865

# TCP 流测试（类似 iperf3）
netperf -H server_ip -t TCP_STREAM -l 30

# TCP 请求-响应测试（关键）
netperf -H server_ip -t TCP_RR -l 30
# 输出：
# Socket Size   Request  Resp.   Elapsed  Trans.
# Send   Recv   Size     Size    Time     Rate
# 16384  87380  1        1       30.00    55000.00
# Trans. Rate = 55000 transactions/sec

# 每个 transaction = 一个 request + 一个 response
# 延迟 = 1/55000 = 18.2 μs

3.2 自定义请求/响应大小

# 模拟 HTTP 请求：100 字节请求，4KB 响应
netperf -H server_ip -t TCP_RR -l 30 -- \
    -r 100,4096

# 模拟 gRPC 请求：1KB 请求，10KB 响应
netperf -H server_ip -t TCP_RR -l 30 -- \
    -r 1024,10240

# UDP 请求-响应
netperf -H server_ip -t UDP_RR -l 30

# TCP Connect/Close（测量 TCP 握手速率）
netperf -H server_ip -t TCP_CRR -l 30
# TCP_CRR = 每次 transaction 都建立新连接
# 测量 connect() + send() + recv() + close() 的完整延迟

3.3 netperf 延迟直方图

# 使用 -D 选项获取更详细的延迟信息
netperf -H server_ip -t TCP_RR -l 30 -D 1

# 输出每秒的事务率，可以看到延迟的变化趋势

# 结合 -o 选项选择输出字段
netperf -H server_ip -t TCP_RR -l 30 \
    -o min_latency,mean_latency,max_latency,p99_latency,throughput

四、延迟测量

4.1 ping 的局限性

# ping 测量 ICMP RTT
ping -c 100 -i 0.1 target_host

# ping 的局限：
# 1. 测量的是 ICMP，不是 TCP/UDP
# 2. ICMP 可能被防火墙限速或丢弃
# 3. ICMP 在路由器上的优先级可能不同
# 4. 无法测量特定端口的延迟

# 使用 -f（flood ping）测量高速丢包
ping -f -c 10000 target_host
# 注意：需要 root 权限，可能影响网络

4.2 hping3 精确延迟测量

# hping3 可以发送 TCP/UDP 包测量延迟

# TCP SYN 延迟（到端口 80）
hping3 -S -p 80 -c 100 target_host
# len=46 ip=10.0.0.1 ttl=64 id=12345 sport=80 flags=SA seq=0 win=65535 rtt=0.3 ms

# UDP 延迟
hping3 --udp -p 53 -c 100 target_host

# TCP 延迟统计
hping3 -S -p 443 -c 1000 target_host 2>&1 | tail -3
# round-trip min/avg/max = 0.2/0.4/2.1 ms

# 指定源端口（绕过某些防火墙规则）
hping3 -S -p 80 -s 12345 -c 100 target_host

4.3 sockperf 微秒级延迟

# sockperf 专为精确延迟测量设计

# 服务端
sockperf sr --tcp -p 11111

# 客户端——ping-pong 模式
sockperf pp --tcp -i target_host -p 11111 -t 30
# 输出包含 avg/min/max/p50/p99/p999 延迟

# under-load 模式——在有负载的情况下测量延迟
sockperf ul --tcp -i target_host -p 11111 -t 30 \
    --msg-size 64 --mps 10000
# --mps 10000: 每秒 10000 条消息

# 典型输出：
# sockperf: Summary: Latency is 15.2 usec
# sockperf: Total Messages: 300000
# sockperf: [including warmup] RunTime: 30.000 sec
# sockperf: Latency (usec):
#   avg=15.2  std-dev=3.4  median=14.8
#   min=10.1  max=350.2
#   percentile 99.0 = 28.5
#   percentile 99.9 = 95.2
#   percentile 99.99 = 280.1

五、PPS 测试

5.1 小包 PPS 是真正的瓶颈

网络设备（包括服务器网卡）的性能受两个维度限制：
1. 带宽（bps）— 大包场景的瓶颈
2. 包速率（pps）— 小包场景的瓶颈

以 10GbE 为例：
• 最大带宽：10 Gbps
• MTU=1500 时最大 PPS：
  10,000,000,000 / (1518 × 8) = 823,000 pps ≈ 823K pps

• 最小包（64 字节）时理论 PPS：
  10,000,000,000 / (84 × 8) = 14,880,000 pps ≈ 14.9M pps
  （84 = 64 + 20 字节 IFG/Preamble）

• 但 Linux 内核收包通常在 1-3M pps 就达到 CPU 瓶颈
  这就是为什么 DPDK/XDP 存在的原因

5.2 使用内核 pktgen 测试

# pktgen 是 Linux 内核自带的高性能包生成器

# 加载模块
modprobe pktgen

# 配置脚本
cat > /tmp/pktgen_test.sh << 'SCRIPT'
#!/bin/bash
PGDEV=/proc/net/pktgen

# 清除之前的配置
echo "rem_device_all" > $PGDEV/kpktgend_0

# 添加设备
echo "add_device eth0" > $PGDEV/kpktgend_0

# 配置参数
echo "count 10000000" > $PGDEV/eth0      # 发送 1000 万包
echo "pkt_size 64" > $PGDEV/eth0          # 64 字节小包
echo "delay 0" > $PGDEV/eth0              # 无间隔
echo "dst 10.0.0.1" > $PGDEV/eth0         # 目标 IP
echo "dst_mac 00:11:22:33:44:55" > $PGDEV/eth0  # 目标 MAC

# 开始发送
echo "start" > $PGDEV/pgctrl

# 查看结果
cat $PGDEV/eth0
SCRIPT

chmod +x /tmp/pktgen_test.sh

六、测试方法论

6.1 测试前准备

步骤	操作	目的
记录环境	CPU/内存/网卡/OS/内核版本	可复现性
排除干扰	停止非必要服务	结果准确性
确认 MTU	`ip link show`	避免分片影响
检查 CPU 频率	`cat /proc/cpuinfo` 或 `cpupower`	排除节能模式
确认拥塞控制	`sysctl net.ipv4.tcp_congestion_control`	已知算法
时间同步	`chronyc tracking`	时间戳准确

6.2 测试的统计方法

# 跑一次 iperf3 得到的数字不可靠
# 至少跑 5 次以上，计算统计值

# 批量测试脚本
cat > /tmp/benchmark.sh << 'SCRIPT'
#!/bin/bash
SERVER=$1
RUNS=10
RESULTS=()

for i in $(seq 1 $RUNS); do
    bps=$(iperf3 -c $SERVER -t 10 -J 2>/dev/null | \
        jq -r '.end.sum_sent.bits_per_second // 0')
    gbps=$(echo "scale=2; $bps / 1000000000" | bc)
    echo "Run $i: $gbps Gbps"
    RESULTS+=($gbps)
done

# 计算统计值
echo "---"
echo "${RESULTS[@]}" | tr ' ' '\n' | \
    awk '{
        sum += $1; sumsq += $1*$1; 
        if(NR==1 || $1<min) min=$1;
        if(NR==1 || $1>max) max=$1;
        a[NR]=$1
    } END {
        avg = sum/NR
        stddev = sqrt(sumsq/NR - avg*avg)
        printf "Avg: %.2f Gbps\n", avg
        printf "Min: %.2f Gbps\n", min
        printf "Max: %.2f Gbps\n", max
        printf "StdDev: %.2f Gbps\n", stddev
        printf "CV: %.1f%%\n", stddev/avg*100
    }'
SCRIPT

chmod +x /tmp/benchmark.sh
# /tmp/benchmark.sh server_ip

6.3 常见测试陷阱

陷阱	说明	避免方法
CPU 瓶颈	CPU 跑满导致吞吐量低，误以为是网络问题	测试时观察 `mpstat -P ALL 1`
NUMA 跨域	网卡和 CPU 在不同 NUMA 节点	用 `numactl` 绑定到同一节点
慢启动	前几秒吞吐量低	使用 `-O 5` 忽略前 5 秒
单流上限	单个 TCP 流无法跑满高带宽高延迟链路	使用多流 `-P 8`
MTU 不匹配	路径中有更小 MTU 的设备	用 `tracepath` 检查 PMTU
防火墙影响	状态防火墙的 conntrack 开销	测试前暂时禁用或 NOTRACK
网卡中断集中	所有中断在 CPU 0	检查 `/proc/interrupts`
Offload 差异	TSO/GRO 开关状态不同	用 `ethtool -k` 检查并统一

6.4 测试结果报告模板

网络性能基准测试报告

测试日期：2025-07-31
测试人员：xxx

环境：
  发送端：Ubuntu 22.04, 内核 5.15, Intel Xeon E-2388G, 64GB RAM
  接收端：Ubuntu 22.04, 内核 5.15, Intel Xeon E-2388G, 64GB RAM
  网卡：Intel X710 10GbE（双口），Driver: i40e 2.20.12
  连接：直连（无交换机），Cat6a 线缆
  MTU：1500
  拥塞控制：cubic
  Offload：TSO=on, GRO=on, GSO=on

测试结果：

| 测试项 | 工具 | 参数 | 结果（avg ± stddev）|
|--------|------|------|---------------------|
| TCP 吞吐（单流）| iperf3 | -t 30 | 9.41 ± 0.02 Gbps |
| TCP 吞吐（8流）| iperf3 | -P 8 -t 30 | 9.42 ± 0.01 Gbps |
| UDP 吞吐 | iperf3 | -u -b 10G | 9.90 ± 0.03 Gbps |
| UDP 丢包率 | iperf3 | -u -b 10G | 0.01% |
| TCP RR | netperf | TCP_RR | 58,000 trans/s |
| TCP CRR | netperf | TCP_CRR | 12,000 trans/s |
| RTT | sockperf | pp | 15.2 ± 3.4 μs |
| P99 延迟 | sockperf | pp | 28.5 μs |

七、网卡 Offload 测试

7.1 硬件卸载对性能的影响

现代网卡支持多种硬件卸载功能，它们对性能测试结果有显著影响：

# 查看所有 offload 设置
ethtool -k eth0

# 关键 offload 功能
# TSO (TCP Segmentation Offload)：网卡硬件分段，减少 CPU 负载
# GRO (Generic Receive Offload)：将小包合并成大包再交给内核
# GSO (Generic Segmentation Offload)：延迟分段到最后一刻
# LRO (Large Receive Offload)：类似 GRO 但更激进
# Checksum Offload：网卡计算校验和

# 测试 offload 对吞吐量的影响
echo "=== TSO ON ==="
ethtool -K eth0 tso on
iperf3 -c server_ip -t 10 -J | jq '.end.sum_sent.bits_per_second / 1e9'

echo "=== TSO OFF ==="
ethtool -K eth0 tso off
iperf3 -c server_ip -t 10 -J | jq '.end.sum_sent.bits_per_second / 1e9'

# 恢复默认
ethtool -K eth0 tso on

Offload	影响	测试建议
TSO	发送吞吐量提升 50-200%	保持开启除非排查特定问题
GRO	接收吞吐量提升 30-100%	保持开启
Checksum	减少 CPU 使用率	保持开启
LRO	可能导致路由/桥接问题	仅端点使用

7.2 环回接口测试

# 使用环回接口（loopback）可以测试纯 CPU/内核性能
# 排除网卡和链路的影响

# TCP 吞吐
iperf3 -c 127.0.0.1 -t 10
# 典型结果：50-100 Gbps（取决于 CPU）

# TCP RR 延迟
netperf -H 127.0.0.1 -t TCP_RR -l 10
# 典型结果：200,000+ trans/s

# 如果环回性能就不高，说明瓶颈在内核或 CPU
# 如果环回高但实际网卡低，瓶颈在网卡/驱动/链路

八、真实场景测试

8.1 HTTP 吞吐量测试

# 使用 wrk 测试 HTTP 性能
# wrk 更适合测试 Web 服务器的性能

# 安装 wrk
apt-get install -y wrk

# 基本 HTTP 吞吐测试
wrk -t 4 -c 100 -d 30s http://server_ip/
# -t 4: 4 个线程
# -c 100: 100 个并发连接
# -d 30s: 测试 30 秒

# 输出：
# Requests/sec:  85000.00
# Transfer/sec:  10.50MB
# Latency   Avg    Stdev    Max   +/- Stdev
#          1.2ms   0.5ms   15ms   90.00%

# 使用 wrk2 可以控制固定请求速率并获得精确延迟分布
# wrk2 -t 4 -c 100 -d 30s -R 50000 http://server_ip/

8.2 DNS 性能测试

# 使用 dnsperf 测试 DNS 服务器性能
apt-get install -y dnsperf

# 准备查询文件
cat > /tmp/queries.txt << 'EOF'
example.com A
google.com A
github.com A
cloudflare.com AAAA
EOF

# 运行测试
dnsperf -s dns_server_ip -d /tmp/queries.txt -l 30

# 输出包含 QPS（Queries Per Second）和延迟统计

8.3 跨网络路径测试

# 使用 mtr 测试完整路径的延迟和丢包
mtr -rw -c 100 target_host

# 输出每一跳的延迟和丢包率
# HOST                Loss%   Snt   Last   Avg  Best  Wrst StDev
# 1. gateway           0.0%   100    0.3   0.3   0.2   0.5   0.1
# 2. isp-router        0.0%   100    2.1   2.2   1.8   5.3   0.4
# 3. core-router       0.0%   100    5.5   5.6   5.2   8.1   0.3
# 4. target            0.0%   100   10.2  10.3   9.8  15.1   0.5

# tracepath 测试 PMTU
tracepath target_host
# 输出路径上的 MTU 变化

# 使用 flent 进行综合网络质量测试
# flent 可以同时测量带宽和延迟（RRUL 测试）
# pip install flent
# flent rrul -H server_ip -l 60 -o result.png

九、容器与虚拟化环境测试

9.1 容器网络性能

容器网络引入了额外的开销——veth pair、bridge、NAT（MASQUERADE）、conntrack。需要分层测试确定瓶颈：

# 第一层：宿主机到宿主机（基线）
iperf3 -c other_host_ip -t 10

# 第二层：容器到宿主机
docker run --rm -it networkstatic/iperf3 -c host_ip -t 10

# 第三层：容器到容器（同主机）
# 在 pod-a 中运行 iperf3 -s
# 在 pod-b 中运行 iperf3 -c pod-a-ip -t 10

# 第四层：容器到容器（跨主机）
# 测量 overlay 网络（VXLAN/Geneve）的开销

# 预期性能降级：
# 宿主机直连：~9.4 Gbps（10GbE）
# 容器（host 网络）：~9.3 Gbps（接近无损）
# 容器（bridge）：~8.5 Gbps（veth + bridge 开销）
# 容器（overlay）：~7.0 Gbps（封装 + 解封开销）

9.2 虚拟化网络性能

# 测试虚拟化网络时注意：
# 1. virtio-net 比 e1000 性能高很多
# 2. vhost-net 减少用户态/内核态切换
# 3. DPDK + vhost-user 可以达到接近物理网卡的性能
# 4. SR-IOV 直通可以绕过虚拟交换机

# 查看 VM 使用的网络设备类型
lspci | grep -i net
# Virtio network device → 好
# Intel 82540EM (e1000) → 性能较差

# 多队列 virtio 设置
ethtool -l eth0
# 如果只有 1 个队列，需要在 libvirt XML 中增加：
# <driver name='vhost' queues='4'/>

十、持续性能监控

10.1 建立性能基线

# 用 cron 定期运行基准测试

cat > /usr/local/bin/network-baseline.sh << 'SCRIPT'
#!/bin/bash
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
TARGET="10.0.0.1"
LOG_DIR="/var/log/network-baseline"
mkdir -p "$LOG_DIR"

# TCP 吞吐
iperf3 -c $TARGET -t 10 -J > "$LOG_DIR/tcp_${TIMESTAMP}.json" 2>/dev/null

# TCP RR
netperf -H $TARGET -t TCP_RR -l 10 -- \
    -o mean_latency,p99_latency,throughput > \
    "$LOG_DIR/rr_${TIMESTAMP}.txt" 2>/dev/null

# RTT
ping -c 100 -q $TARGET > "$LOG_DIR/ping_${TIMESTAMP}.txt" 2>/dev/null

echo "[$TIMESTAMP] Baseline complete" >> "$LOG_DIR/baseline.log"
SCRIPT

chmod +x /usr/local/bin/network-baseline.sh

# 每天凌晨 3 点运行
# 0 3 * * * /usr/local/bin/network-baseline.sh

10.2 性能退化检测

# 对比历史基线，检测性能退化

# 提取最近 7 天的 TCP 吞吐量
for f in /var/log/network-baseline/tcp_*.json; do
    ts=$(basename "$f" .json | sed 's/tcp_//')
    bps=$(jq -r '.end.sum_sent.bits_per_second // 0' "$f")
    gbps=$(echo "scale=2; $bps / 1000000000" | bc)
    echo "$ts $gbps"
done | tail -7

# 如果最新值比 7 天均值低 10% 以上，触发告警

监控维度	正常范围	告警阈值
TCP 吞吐量	基线 ±5%	低于基线 15%
RTT	基线 ±20%	高于基线 50%
TCP RR	基线 ±10%	低于基线 20%
丢包率	< 0.01%	> 0.1%

十一、NUMA 与 CPU 对性能的影响

11.1 NUMA 架构下的网络测试

# 在 NUMA 服务器上，网卡所在的 NUMA 节点影响性能

# 查看网卡的 NUMA 节点
cat /sys/class/net/eth0/device/numa_node
# 输出：0

# 查看 CPU 的 NUMA 分布
lscpu | grep NUMA
# NUMA node0 CPU(s): 0-7
# NUMA node1 CPU(s): 8-15

# 将 iperf3 绑定到网卡所在 NUMA 节点
numactl -N 0 -m 0 iperf3 -s -A 0

# 客户端也绑定
numactl -N 0 -m 0 iperf3 -c server_ip -A 0 -t 30

NUMA 对性能的影响：

测试条件	吞吐量	说明
本地 NUMA 节点	9.4 Gbps	最优
远端 NUMA 节点	7.8 Gbps	跨 NUMA 内存访问延迟
不绑定（系统调度）	8.5 Gbps	偶尔跨 NUMA

11.2 CPU 频率对网络性能的影响

# 检查 CPU 是否在节能模式
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
# powersave → 频率会动态降低，影响性能测试

# 测试时使用 performance 模式
cpupower frequency-set -g performance

# 或者禁用所有节能
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor; do
    echo "performance" > "$cpu"
done

# 查看当前频率
cat /proc/cpuinfo | grep "cpu MHz" | head -4

# 测试完成后恢复
cpupower frequency-set -g ondemand

11.3 中断与软中断分析

# 测试期间观察 CPU 使用分布
# 打开一个监控窗口
mpstat -P ALL 1

# 关注：
# %irq    — 硬中断处理时间
# %soft   — 软中断处理时间（网络收发包）
# %usr    — 用户态 CPU 时间

# 如果某个 CPU 的 %soft 很高（>80%），说明中断集中
# 需要通过 RSS 或 RPS 分散到多个 CPU

# 查看软中断分布
watch -n 1 cat /proc/softirqs
# NET_RX 行显示每个 CPU 处理的接收软中断数量
# 如果只有 CPU0 在增长，说明需要配置 RSS/RPS

十二、工具对比总结

工具	测量维度	精度	适用场景	开销
iperf3	带宽、重传	中	链路吞吐量	低
netperf	带宽、RR 延迟	中	请求-响应模式	低
sockperf	μs 级延迟	高	延迟敏感场景	低
hping3	TCP/UDP 延迟	中	端口可达性 + 延迟	低
wrk/wrk2	HTTP QPS/延迟	中	Web 服务性能	中
pktgen	PPS	高	小包转发能力	高
mtr	路径延迟/丢包	中	路径质量	低
flent	带宽+延迟组合	中	缓冲膨胀分析	中
dnsperf	DNS QPS	中	DNS 服务器	低

12.1 带宽-延迟积（BDP）参考表

理解 BDP 是正确配置 TCP 窗口大小和解读测试结果的前提：

带宽	RTT	BDP	最小窗口大小
100 Mbps	1 ms	12.5 KB	16 KB
1 Gbps	1 ms	125 KB	128 KB
1 Gbps	10 ms	1.25 MB	2 MB
1 Gbps	100 ms	12.5 MB	16 MB
10 Gbps	1 ms	1.25 MB	2 MB
10 Gbps	10 ms	12.5 MB	16 MB
10 Gbps	100 ms	125 MB	128 MB
100 Gbps	1 ms	12.5 MB	16 MB
100 Gbps	10 ms	125 MB	128 MB

# 计算 BDP
# BDP (bytes) = Bandwidth (bps) / 8 × RTT (seconds)

# 快速计算脚本
calc_bdp() {
    local bw_gbps=$1
    local rtt_ms=$2
    local bdp=$(echo "scale=0; $bw_gbps * 1000000000 / 8 * $rtt_ms / 1000" | bc)
    local bdp_mb=$(echo "scale=1; $bdp / 1048576" | bc)
    echo "BDP = ${bdp_mb} MB (bw=${bw_gbps}Gbps, rtt=${rtt_ms}ms)"
    echo "建议 tcp_rmem max >= ${bdp_mb} MB"
}

# calc_bdp 10 50
# BDP = 62.5 MB (bw=10Gbps, rtt=50ms)
# 建议 tcp_rmem max >= 62.5 MB

参考文献

ESnet/Lawrence Berkeley National Laboratory, “iperf3 Documentation,” iperf.fr.
Hewlett-Packard, “netperf Documentation,” hewlettpackard.github.io/netperf.
Mellanox, “sockperf — Network Benchmarking Utility,” github.com/Mellanox/sockperf.
Gregg, B., “Network Performance Observability,” brendangregg.com, 2017.
Dugan, J. et al., “iperf3: A TCP, UDP, and SCTP network bandwidth measurement tool,” ESnet.
Salvatore, S., “Linux networking stack from the ground up,” 2020.
Linux Kernel Documentation, “Pktgen,” kernel.org/doc/Documentation/networking/pktgen.rst.

上一篇: 内核网络参数调优：sysctl 全景与实战 下一篇: 网络延迟优化：Nagle、TCP_NODELAY 与中断亲和

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2025-08-06 · network

文章导航

目录