本文目录导读：
网络性能测试是评估网络健康状况、诊断问题、保障业务体验的关键手段，根据测试目的（如测量带宽、延迟、抖动、丢包等）,通常分为以下几类核心方法：
核心指标与测试工具
在开始测试前,需要明确要测量的四个黄金指标：
- 带宽（Throughput）：单位时间内成功传输的数据量（Mbps/Gbps）。
- 延迟（Latency）：数据包从源到目的地的往返时间（RTT，通常以ms计）。
- 抖动（Jitter）：延迟的变化量（ms）,对实时音视频影响较大。
- 丢包率（Packet Loss）：传输过程中丢失的数据包占比。
常用测试工具：
| 工具 | 主要用途 | 协议 | 特点 |
|---|---|---|---|
| ping | 测延迟、丢包、连通性 | ICMP | 最基础、最常用，适合快速排查。 |
| traceroute / tracert | 路径跟踪，定位延迟断点 | ICMP / UDP | 显示数据包经过的每一跳路由器及其延迟。 |
| iPerf / iPerf3 | 带宽和吞吐量测试 | TCP / UDP | 行业标准工具，可调节窗口、线程等参数。 |
| qperf | 延迟和带宽测试 | TCP / RDMA | 擅长测试低延迟网络（如InfiniBand）。 |
| mtr | 综合延迟 + 丢包 + 路径 | ICMP | 结合 ping 和 traceroute，持续追踪路径状态。 |
| netperf | 吞吐量、延迟、CPU占用 | TCP / UDP | 适合高负载下的性能基准测试。 |
| wrk / ab | HTTP/HTTPS 吞吐量 | HTTP | 测试Web服务器（如Nginx、Apache）的请求处理能力。 |
| Flent | 综合测试（结合NetPerf, iPerf） | 多种 | 图形化展示，测试TCP友好性和缓冲区膨胀。 |
分场景的测试方法
基础连通性与延迟测试（ping / mtr）
- 命令示例：
ping -c 100 -s 1400 8.8.8.8-c 100：发送100个包（避免偶然性）。-s 1400：模拟实际数据包大小（默认56字节太小）。
- 结果解读：
- 延迟 > 50ms 可能影响互动游戏；> 150ms 影响实时通话。
- 丢包 > 0.5% 需警惕；> 1% 会导致明显卡顿。
- 高级用法：
mtr -r -c 50 8.8.8.8可看到“是哪一跳路由器导致的丢包”。
带宽与吞吐量测试（iPerf3 / iPerf3）
这是最可靠的带宽测试方式,需一台服务器端和一台客户端。
- 服务器端（监听）：
iperf3 -s -p 5201 - 客户端（发起测试）：
- TCP带宽（默认）：
iperf3 -c <服务器IP> -p 5201 -t 30 -P 4-t 30：测试30秒。-P 4：4个并行流（模拟多会话，更容易打满带宽）。
- UDP带宽（测试稳定质量）：
iperf3 -c <服务器IP> -u -b 1000M -t 30-u：UDP模式。-b 1000M：目标发送速率（如尝试1000Mbps，看实际接收率）。- 重点看：Jitter（抖动）和 Packet Loss。
- TCP带宽（默认）：
- 注意：iPerf3 测试结果受两端CPU和网卡驱动影响较大,建议关闭防火墙或放行端口。
网络路径与瓶颈诊断（traceroute / pathping）
用于发现“问题出在第几跳”。
traceroute -n www.example.com（Linux）或tracert -d www.example.com（Windows）- 识别问题：
- 如果某跳延迟突然飙升（如1ms -> 200ms）,则该路由器或链路可能存在拥塞。
- 如果某跳显示 ，可能是该节点禁止ICMP，也可能是真的断连（需结合mtr判断）。
应用层性能测试（Web / 数据库 / 流媒体）
- Web服务器：
wrk -t 12 -c 400 -d 30s http://your-server.com/测试每秒请求数（RPS）和延迟分布（P99延迟）。
- 流媒体：使用
ffplay或VLC拉流，配合tshark抓包分析，重点看RTP包的到达间隔、重传率。 - 数据库：
sysbench或pgbench测试SQL查询吞吐量,网络延迟会影响短连接场景。
全路径压力测试（工控 / 数据中心场景）
- 多流并发：使用 iPerf3 的
-P参数、-R（反向测试）。 - 大包/小包混合：模拟VoIP（小包）和文件传输（大包）并存场景。
- 长时稳定性：
iperf3 -t 3600测试1小时，观察带宽是否掉速（可能因散热、缓冲区填满导致丢包）。
测试前的注意事项（避免无效数据）
- 排除本地瓶颈：
- 确保客户端和服务器CPU、内存、磁盘I/O不成为瓶颈（测试时可用
top/perfmon观察）。 - 有线优先于Wi-Fi：Wi-Fi的干扰、信号衰减会反映为随机延迟和丢包,掩盖真实网络质量。
- 确保客户端和服务器CPU、内存、磁盘I/O不成为瓶颈（测试时可用
- 防火墙/安全组：放行 iPerf3（TCP 5201）、ping（ICMP）、traceroute（UDP高端口）等协议。
- 全双工/半双工：检查网卡双工模式（应设为自动协商并锁定为Full Duplex）,半双工会导致严重冲突和重传。
- 时钟同步：测试延迟时，客户端与服务器时钟偏差会严重失真（NTP同步误差应在1ms内）。
- 背景流量干扰：测试期间关闭其他大流量应用（如云盘同步、视频会议、系统更新）。
- 工具选择：尽量使用相同版本（尤其是 iPerf2 与 iPerf3不兼容）。
常见问题与快速定位思路
| 现象 | 可能原因 | 快速验证方法 |
|---|---|---|
| ping 通，但网页/应用慢 | MTU设置不正确、防火墙丢包、HTTP性能瓶颈 | ping -f -l 1472 <网关>（测试MTU）；使用 httpstat 分析请求阶段 |
| 延迟高且稳定 | 距离远（跨洋）、路由绕路 | traceroute 看跳数；确认是否走了 VPN / CDN 路径 |
| 延迟抖动大 | Wi-Fi干扰、拥塞、网卡缓冲区过小 | 有线测试；iperf3 -u 看Jitter；检查交换机队列丢弃 |
| 带宽远小于预期 | 网线/光模块故障、双工不匹配、协商速率低 | ethtool <网卡名> 查看 Speed 和 Duplex；更换网线/模块 |
| 丢包集中在某几跳 | 中间节点负载高、流量整形、安全策略 | mtr 持续观察；联系上游运营商或网络管理员 |
总结建议
- 日常巡检：使用
mtr每天跑一次,记录基线。 - 故障排查：顺序自查：物理层（网线/光模块） -> 链路层（双工/协商） -> 网络层（路由/防火墙） -> 传输层（TCP窗口/拥塞）。
- 自动化测试：可编写脚本循环执行
iperf3和ping -f，结合 Grafana + InfluxDB 可视化网络波动。
如果你有特定的测试场景（如VPN、Wi-Fi 6、数据中心内网、5G、直播推流）,可以进一步细化方法。
标签： 延迟抖动