我刚刚安装了新的宽带，想用 iperf3 测试它的吞吐量。但是它给出的结果似乎与更传统的速度测试有很大不同。
E:\tmp> iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-10.01 sec 13.1 MBytes 11.0 Mbits/sec sender
[ 4] 0.00-10.01 sec 13.1 MBytes 11.0 Mbits/sec receiver
而在线速度测试显示预期结果约为 150 Mbits
3.testdebit.info 已从 azure 进行测试，并且始终保持在 330Mbits 左右（虽然谁知道这意味着什么！）
我尝试过各种不同的服务器，包括托管在 Azure 上的 Linux 机器 - 它向另一个 Azure 机器提供约 100Mbits 的带宽。这也在端口 80 上执行，以排除任何 ISP 限制。所有这些结果都是可比较的。
下载一个 3.5GB 的文件需要 210 秒，大约需要 130Mbit
有人可以解释一下为什么 iperf3 会这么低吗（或者我真的很笨并且读错了！）
这些都在同一台计算机上，通过以太网，因此不会受到无线等干扰。
编辑以添加
使用 iperf2 执行相同的测试（在 Windows 客户端（iPerf 2.0.5-3）和 ubuntu（iperf 版本 2.0.5）上）得到以下结果
E:\tmp\iperf2> iperf -c <hidden>.cloudapp.net -p 5201
------------------------------------------------------------
Client connecting to <hidden>.cloudapp.net, TCP port 5201
TCP window size: 63.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.0.2 port 51816 connected with <hidden> port 5201
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 12.1 MBytes 10.0 Mbits/sec
从基于 Linux 的 NAS 执行相同的操作
Nas:~# iperf3 -c 3.testdebit.info
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 14.5 MBytes 12.2 Mbits/sec receiver
使用 -R 标志
E:\tmp> iperf3 -c 3.testdebit.info -R
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 58.0 MBytes 48.6 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 57.0 MBytes 47.8 Mbits/sec receiver
为了确保这不是服务器问题，我已将 Azure VM 升级到可以从 3.testdebit.info 服务器拉取 600Mbit 上行 / 1Gbit 下行的大小
回应 John Looker 的回答
我提出这个问题的主要目的是试图理解为什么 iperf 给出的结果如此不同。我知道上传被大量共享，我对此并不太关心（或者至少这是一个不同的问题！）
我使用的 Azure 服务器位于北欧和西欧（我记得是阿姆斯特丹和爱尔兰），在线速度测试结果达到 240Mb/s
然而，问题似乎是多线程，我刚刚重新运行了测试，使用四个线程而不是默认线程 -
E:\tmp>iperf3 -c 3.testdebit.info -R -P 5
Connecting to host 3.testdebit.info, port 5201
Reverse mode, remote host 3.testdebit.info is sending
- - - - - - - - - - - - - - - - - - - - - - - - -
[SUM] 0.00-10.00 sec 195 MBytes 163 Mbits/sec 50 sender
[SUM] 0.00-10.00 sec 190 MBytes 160 Mbits/sec receiver
答案1
- 良好的传统速度测试是多线程的，并会与速度测试服务器建立多个连接。从而最大限度地发挥您的连接的潜力。
http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#324
iPerf3 似乎仅创建两个连接（使用默认选项），这可能不足以最大化您的 152Mb 宽带，特别是在出现拥塞时。
您的下载测试还表明有多线程连接。
下载一个 3.5GB 的文件需要 210 秒，大约需要 130Mbit
但你的计算是错误的。
((3.5GB x 8bits x1024x1024x1024)/210s)/1000000Mbit = 平均143Mb/s。
143Mb/s 的平均速度对于 152Mb 层的下载来说已经很不错了。
虽然 152Mb 层的最大突发下载速度为 161Mb/s（您的调制解调器配置过高以保证速度），但由于多种因素，平均速度通常会略低。
- 服务器进行速率限制。
- TCP 接收窗口需要时间来提高速度。
- 电缆调制解调器请求-授予周期。
- 节点拥塞。您正在与数百人共享您的有线连接（因此也共享您的下行信道）。您在有线调制解调器上锁定的 8 x 256 QAM 下行信道的最大可用带宽为 400Mb，来自节点。此带宽由您和您有线上与您使用相同信道的所有其他用户共享。当其他用户在您下载期间使用他们的连接时，速度自然会略有不同。
- 路线拥堵。
- 服务器拥塞。
- 任何数据包丢失和重新传输。
上行带宽与您到节点的电缆上的其他用户竞争激烈。
如果您锁定了 2 x 16 QAM 上行信道，那么您将与许多其他用户共享 2 x 17Mb = 34Mb。如果您锁定了 2 x 64 QAM 上行信道，那么您将与许多其他用户共享 2 x 27Mb = 54Mb。
- 长距离传输时，延迟将成为影响传输速度的一个因素。
您没有说明您使用的是哪个 Azure 服务器，是英国、欧洲还是美国。
您的 iPerf3 服务器位于法国，可能会也可能不会通过 LINX 路由，具体取决于您的位置。一旦离开 VM 网络，路由拥塞有时可能会成为问题，尤其是在对等点。
- 非标准端口通常会被视为 P2P 流量。 http://www.thinkbroadband.com/faq/sections/flash-speed-test.html#323
虽然在 30Mb 及以上的层级上下载、流媒体、游戏等没有下行流量管理，但如果您的流量被归类为 P2P，那么它将受到流量管理并且在高峰时段降低速度。
原因是上行带宽非常稀缺，因为它由数百名用户共享，因此任何可能淹没上行的程序都会对电缆上的每个人都非常不利。这也是为什么上行仍然受到流量管理的原因。
在高峰时段之外，您可以按照自己喜欢的任何方式最大限度地利用您的连接。
小心使用小文件大小的测试。这里有一系列的测试文件可供您使用：http://www.thinkbroadband.com/download/
您的下载不太可能由 CDN 提供或缓存在 VM 网络内。当我使用 152Mb 时，我经常直接从服务器下载并以 161Mb 的速度流式传输。CDN 往往会使传输速度变慢而不是变快！
您需要提供有关测试策略的更多细节以回答原始问题。
答案2
请注意，IPerf 默认为“上传”测试：IPerf 客户端（-c）发送TCP 数据到 IPerf 服务器（-s）。看起来您正在 LAN 上运行客户端并连接到托管在公共 Internet 上的 IPerf 服务器，因此您正在测试新宽带连接的上传速度，而不是下载速度。
-s要测试其下载速度，请反转您以/调用的那一端-c，或使用-r指定您希望它在进行正常测试后执行“反向”（下载）测试。
请注意，如果您的 LAN 机器位于 NAT 或防火墙后面，您可能必须适当地打开/映射/转发端口才能进行下载测试。