Python 在UDP中的停止和等待协议中设置超时

在UDP上的

stop and wait

协议中，应该如何估计套接字的超时？它可以是往返时间（RTT）的任意整数倍吗？

理想情况下，您希望超时时间等于从发送数据包到收到另一方确认的那一刻所花费的确切时间-这几乎就是RTT

但是几乎不可能提前知道确切的理想超时，所以我们必须猜测。让我们考虑如果我们猜错了会发生什么。< /P> 如果我们使用的超时恰好低于实际的RTT，我们将在ack到达之前超时。这被称为过早超时，这很糟糕——我们正在传输数据包，即使传输成功

如果我们使用的超时恰好高于实际的RTT，那么识别和重新传输丢失的数据包将花费更长的时间。这也很糟糕——我们可以更早地识别丢失的数据包并重新传输它

现在，关于你的问题：

它可以是往返时间的任意整数倍吗 （RTT）

首先，答案是肯定的。可以使用任何正整数，从1到基本无穷大。此外，您甚至不必使用整数，x2.5的乘数有什么问题

---

但重要的是要了解不同乘数会发生什么。如果你选择一个低乘数，比如1，你会遇到很多过早的超时。如果选择一个较大的数字，例如100，则会有许多延迟超时，这将导致传输长时间停止。

当然，设置超时没有什么比学习TCP如何操作更好的了。

在开始时，必须以任意超时开始，并且必须足够高。说3秒钟。考虑到在大多数情况下，另一方的响应速度要快得多，这对于大多数通信来说应该足够了。然后根据测量的往返时间动态更改重传超时。例如，在一个简单的算法中，您可以将超时设置为2*RTT，如果有超时，则可以按指数增加重传超时，直到收到响应为止。当您收到响应时，您将重新计算新2*RTT的超时

通过动态计算，您的协议将能够适应不同类型的网络和不同的地理位置和情况

---

您可以使它更复杂，并且可以用TCP的方式来完成。

计时器应设置为比平均往返时间长的某个值，以便超时指示可能的丢失。将计时器设置为太短的值将导致多余的重复数据包。虽然协议可以处理这些问题，但我们希望避免过多不必要的重传。这只会增加交通量，从而造成拥堵。