我想知道在两种服务之间处理HTTP超时的两种方法之间的权衡。服务A在调用服务B时尝试实施 重试 功能。
方法1：这是典型的方法（例如以太网协议）。执行具有固定超时T的请求。如果发生超时，则为X休眠并重试该请求。按指数增加X.
方法2：不是在重试之间休眠，而是增加实际的HTTP超时值（比如指数）。在这两种情况下，请考虑最大限制。
对于以太网，这是有道理的，因为它是网络堆栈中的低级别位置。但是，对于应用程序级别的重试机制，接近2会更合适吗？在网络拥塞程度很高的情况下，我认为＃2更好有几个原因：
对此有何想法？
答案 0 :(得分：1)
在高数据包丢失网络（例如，蜂窝网或接近其范围限制的Wi-Fi）上，如果超时太短，您的请求将永远超时的可能性。因此，增加超时通常是一个好主意。
立即重试请求通常会有效，如果没有，等待一段时间可能没有任何区别（例如，如果您不再有网络连接）。例如，在iOS上，您最好的选择是使用可访问性，如果可达性确定网络已关闭，则没有理由重试，直到它没有。
我的一般想法是，对于短请求（即不上传/下载大文件），如果您在3-5秒后没有收到服务器的任何响应，请并行启动第二个请求。无论哪个请求返回头，首先获胜。取消另一个。将超时保持在90秒。如果失败，请查看您是否可以访问generate_204。
如果generate_204有效，问题可能是服务器问题。立即重试，但将服务器标记为可疑。如果第二次重试失败（在generate_204响应成功之后），则开始等待服务器的指数退避（在最大间隔上设置上限）。
如果generate_204请求没有响应，那么您的网络已经死亡。等待网络更改，只是偶尔尝试（例如每隔几分钟）。
如果网络连接发生变化（例如，如果您突然有Wi-Fi），请在几秒钟后重新启动所有等待的连接。因为一切都已经改变，所以没有理由等到那个时候全职。
但显然没有正确答案。这种方法相当激进。其他人可能采取相反的方法。这一切都取决于你的目标。
答案 1 :(得分：0)
当你做一些有用的工作，或者使用比你真正可以忍受的更短的超时时，睡眠没什么意义。我会用（2）。
以太网或其他任何用途（1）的想法似乎都很奇特。你有引文吗？