什么是好的 UDP 超时和重试值？答案

【问题标题】：What are good UDP timeout and retry values?什么是好的 UDP 超时和重试值？
【发布时间】：2011-08-22 17:00:20
【问题描述】：

我正在处理 UDP 服务器/客户端配置。客户端向服务器发送单个数据包，该数据包大小不一，但通常小于 500 字节。服务器基本上立即使用单个传出数据包进行响应，通常小于传入请求数据包。完整的事务总是由单个数据包交换组成。

如果客户端在 T 时间内没有看到响应，它会重试 R 次，在每次重试之前将 T 增加 X，最后放弃并返回错误。目前，R 从未改变。

选择最佳初始 T（等待时间）、R（重试）和 X（等待增加）是否有任何特殊逻辑？重试的持久性应该是多少（即，使用什么最小 R）才能达到某种“可靠”协议的近似值？

【问题讨论】：

这是用于 LAN 应用程序还是在 Internet 上工作的东西，使用各种未知速度的连接？
@DaveRandom：后者：通过互联网（但美国任何地方的所有客户端），连接类型/速度不可预测。
如果你想要可靠的东西，为什么不使用 TCP。它是为此而构建的；）
没有要求可靠性。但是，TCP 只能通过重试来尝试“保证”可交付性。问题基本上是您应该尝试多少次重试？如果你比 TCP 更早放弃，你就不会那么可靠。但是，如果您重试的次数与 TCP 重试次数一样多，那么您不会做得更糟，对吧？
只是为了添加另一个数据点，我们使用了4000 的-reorder_queue_size 和10000000 的-max_delay。并不完美，我们仍然遇到丢失的数据包并达到最大延迟。我希望有一种更直观的方式来设置这些。就像您可以在“延迟”或“质量”之间选择优先级的配置一样。这将大有帮助。

标签： algorithm timeout udp protocols

【解决方案1】：

这类似于问题5227520。谷歌搜索“tcp retries”和“tcp retransmission”会导致多年来尝试过的许多建议。不幸的是，没有单一的解决方案看起来是最优的。

我会选择 T 从 2 或 3 秒开始。我的增加 X 将是 T 的一半（加倍 T 似乎很受欢迎，但你很快就会得到很长的超时）。如有必要，我会即时将 R 调整为至少 5 或更多，因此我的总超时时间至少为一两分钟。

如果后续交易通常更快，我会注意不要让 R 和 T 太高；您可能希望在统计数据允许的情况下降低 R 和 T，这样您就可以重试并获得快速响应，而不是将 R 和 T 保持在最大值（尤其是如果您的客户是人类并且您希望做出响应）。

请记住：如果重试成功，您永远不会像重试次数超过您的算法那样可靠。另一方面，如果您的服务器始终可用并且始终“基本上立即响应”，那么如果客户端未能看到响应，则表明您的服务器无法控制故障，唯一可以做的就是让客户端重试（虽然重试可以不仅仅是重新发送，例如关闭/重新打开连接，尝试不同 IP 的备份服务器等）。

【讨论】：

哎哟...分钟？如果我发送视频数据，希望我不必等待几分钟就可以重新发送数据包！

【解决方案2】：

最小超时应该是路径延迟，或往返时间 (RTT) 的一半。

见RFC 908 — Reliable Data Protocol。

最大的问题是决定一次超时后会发生什么，你是重置为相同的超时还是加倍？这是一个复杂的决定，取决于沟通频率的大小以及您希望与他人玩耍的公平程度。

如果您发现数据包经常丢失并且延迟是一个问题，那么您需要考虑保持相同的超时或缓慢上升到指数超时，例如1x、1x、1x、1x、2x、4x、8x、16x、32x。

如果带宽不是什么大问题，但延迟确实很重要，那么请遵循UDP-based Data Transfer Protocol (UDT) 并以低超时和冗余传输强制数据通过。这对于 WAN 环境非常有用，尤其是洲际距离以及为什么 UDT 经常出现在 WAN 加速器中。

延迟更可能不是问题，优先考虑其他协议的公平性，然后使用标准退避模式，1x、2x、4x、8x、16x、32x。

理想情况下，协议处理的实现应该提前自动推导出最佳超时和重试周期。当没有数据丢失时，您不需要冗余交付，当有数据丢失时，您需要增加交付。对于超时，您可能希望考虑在最佳条件下减少超时，然后在发生拥塞时放慢速度以防止同义广播风暴。

【讨论】：