我正在进行UDP服务器/客户端配置。客户端向服务器发送单个数据包，其大小不同但通常<500字节。服务器基本上立即响应单个传出数据包，通常小于传入请求数据包。完整交易总是由单个数据包交换组成。
如果客户端在T时间内没有看到响应，则重试R次，在每次重试之前将T增加X，最后放弃并返回错误。目前，R永远不会改变。
选择最佳初始T（等待时间），R（重试）和X（等待增加）是否有任何特殊逻辑？应该重试多久（即，使用什么最小R）来达到某种“可靠”协议的近似值？
答案 0 :(得分：6)
这类似于问题5227520。谷歌搜索“tcp重试”和“tcp重新传输”导致了许多多年来一直在尝试的建议。不幸的是，没有单一的解决方案是最佳的。
我选择 T 以2或3秒开始。我的增加 X 将是T的一半（加倍T看起来很受欢迎，但你很快会超时）。如果需要的话，我会动态调整 R 至少5个以上，这样我的总超时时间至少为一两分钟。
如果后续交易通常更快，我会小心不要让R和T太高;您可能希望降低R和T，因为您的统计数据允许，因此您可以重试并获得快速响应，而不是将R和T保留在最大值（特别是如果您的客户是人类并且您希望做出响应）。
请记住：如果重试成功，那么您将永远不会像重试比您重试的算法一样可靠。另一方面，如果您的服务器始终可用并且始终“立即响应”，那么如果客户端未能看到响应，则表示服务器无法控制，并且唯一可以做的就是让客户端重试（虽然重试不仅仅是重新发送，例如关闭/重新打开连接，尝试使用不同IP的备份服务器等。）
答案 1 :(得分：2)
最小超时应为路径延迟，或往返时间（RTT）的一半。
http://www.faqs.org/rfcs/rfc908.html
最大的问题是决定一次超时后会发生什么，你重置到相同的超时还是加倍？这是一个复杂的决定，取决于沟通频率的大小以及你希望与他人合作的公平程度。
如果您发现数据包经常丢失并且延迟是一个问题，那么您希望查看保持相同的超时或缓慢上升到指数超时，例如1x，1x，1x，1x，2x，4x，8x，16x，32x。
如果带宽不是很重要但延迟确实存在，那么请遵循UDT并强制数据通过低超时和冗余交付。这对于WAN环境很有用，尤其是洲际距离以及为什么UDT经常在WAN加速器中找到。
更有可能延迟并不是一个值得关注的问题，并且首选其他协议的公平性，然后使用标准的退避模式，1x，2x，4x，8x，16x，32x。
理想情况下，应提前执行协议处理，以自动导出最佳超时和重试周期。当没有数据丢失时，您不需要冗余交付，当数据丢失时，您需要增加交付。对于超时，您可能希望考虑在最佳条件下减少超时，然后在发生拥塞时减慢以防止同义广播风暴。