什么是好的 UDP 超时和重试值？
我正在研究 UDP 服务器/客户端配置。客户端向服务器发送单个数据包，该数据包的大小各不相同，但通常小于 500 字节。服务器基本上立即响应单个传出数据包，通常小于传入请求数据包。完整的事务始终由单个数据包交换组成。
如果客户端在 T 时间内没有看到响应，它将重试 R 次，在每次重试之前将 T 增加 X，最后放弃并返回错误。目前，R 从未改变。
选择最佳初始 T（等待时间）、R（重试）和 X（等待增加）是否有任何特殊逻辑？为了达到“可靠”协议的某种近似值，重试应该持续多久（即使用最小的 R）？
I'm working on a UDP server/client configuration. The client sends the server a single packet, which varies in size but is usually <500 bytes. The server responds essentially instantly with a single outgoing packet, usually smaller than the incoming request packet. Complete transactions always consist of a single packet exchange.
If the client doesn't see the response within T amount of time, it retries R times, increasing T by X before each retry, before finally giving up and returning an error. Currently, R is never changed.
Is there any special logic to choosing optimum initial T (wait time), R (retries), and X (wait increase)? How persistent should retries be (ie, what minimum R to use) to reach some approximation of a "reliable" protocol?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这类似于问题 5227520。谷歌搜索“tcp 重试”和“tcp 重传”会得到许多多年来已经尝试过的建议。不幸的是，没有一个解决方案看起来是最佳的。
我会选择 T 在 2 或 3 秒处开始。我的增加X将是T的一半（将T加倍似乎很受欢迎，但你很快就会得到长时间的超时）。如果有必要，我会即时将 R 调整为至少 5 或更多，这样我的总超时时间至少为一两分钟。
如果后续交易通常更快，我会小心不要将 R 和 T 设得太高；您可能希望在统计数据允许的情况下降低 R 和 T，这样您就可以重试并获得快速响应，而不是将 R 和 T 保持在最大值（特别是如果您的客户是人类并且您希望做出响应）。
请记住：如果重试成功，您永远不会像重试次数比您多的算法那么可靠。另一方面，如果您的服务器始终可用并且始终“基本上立即响应”，那么如果客户端无法看到响应，则这是服务器无法控制的故障，唯一可以做的就是客户端重试（尽管重试不仅仅是重新发送，例如关闭/重新打开连接、尝试不同 IP 的备份服务器等）。
This is similar to question 5227520. Googling "tcp retries" and "tcp retransmission" leads to lots of suggestions that have been tried over the years. Unfortunately, no single solution appears optimum.
I'd choose T to start at 2 or 3 seconds. My increase X would be half of T (doubling T seems popular, but you quickly get long timeouts). I'd adjust R on the fly to be at least 5 and more if necessary so my total timeout is at least a minute or two.
I'd be careful not to leave R and T too high if subsequent transactions are usually quicker; you might want to lower R and T as your stats allow so you can retry and get a quick response instead of leaving R and T at their max (especially if your clients are human and you want to be responsive).
Keep in mind: you're never going to be as reliable as an algorithm that retries more than you, if those retries succeed. On the other hand, if your server is always available and always "responds essentially instantly" then if the client fails to see a response it's a failure out of your server's control and the only thing that can be done is for the client to retry (although a retry can be more than just resending, such as closing/reopening the connection, trying a backup server at a different IP, etc).
最小超时应为路径延迟或往返时间 (RTT) 的一半。
请参阅 RFC 908 — 可靠数据协议。
最大的问题是决定一次暂停后会发生什么，是重置到相同的暂停还是加倍？这是一个复杂的决定，取决于沟通的频率大小以及您希望与他人公平竞争的程度。
如果您发现数据包经常丢失并且延迟是一个问题，那么您需要考虑保持相同的超时或缓慢增加到指数超时，例如 1x、1x、1x、1x、2x、4x、8x、16x , 32 倍。
如果带宽不是很重要，但延迟确实很重要，那么请遵循 基于 UDP 的数据传输协议 (UDT) 并以低超时和冗余传输强制数据通过。这对于 WAN 环境非常有用，尤其是洲际距离，这也是 UDT 经常出现在 WAN 加速器中的原因。
更有可能的是，延迟并不是那么重要，并且优先考虑对其他协议的公平性，然后使用标准回退模式，1x、2x、4x、8x、16x、32x。
理想情况下，应该提前执行协议处理以自动导出最佳超时和重试周期。当没有数据丢失时，不需要冗余交付，当有数据丢失时，需要增加交付。对于超时，您可能希望考虑在最佳条件下减少超时，然后在发生拥塞时放慢速度，以防止同义广播风暴。
The minimum timeout should be the path latency, or half the Round-Trip-Time (RTT).
See RFC 908 — Reliable Data Protocol.
The big question is deciding what happens after one timeout, do you reset to the same timeout or do you double up? This is a complicated decision based on the size on the frequency of the communication and how fair you wish to play with others.
If you are finding packets are frequently lost and latency is a concern then you want to look at either keeping the same timeout or having a slow ramp up to exponential timeouts, e.g. 1x, 1x, 1x, 1x, 2x, 4x, 8x, 16x, 32x.
If bandwidth isn't much of a concern but latency really is, then follow UDP-based Data Transfer Protocol (UDT) and force the data through with low timeouts and redundant delivery. This is useful for WAN environments, especially intercontinental distances and why UDT is frequently found within WAN accelerators.
More likely latency isn't that much of a concern and fairness to other protocols is preferred, then use a standard back-off pattern, 1x, 2x, 4x, 8x, 16x, 32x.
Ideally the implementation of the protocol handling should be advanced to automatically derive the optimum timeout and retry periods. When there is no data loss you do not need redundant delivery, when there is data loss you need to increase delivery. For timeouts you may wish to consider reducing the timeout in optimum conditions then slowing down when congestion occurs to prevent synonymous broadcast storms.