过多的延迟会影响吞吐量吗？

Question 1

简而言之：是的，过多的延迟会降低你的总带宽，并且在串行类型连接上效果更为明显 - 即：在收到上次传输的 ACK 之前，连接无法传输任何数据。

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

让我举个简单的例子，比如在 WAN 连接上执行 32 字节的 ping，延迟约为 50 毫秒（100 毫秒 RTT）。使用这样的连接，您最多可以发送 10x 32b ping，总计仅限 320b/s在每个方向上！ping 洪水明确不要等待对方确认，否则洪水就不会存在。

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

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

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

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

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

例如：

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

Answer

简而言之：是的，过多的延迟会降低你的总带宽，并且在串行类型连接上效果更为明显 - 即：在收到上次传输的 ACK 之前，连接无法传输任何数据。

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

让我举个简单的例子，比如在 WAN 连接上执行 32 字节的 ping，延迟约为 50 毫秒（100 毫秒 RTT）。使用这样的连接，您最多可以发送 10x 32b ping，总计仅限 320b/s在每个方向上！ping 洪水明确不要等待对方确认，否则洪水就不会存在。

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

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

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

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

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

例如：

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

Question 2

评论太长但不是完整的答案，但延迟会影响吞吐量（带宽是固定属性）：

您的 TCP 网络堆栈需要在内存中保留所有传输数据包的副本，直到收到接收方确认已收到数据包为止，以便在发生数据包丢失的情况下可以重新传输数据包。

该缓冲区的最小大小是一个简单的乘法：

<throughput> * <roundtrip time> = <retransmit buffer size>

例如，为了支持 LAN 中往返时间（=延迟）为 0.2 毫秒的千兆位 NIC 的最大吞吐量，所需的重传缓冲区将是：

  (1Gigabit/s = 10^9 bit/s) * 0.0002 s = 200000 bits = 25 Kb

相当适中的数量。更现实的 WAN 延迟为 2 毫秒，您需要 250 Kb。

除非您的网络驱动程序动态调整分配给 TCP 重传缓冲区大小的内存量，否则该缓冲区实际上会成为系统可维持的吞吐量的限制器，无论网络中的可用带宽如何：

<max throughput>  = <retransmit buffer size> / <roundtrip time>

任何延迟的增加都会降低系统的有效吞吐量。

现在想象一下，如果将相同的 250 Kb 缓冲区设置为高延迟、高带宽连接（例如典型延迟为 500 毫秒的卫星上行链路），而不是低延迟 LAN/WAN，则吞吐量将限制为：

250 Kb / 0,5 s = 2 000 000 / 0,5 = 4 Mbit/s

而不是卫星互联网连接实际上可以支持的 1 Gbit 带宽（根据维基百科）

Answer