我曾经iperf3测量过 TCP 窗口对吞吐量的影响。我正在测量位于不同物理主机上的两个虚拟机之间的吞吐量。所以我写了一个 Python 脚本，iperf3用不同的窗口大小（2 KB -1024 KB）调用并绘制了吞吐量。事实证明，在没有定义窗口大小的情况下，没有一个窗口大小能达到我测量的几乎一样高的吞吐量。
此命令测量的吞吐量约为 250 Mbits/s：
iperf3 -c 10.0.0.3 -t 120
这是我用于以下情节的命令：
iperf3 -c 10.0.0.3 -t 120 -w <window size>
谁能解释一下，为什么没有指定窗口大小的吞吐量要高得多？如果未指定，我也找不到使用的默认窗口大小。如果未指定，是否iperf3使用灵活的窗口大小？
编辑我在tcpdump 这里
上传了两个输出文件。它捕获了带有和不带有标志的iperf3流量。-w在开始之前iperf3开始直到结束之后。我在 WireShark 中查看了它，但仍然无法弄清楚用于连接的 TCP 窗口大小。
接收窗口大小 (rwin) 将在 TCP 会话期间自动增加和减少，具体取决于连接最终的损耗程度。因此，当您从 iperf 中省略 -w 标志时，可能会动态缩放窗口大小高于静态值。请记住，最大理论吞吐量是 rwin/delay。
但是，根据该图，您的带宽上限似乎在 70Mbit 左右，并且提高窗口大小没有任何影响。由于窗口大小似乎没有限制带宽，是否还有其他可能消耗它的东西 - 您是否通过 Wifi 执行这些测试？或者，您能否再次检查当您使用 -w 标志设置大于 256 的窗口大小时，它是否确实通过使用 tcpdump/Wireshark 验证“在线”发送？
这并不令人震惊。如今，我们自动调整分配给 TCP 缓冲区的 RAM 量（即最大 TCP 窗口大小），并通过指定窗口大小来关闭自动调整。
带宽延迟乘积约为 64KB 的平顶向我表明，没有协商合适的窗口缩放选项，因此有效的 TCP 缓冲区保持在 64KB。
顺便说一句，如果在最有利的情况下，同一主机上的虚拟机之间只能获得 250Mbps 的吞吐量，则会出现严重的吞吐量问题。您应该确保您使用的是半虚拟化的 virtio 网络接口，并且这些虚拟机位于同一个网桥上。要推理网络性能，您确实需要在硬件受到限制的情况下获得最佳案例性能。
正如马可所说，
接收窗口大小 (rwin) 将在 TCP 会话期间自动增加和减少，具体取决于连接最终的损耗程度。因此，当您从 iperf 中省略 -w 标志时，可能会动态缩放窗口大小高于静态值。请记住，最大理论吞吐量是 rwin/delay。
当您考虑这一点并考虑TCP 窗口缩放时，您的 1,024 KB 窗口远低于 1,073,725,440 字节（约 1 GB）的最大大小。这并不是说 iperf 会达到那个大小，但是当未指定 -w 标志时，它很可能会超过 1,024 KB。
最好的办法是重做测试并同时运行数据包捕获。这样您就可以看到窗口大小的值。
查看 RTT 和 CWND 以获取有关实际运行时窗口大小的信息。此外，使用 -i 0.1 获取采样值，因为它们是动态的。如果在不设置-w 时这些值较大，则您知道答案，即您的-w 太小。
在 iperf 2.0.9 中，客户端上的 -e 将提供 RTT 和 CWND（仅限 Linux）。获得这些的其他方法是使用 tcpdump 和 tcptrace。