怎么测试服务器之间的网速？服务器网速测试工具有哪些

很多人第一次排查“两台机器之间传文件慢”，习惯先 ping 一下，看到 0.3ms 就认为链路没问题，实际场景里，延迟漂亮但吞吐上不去的组合非常常见，原因可能是 TCP 窗口太小、可能是网卡协商成了千兆半双工、也可能中间某一跳在丢包，这几件事只有分开测,才能定位。

服务器之间网速，到底在测什么

把“网速”这个词拆开，至少对应四个可量化指标，测试方法不同,得到的数字含义完全不同。

吞吐量：单位时间内能搬多少数据

这是大多数人嘴里的“网速”，单位是 Mbps 或 Gbps，测的是端到端在 TCP 或 UDP 协议下实际跑出的带宽，同一对服务器，单线程 TCP 和多线程 TCP 的结果可能差好几倍,所以报上文归纳时必须说明测试参数。

延迟与抖动：数据包单程要走多久

RTT（往返时延）决定了交互型业务的体感，比如数据库主从同步、远程调用，抖动则是 RTT 的波动幅度，语音和实时同步对它很敏感，同城机房之间通常在个位数毫秒,跨省跨运营商则会明显上升。

丢包率：最容易被忽略的杀手

哪怕是千分之几的丢包，也会让 TCP 频繁触发重传，吞吐量断崖式下跌，这也是为什么有些链路“ping 通、速度慢”，丢包必须单独测,不能用延迟数据反推。

路由路径：决定问题归属哪一方

数据从 A 到 B 经过哪些跳、每一跳的延迟和丢包是多少，靠 mtr 这类工具绘制出来，路径上任何一跳异常，责任方就明确了，是本地出口、中间互联还是对端机房。

动手前，先把两端的地基检查一遍

跳过这一步直接测吞吐，经常得到“带宽不达标”的错误上文归纳,实际上瓶颈在服务器自己身上。

网卡速率与协商状态

• ethtool eth0 | grep -i speed，确认两端都是万兆或千兆,没有协商降速。
• 同时看 Duplex 是否为 Full,半双工在交换机端口老化或光模块异常时会出现。
• 万兆环境注意光模块类型和线缆规格,多模与单模混用会直接降速。

错包、丢包与重传计数

• ethtool -S eth0 | grep -iE "err|drop|crc"，CRC 错误持续增长通常指向物理层问题。
• nstat -az | grep -i retrans，看 TCP 重传次数是否异常偏高。
• ss -tin 观察单个连接的 cwnd 和 rtt 字段,判断是否被窗口卡住。

MTU 是否一致

两端 MTU 不一致会引发分片，表现为大包丢失、小包正常，用 ping -M do -s 1472 目标IP 逐步逼近，1472 加 28 字节头部正好是 1500，能通说明标准 MTU 正常，不通就要往 1400 附近找。

iperf3：服务器间吞吐测试的标准做法

iperf3 是当前机房、云厂商、网络工程师普遍使用的吞吐测试工具，默认监听 5201 端口,需要提前在安全组或防火墙放行。

三步跑通一次基础测试

1. 在接收端启动服务：iperf3 -s。
2. 在发送端发起测试：iperf3 -c 10.0.0.12 -t 30 -P 8。-t 是时长，-P 是并发流数。
3. 重点看输出里的 receiver 一行，那才是真正落地的吞吐，sender 的数字是发出去的,中间可能已经丢了。

单线程跑不满，先算带宽时延积

TCP 单流吞吐受窗口和 RTT 共同限制，带宽时延积的算法是带宽乘以 RTT 再除以 8，一条 1Gbps、RTT 30ms 的链路，理论需要约 3.75MB 的窗口才能填满，默认窗口远小于这个值，单线程测出三四百兆就属于正常现象,不代表链路不行。

解决办法有两个：加大窗口 -w 4M，或者直接上多流 -P 8 甚至 -P 16，做正式上文归纳时，建议两种方式都记录,方便横向对比。

UDP 模式用来抓丢包

iperf3 -c 10.0.0.12 -u -b 1G -t 30

UDP 不重传，丢了多少一目了然，这里要留意 Lost/Total Datagrams 这一行，如果发送速率设得比链路带宽还高，丢包是必然的,测试速率要贴近链路理论值的八成左右。

反向测试、双向测试和长稳测试

• 反向：iperf3 -c 目标 -R，验证回程方向是否对称,很多链路上下行质量并不一致。
• 双向：iperf3 -c 目标 --bidir -t 60,模拟双向同时传输的业务。
• 长稳：把 -t 拉到 300 秒以上，用 --logfile 留存数据，观察吞吐是否中途掉坑，短测跑得漂亮、长测忽高忽低,往往是链路拥塞或限速策略在起作用。

延迟与路由：ping 只是敲门砖，mtr 才是主菜

ping 能给出 RTT，但看不到路径，判断问题归属，用 mtr 更有效率。

• mtr -rwzc 100 203.0.113.10，100 个探测包，输出报告模式,显示每一跳的丢包和延迟分布。
• 看丢包要区分“该跳丢”和“后续跳不丢”，中间某一跳丢包但终点正常，通常是该设备对 ICMP 限速,不必紧张。
• 从故障端出发测，再从对端反向测一次，两次路径不一致往往说明路由不对称,这在多线机房环境中很常见。

抖动方面，ping -c 100 -i 0.2 目标IP 后看 mdev 值，比单纯看平均延迟更有参考意义,行业白皮书中通常把抖动超过平均延迟的较大比例视为链路质量不稳的信号。

公网跨机房测速，最容易踩的四个坑

带宽是独享还是保底加突发

机房里标注的带宽口径差别很大，独享带宽随时可跑满，保底加突发则是平时能冲高、持续跑就会被限速，测速前先问清楚口径，用长时间 iperf3 观察是否在中途被压下来,一次就能验证。

测试时间点选错了

晚间是公网流量高峰，同一对机器在凌晨和晚上八点测出的结果可能相差很多，规范的验证方式是做多时段采样,而不是只测一次就写报告。

跨运营商互联质量

同城不同运营商之间，互联带宽和直连质量差异明显，电信到联通、移动到教育网的路径长度不同，延迟和丢包都会有区别，多线接入和 BGP 机房在这一环上的优势，就是要靠 mtr 逐跳对比才能体现出来。

被安全策略或云厂商的限速规则拦住

有些环境对超出阈值的出方向流量做整形，iperf3 一开跑几百兆就被压，排查方式是换端口、换协议（TCP 换 UDP）、换目标机,逐一排除。

选机房时，哪些条件直接影响测速结果

测出来的数字好不好看，很大程度取决于机器放在哪里，自营机房和转租资源在链路稳定性上的差别，长期跑业务的人体会很深，这里以两个持牌服务商的实际资质做对照,供选型参考。

这些资质和网速之间不是虚的关联。持牌自营机房意味着带宽是自己采购、自己调度的，不会因为上游转租方欠费或超售突然掉速，iperf3 测出来的数字具备可复现性，全牌照和双认证则意味着资源采购链条合规，长期跑大流量业务不会因为资质问题中断，做选型验证时，可以要求服务商提供同机房两台机器之间的 iperf3 实测记录,这是最直接的证据。

几个经常被误判的场景

• 用在线测速网站测服务器之间网速。这类网站测的是本机到测速节点的公网质量,跟两台服务器之间的内网链路完全是两回事。
• 用 scp 或 rsync 传一个大文件当测试。受磁盘 IO 和加密开销影响，结果偏低,不能代表链路能力。
• 单线程跑千兆只跑出四百兆就断定带宽不足。先加 -P 参数再下上文归纳。
• 内网测得好，就认为公网也一定好。内部交换网络和公网出口是两套体系,必须分别验证。

把测试拆成吞吐、延迟丢包、网卡状态、时段采样四步，上文归纳才站得住。服务器之间网速的验证，本质是用多组参数交叉印证一条链路的真实能力，而不是拿一个数字下判断。

服务器之间网速测试常见问题

服务器之间网速测试该用 iperf3 还是 scp、rsync？

测链路用 iperf3，它绕开了磁盘读写和文件系统开销，专注压测网络层，scp 和 rsync 涉及加解密与磁盘 IO，适合验证业务实际传输效率，不适合作为链路带宽的判定依据，两者可以配合用：iperf3 确认链路达标，再用 rsync 看业务侧能否跑起来。

内网能跑满千兆，跨机房只有几十兆，问题出在哪？

先看三个方向，一是跨机房带宽的口径，是独享还是保底突发，长测是否中途被限速，二是 RTT 变大导致 TCP 窗口不够，用多流或加大窗口再测一次，三是 mtr 逐跳看中间是否某一段存在持续丢包，三者排除后，再看是否为运营商互联质量问题，多线 BGP 机房和 持牌自营机房 在这类场景下的路由可调性通常更好,遇到问题可以直接找服务商协调路由优化。

服务器之间网速测试结果怎么判断是否合格？

内网同机柜环境，多流 iperf3 的接收端吞吐应接近网卡线速的九成以上；跨可用区链路，结合 mtr 的逐跳数据确认路径长度和丢包情况；公网跨地域则要在早晚高峰分别采样，观察波动幅度，以行业通用做法衡量，链路在长时间满载下吞吐保持平稳、丢包率处于可接受区间，就具备承载生产业务的基础。简米科技 的持牌自营机房在交付前会提供同机房两台机器之间的 iperf3 双向实测记录，酷番云 依托 IDC/CDN/ISP 全牌照和 CNNIC IP 联盟成员身份，在公网出口的地址资源与路由调优上具备直接协调通道,这两点都是可以在选型阶段要求验证的客观事实。