如何测试Linux网络吞吐量 iperf多线程测试方法

要测试linux网络吞吐量真实上限，必须使用iperf3配合多线程（-p参数）进行测试。1. 准备工作：确保两台linux机器安装iperf3；2. 服务器端启动监听模式（iperf3 -s）；3. 客户端使用多线程发起测试，如tcp测试命令为iperf3 -c -p 8 -t 30，udp测试则加-u和-b参数；4. 观察结果时重点关注带宽、抖动、丢包率及重传次数等指标。多线程能有效绕过单线程cpu瓶颈，更真实反映网络性能。此外，硬件性能、内核参数、驱动固件、mtu设置、防火墙及虚拟化等因素也会影响实际吞吐量，需综合排查。

要测试Linux网络吞吐量，特别是想摸清真实上限，iperf3配合多线程（-P 参数）几乎是绕不开的。它能帮你模拟多路并发的数据流，把网络带宽榨干，看看到底能跑多快。

解决方案

使用iperf3进行多线程网络吞吐量测试，通常需要一台服务器作为接收端（或发送端），另一台作为客户端（或接收端）。

1. 准备工作： 确保两台Linux机器都安装了iperf3。大多数发行版可以直接通过包管理器安装，比如：

• Debian/Ubuntu: sudo apt install iperf3
• CentOS/RHEL: sudo yum install iperf3 或 sudo dnf install iperf3

2. 服务器端操作： 在一台机器上启动iperf3服务器模式，它会监听默认的5201端口（也可以通过-p参数指定）。

iperf3 -s

这台机器会等待客户端连接并发送数据。

3. 客户端操作： 在另一台机器上，运行iperf3客户端模式，指向服务器的IP地址，并使用-P参数指定并发的线程数。线程数一般可以根据CPU核心数或者预期的带宽来调整，比如4、8、16甚至更多。 TCP测试（推荐，模拟实际应用场景）：

iperf3 -c <服务器IP地址> -P 8 -t 30

• -c : 指定iperf3服务器的IP地址。
• -P 8: 指定使用8个并发线程。这是关键，多线程能更好地模拟高负载，避免单线程CPU瓶颈。
• -t 30: 指定测试持续30秒。你可以根据需要调整时间，确保测试结果稳定。

UDP测试（用于测试最大无损带宽和丢包、抖动）：

iperf3 -c <服务器IP地址> -u -b 1G -P 8 -t 30

• -u: 指定使用UDP协议。
• -b 1G: 指定UDP带宽上限为1Gbps。这个值需要根据你的网络预期带宽来设定，如果设得太低，可能测不出真实上限；设得太高，可能会导致大量丢包。
• 其他参数同TCP测试。

4. 观察结果： 客户端和服务器端都会输出测试结果。主要关注Bandwidth（带宽）这一列，它显示了每个线程以及总的吞吐量。UDP测试还会显示Jitter（抖动）和Lost/Total Datagrams（丢包率）。

为什么多线程对于网络吞吐量测试至关重要？

我个人经验是，单线程iperf3在现代高速网络上，经常跑不满带宽。这不是网络不行，很可能是你的CPU或者TCP/IP协议栈在单线程模式下成了瓶颈。比如，单个CPU核心处理网络中断、TCP协议栈的计算开销等，都可能限制了数据流。当你面对万兆甚至更高带宽的网络时，单个TCP流可能根本无法充分利用全部带宽，因为TCP的滑动窗口机制、网络延迟、以及操作系统层面的上下文切换开销都会成为限制因素。

多线程就好比你不是一个人搬砖，而是找了一队人一起上，效率自然高了。每个线程都建立一个独立的TCP连接，这样就能并行地发送或接收数据。这不仅能更好地模拟真实世界中多应用、多用户并发访问网络的场景，更能有效地压榨出网卡的全部潜力，绕过单核CPU或单TCP流的瓶颈，从而测出更接近网络链路真实上限的吞吐量。尤其是在测试跨数据中心、跨地域的网络时，高延迟环境下，单线程TCP的性能会急剧下降，多线程的作用就更加凸显了。

如何有效解读iperf3测试结果？

看iperf3的测试结果，主要就是Bandwidth（带宽）那一行。但别光看它，里面门道不少。

• Bandwidth (带宽): 这是最直观的指标，显示了在测试期间每秒传输的数据量，通常以Mbps或Gbps为单位。客户端和服务器端的报告都值得看，有时候会有细微差别。如果测试结果远低于你网络的理论带宽，那就要考虑是不是有瓶颈了。
• Jitter (抖动): 主要在UDP测试中出现。它衡量了数据包到达时间间隔的变化。高抖动意味着数据包到达的顺序或时间不规律，这对于实时应用（如VoIP、视频会议）来说是灾难性的。
• Lost/Total Datagrams (丢包率): 同样主要在UDP测试中出现。它表示在传输过程中丢失的数据包占总发送数据包的比例。高丢包率直接影响数据完整性和应用性能。即便带宽看起来很高，但如果丢包率也很高，那这个带宽的质量是存疑的。
• Retransmits (重传次数): 在TCP测试中，iperf3可能会报告重传次数。如果重传次数很多，说明网络不稳定，可能存在拥塞、链路质量差或者MTU不匹配等问题。重传会显著降低有效吞吐量。
• Interval (时间间隔): iperf3会每隔一段时间（默认1秒）输出一次结果。观察这些间隔内的带宽变化，可以发现网络吞吐量是否稳定，有没有突然的波动。

解读时，要综合来看。比如，TCP测试跑出了10Gbps，但重传率很高，那说明网络虽然快，但稳定性可能不佳。UDP测试带宽很高，但丢包率和抖动也高，那这样的网络承载实时业务是会有问题的。有时候，客户端和服务器端报告的带宽会略有不同，这通常是由于统计方式、或者网络方向（上传/下载）的差异造成的，一般以服务器端的报告为准，因为它通常能更准确地反映接收到的数据量。

除了iperf3，还有哪些因素会影响Linux网络吞吐量？

别以为iperf3跑出来就是网络的全部了。网络吞吐量是个复杂的系统工程，除了iperf3工具本身，还有很多底层和上层因素会影响最终结果。我曾经就遇到过，明明网络设备都万兆了，结果服务器跑不满，最后发现是别的问题。

• 硬件瓶颈：
  • 网卡（NIC）性能： 你的网卡本身支持多少带宽？PCIe插槽版本和通道数够不够？比如一块万兆网卡插在PCIe 2.0 x1的槽位上，是跑不满的。
  • CPU性能： 网络I/O处理、中断处理、TCP/IP协议栈的计算都需要CPU资源。如果CPU核心数不够或者主频太低，在高吞吐量场景下很容易成为瓶颈。
  • 内存带宽： 数据在内存和网卡之间传输，内存带宽也可能成为限制。
• Linux内核网络参数调优：
  • TCP缓冲区大小： net.ipv4.tcp_rmem、net.ipv4.tcp_wmem、net.core.rmem_max、net.core.wmem_max等参数决定了TCP接收和发送缓冲区的大小。如果这些缓冲区太小，尤其是在高延迟网络中，TCP滑动窗口无法充分利用，吞吐量就会受限。
  • TCP拥塞控制算法： Linux内核默认的TCP拥塞控制算法（如Cubic）可能不适合所有场景。BBR算法在某些高延迟、高带宽网络中表现更好，可以尝试切换：sysctl -w net.ipv4.tcp_congestion_control=bbr。
  • 中断处理： 网卡产生大量中断，如果中断处理不能均匀分配到多个CPU核心，可能导致某个CPU核心过载。irqbalance服务或手动设置中断亲和性（/proc/irq//smp_affinity）可以优化。
• 驱动和固件：
  • 网卡驱动： 老旧或不兼容的网卡驱动可能导致性能问题或不稳定性。确保使用最新的稳定驱动。
  • 网卡固件： 有时候网卡固件版本也会影响性能。
• MTU (Maximum Transmission Unit)： 网络路径中的MTU不匹配可能导致分片和重组，增加开销。通常建议将MTU设置为1500，或者在特定场景下（如巨型帧）设置为9000。
• 防火墙和安全策略： 防火墙规则、SELinux等可能会引入额外的处理开销，甚至阻断部分流量。在测试时，可以暂时禁用或简化防火墙规则，以排除其影响。
• 虚拟化开销： 如果是在虚拟机中测试，虚拟化层本身会引入性能开销，包括虚拟网卡、虚拟交换机等。确保虚拟机分配的CPU、内存资源充足，并使用virtio等高性能驱动。
• 其他网络设备： 路由器、交换机、线缆质量等，这些设备自身的性能瓶颈或配置问题，都会直接影响端到端的吞吐量。

所以，当iperf3结果不如预期时，不要只盯着iperf3本身，更要深入到系统层面去排查，这才是解决问题的关键。

以上就是如何测试Linux网络吞吐量 iperf多线程测试方法的详细内容，更多请关注php中文网其它相关文章！