在Linux环境下进行网络带宽测试,核心在于明确测试目的：是验证运营商提供的公网接入质量，还是排查内网服务器间的最大传输吞吐量，对于运维工程师而言，iperf3 是进行专业内网带宽测试的黄金标准，它能精准测量TCP和UDP性能；而 speedtest-cli 则是快速检测公网上下行速率的便捷工具，掌握这两类工具的组合使用，并结合 iftop 或 nload 进行实时流量监控，构成了完整的Linux带宽诊断体系。
公网带宽测试：speedtest-cli 的实战应用
当需要评估服务器连接互联网的实际速度,或者验证运营商带宽是否达标时，命令行工具 speedtest-cli 是最佳选择，它基于Speedtest.net的基础设施，能够快速测试出下载、上传速度以及网络延迟。
使用前需确保Python环境已安装,通常通过 pip install speedtest-cli 或包管理器直接安装即可，最基础的测试命令 speedtest-cli 会自动寻找最近的服务器进行测速，但在专业场景中，为了获得更稳定的数据，建议指定服务器列表，使用 speedtest-cli --list 命令列出所有可用服务器，根据地理位置或运营商选择ID，然后使用 speedtest-cli --server [ID] --simple 进行针对性测试。
需要注意的是，公网测速结果受限于运营商链路拥塞情况和对端服务器负载，如果测试结果远低于预期，应先排除本地防火墙QoS策略限制，再进行多次测试取平均值，使用 --bytes 参数可以以字节为单位显示数据，更符合Linux系统的读取习惯。
内网吞吐量测试：iperf3 的深度解析
对于数据中心、局域网或服务器间的带宽测试，speedtest-cli 往往受限于公网瓶颈，无法发挥网卡的最大性能，iperf3 作为客户端/服务端（C/S）架构的工具，能够通过内存到内存的数据传输，测试出网络链路的真实极限带宽。
iperf3 的核心优势在于其参数的可控性，测试前，需在一端运行 iperf3 -s 启动服务端监听，另一端运行 iperf3 -c [服务端IP] 发起连接，默认情况下，iperf3 使用单线程TCP流进行测试，在现代高带宽网络（如10Gbps及以上）中，单TCP流往往无法打满带宽，这是受限于TCP协议的窗口大小以及单核CPU的处理能力。
为了获得准确的带宽上限,必须使用多线程并行测试，通过 -P 参数指定并发线程数，iperf3 -c [IP] -P 4，开启4个线程同时传输，这通常能显著提升吞吐量数据，更接近物理链路的真实性能，调整TCP窗口大小（-w 参数）对于高延迟长肥网络至关重要，设置较大的窗口（如1M）可以避免因等待ACK确认而导致传输停滞。
在专业排查中,UDP测试 同样不可或缺，使用 -u 参数切换到UDP模式，配合 -b 参数指定带宽目标（如 iperf3 -c [IP] -u -b 10G），可以模拟特定速率下的网络状况，UDP测试不仅能测试带宽，更能直观地反映出丢包率和抖动，如果在内网环境下测试出现丢包，通常意味着链路中存在拥塞、物理接口故障或交换机缓冲区溢出。
实时流量监控与辅助分析
单纯的测速只能提供某一时刻的快照,而带宽问题往往是间歇性的，结合实时监控工具，可以捕捉到瞬间的流量峰值。
iftop 是一款类似于top的流量监控工具，它能够显示各个主机之间的实时连接带宽，通过 iftop -i [网卡名] 启动后，界面会列出源IP、目的IP以及发送和接收的速率。iftop 的核心价值在于它能迅速定位带宽占用者，当发现带宽异常占用时，可以直接在屏幕上看到是哪台IP在大量传输数据，从而快速判断是业务激增还是遭受攻击。
另一个轻量级工具是 nload，它专注于显示整体网卡的进出流量，与iftop不同，nload以图形化的进度条形式展示当前流量和平均流量，非常适合用来观察iperf3测试过程中的流量曲线是否平滑，或者监控服务器在业务高峰期的总体负载情况。
专业测试中的常见误区与调优
在进行Linux带宽测试时,仅仅会运行命令是不够的，必须理解底层机制对结果的影响。
CPU瓶颈，iperf3在测试高带宽（如25Gbps或100Gbps）时，CPU的单核处理能力往往成为瓶颈，而非网络链路本身，应使用 taskset 命令将iperf3进程绑定到不同的CPU核心上，或者确保启用了多线程测试，以充分利用多核性能。
中断合并，现代网卡为了降低CPU中断频率，默认开启了中断合并，但在进行小包测试或低延迟测试时，这会导致数据包在网卡缓存中积压，造成延迟飙升，在测试前，使用 ethtool -C [网卡] adaptive-rx off adaptive-tx off 关闭自适应中断合并，可以获得更真实的延迟数据。
双工模式与速率协商，物理层的不匹配是导致带宽减半的常见原因，使用 ethtool [网卡] 检查 Speed 和 Duplex 设置，确保两端协商为 Full Duplex（全双工）且速率匹配（如1000Mbps/Full），如果出现大量 FCS 错误或碰撞，通常意味着物理链路存在故障或双工不匹配。
相关问答
Q1：为什么使用 iperf3 测试内网带宽时，实际速度只有理论值的一半？
A1：这种情况最常见的原因是双工模式不匹配（一端全双工，一端半双工）或网线物理故障，如果使用单线程测试，可能触及了TCP窗口大小的限制或CPU单核处理能力的瓶颈，建议先检查 ethtool 输出确认物理层状态，然后尝试使用 -P 4 开启多线程测试，并增大 -w 窗口参数。
Q2：在进行 UDP 带宽测试时，服务器端显示大量丢包，如何判断是链路问题还是服务器处理不过来？
A2：需要结合系统负载判断，如果在测试期间，服务器的 CPU 软中断（si）占用率极高，说明服务器网卡处理能力达到极限，丢包是服务器性能瓶颈导致的，CPU 负载很低但丢包率很高，则通常是中间链路（交换机、路由器）拥塞或物理线路质量差造成的，此时应降低 -b 指定的目标带宽，寻找无丢包的临界点。
希望以上的带宽测试方案能帮助大家更精准地掌握网络状态,如果你在日常运维中有独特的测速技巧或遇到过棘手的网络瓶颈，欢迎在评论区分享你的经验和解决方案。
