在重试期间调整HTTP超时与退避

Question

我想知道处理两个服务之间HTTP超时的两种方法之间的权衡。服务A在调用服务B时试图实现重试功能。

• 方法1:这是典型的方法(例如以太网proto)。使用固定超时T执行请求。如果发生超时，请为X睡觉，然后重试请求。按指数增加X。
• 方法2:而不是在重试之间休眠，而是增加实际的HTTP超时值(例如，指数级)。在这两种情况下，考虑最大限度的限制。

对于以太网来说，这是有意义的，因为它在网络堆栈中的位置很低.然而，对于应用程序级别的重试机制，方法2更合适吗？在网络拥堵程度很高的情况下，我认为第二种情况更好，原因有几点：

• 发送额外的TCP连接请求只会使网络淹没更多。
• 您基本上保证在休眠时不会收到响应(因为您已经超时和/或撕毁了套接字)，而如果您只是允许TCP请求保持未执行状态(或者在至少建立了连接时保持套接字打开)，则至少有成功的可能性。

对此有什么想法吗？

Answer 1

在高丢包网络(例如蜂窝网络或will的范围内)上，如果超时时间太短，您的请求很可能会永远超时。因此，增加超时时间通常是个好主意。

并且立即重新尝试请求通常是有效的，如果没有，等待一段时间可能没有什么区别(例如，如果您不再有网络连接)。例如，在iOS上，最好的选择是使用“可达性”，如果“可达性”确定网络已关闭，则没有理由重新尝试，直到没有。

我的一般想法是，对于简短的请求(即不上传/下载大型文件)，如果您在3到5秒后根本没有收到来自服务器的任何响应，则并行启动第二个请求。无论哪个请求首先返回标题，都会获胜。取消另一个。将超时时间保持在90秒。如果失败，请查看是否可以到达generate_204。

• 如果generate_204有效，问题可能是服务器问题。立即重试，但将服务器标记为可疑。如果该重试再次失败(在成功的generate_204响应之后)，则启动指数退避，等待服务器(在最大间隔上设置上限)。
• 如果generate_204请求没有响应，您的网络就死了。等待网络改变，只是偶尔尝试(例如每隔几分钟至少一次)。
• 如果网络连接发生变化(例如，如果您突然拥有Wi)，几秒钟后重新启动任何等待连接。没有理由在那一刻等待全职，因为一切都变了。

但显然没有正确的答案。这种做法相当激进。其他人则可能采取相反的做法。这都取决于你的目标是什么。

Answer 2

当你在做有用的工作时，睡觉没有多大意义，也没有必要使用比你真正能忍受的更短的超时时间。我会用(2)。

认为以太网或任何东西都使用(1)的想法似乎是不切实际的。你有引文吗？