过度延迟会影响吞吐量吗？

Question

我不知道这个问题是否是这里的主题，所以如果不是，请重定向我。

为了了解 TCP 的工作原理，我使用 ns-3 模拟器模拟了单点对点链接。在将链路带宽设置为 5 Mbps、合适的错误率和 5 毫秒的延迟后，我得到了大约 4.9 Mbps 的原始吞吐量。但是，将链接增加到 50 Mbps 后，我只能获得 16 Mbps。此外，将延迟减少到 1 毫秒可使吞吐量达到约 40 Mbps。

有人可以解释一下这个巨大的差异吗？

编辑：我了解带宽和延迟有何不同。我只想知道我的模拟器是否有问题，或者这是 TCP 的预期。

Answer 1

简而言之：是的，太多的延迟会降低您的总带宽，并且对串行类型连接的影响更为明显 - 即：在收到先前传输的 ACK 之前无法传输更多数据的连接。

只有当两个值相距很远时，延迟/带宽相关性才会成为问题，例如具有非常“宽”但延迟高的链接（或反之亦然 - 延迟非常低但非常“窄”的链接）。

让我举一个例子，使用一些简单的东西，比如在 WAN 连接上执行 32 字节的 ping，延迟大约为 50 毫秒（100 毫秒 RTT）。通过这样的连接，您最多可以发送 10 个 32b ping，每个方向总共只有 320b/s！ping floods明确不等待对方确认并不奇怪，否则洪水将不存在。

如果不能降低延迟，如何解决这个问题？主要使用两种方式：

• 发送更大的数据包（例如：使用 1400 字节大小的 ping）；
• 在等待确认之前发送更多数据包。

TCP 使用两种系统：在建立流连接后（例如：开始下载），它既将数据包大小增加到最大值（MSS - 最大段大小）和发送的数据包数量，而无需等待任何确认/ ack-aka TCP 窗口缩放。很多工作都花在创建能够动态调整 TCP 窗口缩放的网络堆栈上，因此现在很少需要手动调整。然而，有时糟糕的网络驱动程序和/或奇怪的极端情况会阻止正确的缩放，从而导致带宽减少。

本身不实现窗口缩放的协议（即：IP 和 UDP）对带宽问题更敏感，并且通常需要更高级别应用程序（如果可能）或特定系统调整（例如，增加最大数据包大小，称为 MTU）。

显然，WAN 连接由于其固有的更高延迟，更容易出现问题。但是，即使是非常快的本地连接也会受到影响。

相关案例：

• 在 10 Gb/s 以太网网络上，ping RTT 在 0.05 毫秒的范围内，我最初仅实现了总可用带宽的 30-40%。将接口 MTU 增加到 9000 字节（从标准的 1500 字节上调）完全解决了问题；
• 在千兆以太网连接上，Athereos 接口驱动程序以一种阻止 TCP 窗口“打开”到其最大值的方式与 Linux 网络堆栈交互，从而降低了性能。手动设置 TCP 窗口解决了这个问题。