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

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

以下示例来自 Tanenbaum 的计算机网络（第 5 版，第 232 页），让我感到困惑：

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

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

解决方法

据我所知，发送方帧完全发送或“飞行中”的时间为 20 毫秒，该值是通过计算发送 1000 位帧的带宽延迟乘积得出的带宽等于 50kbps 的信道。

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

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

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