计算通过网络发送数据帧的往返传播延迟

Question

以下示例来自 Tanenbaum 的 Computer Networks（第 5 版，第 232 页），它让我感到困惑：

到目前为止，我们一直默认帧到达接收器所需的传输时间加上确认返回的传输时间可以忽略不计。有时这个假设很明显 错误的。在这些情况下，较长的往返时间可能会产生重要影响 以提高带宽利用效率。例如，考虑一个 50-kbps 具有 500 毫秒往返传播延迟的卫星信道。让我们想象 试图使用协议 4 通过卫星发送 1000 位帧。在 t = 0 时 sender 开始发送第一帧。在 t = 20 毫秒时，帧已被完全发送。直到 t = 270 毫秒，帧才完全到达接收器， 直到 t = 520 毫秒，确认才返回发送方， 在最好的情况下（在接收器中没有等待和一个短的确认帧）。这意味着发件人被阻止 500/520 或 96% 的时间。换言之，仅使用了 4% 的可用带宽。显然，长传输时间、高带宽和短帧长度的组合 在效率方面是灾难性的。

据我了解，发送者的帧被完全发送或“在飞行中”的时间是 20 毫秒，这个值是通过计算发送 1000 位帧的带宽延迟积得出的带宽等于 50kbps 的信道。到目前为止，一切都很好。然后，帧完全到达接收器的时间是 270 毫秒，这个值是简单地通过将单向传播延迟（250 毫秒）与我们的 20 毫秒带宽延迟积相加来计算的。那么，接收方的确认帧如何在时间 t = 520 毫秒时返回发送方？这似乎意味着总共只需要 250 毫秒就可以完全发送 ACK 帧，然后让它到达发送方，完全忽略带宽延迟时间来获得 1000 位帧“飞行中”。我能想到忽略发送 ACK 帧的带宽延迟时间的唯一原因是接收器没有发送整个帧，而只是发送序列号的一个比特。即使这样，单个位的 BD 乘积仍然是一个非零值，准确地说是 20 微秒。因此，在这种情况下，ACK 帧应该在时间 t = 520.02 毫秒到达发送方。这只是一个错字吗？如果不是，有人可以解释计算时间差异的原因吗？

Answer 1

据我了解，发送者的帧被完全发送或“在飞行中”的时间是 20 毫秒，这个值是通过计算发送 1000 位帧的带宽延迟积得出的带宽等于 50kbps 的通道。

不完全是。您混淆了传输（“发送”）时间和传播（“飞行中”）时间。 发射器需要 20 毫秒才能将整个数据包发送（“放置”）到空中。这意味着数据包的最后一位在 t=20ms 时发送。然而，这只是那段旅程的开始。它现在必须传播（“飞行”）到 250 毫秒外的卫星。这就是为什么卫星只在 t=270ms 时才收到整个数据包的原因。

换句话说，如果我们只看数据包的最后一位，它需要 20 毫秒才能到达发射器旁边的空中，而另外 250 毫秒才能到达卫星本身。

一旦卫星在 t=270ms 收到数据包的最后一位，它立即发送一个 ack，它很小，所以它的传输时间可以忽略不计。 ack 又需要 250 毫秒（直到 t=520 毫秒）才能到达地面站。