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

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

• 方法1：这是典型的方法（例如以太网协议）。使用固定超时T执行请求。如果发生超时，请休眠X并重试该请求。以指数方式增加X

• 方法2：不要在重试之间休眠，而是增加实际的HTTP超时值（比如说，指数级）。在这两种情况下，考虑最大界限。

对于以太网来说，这是有意义的，因为它在网络堆栈中处于低级位置。然而，对于应用程序级重试机制，方法2是否更合适？在网络拥塞严重的情况下，我认为#2更好，原因有两个：

• 发送额外的TCP连接请求只会使网络更加泛滥
• 您基本上可以保证在睡觉时不会收到响应（因为您已经超时和/或断开了套接字），而如果您只是允许TCP请求保持未完成状态（或者如果连接至少已经建立，则保持套接字打开），您至少有成功的可能

---

对此有何想法？

在高丢包网络（例如，蜂窝网络或接近其范围极限的wi-fi）上，如果超时时间太短，您的请求很可能会持续超时。因此，增加超时通常是一个好主意

立即重试请求通常有效，如果无效，等待一段时间可能不会有什么不同（例如，如果您不再有网络连接）。例如，在iOS上，您的最佳选择是使用可达性，如果可达性确定网络已关闭，则在未关闭之前没有理由重试

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

• 如果generate_204正常工作，则问题可能是服务器问题。立即重试，但将服务器标记为可疑。如果重试第二次失败（在成功生成_204响应之后），则开始指数退避，等待服务器（最大间隔上有一个上限）

• 如果generate_204请求没有响应，则表示您的网络已死机。等待网络更改，仅偶尔尝试（例如，至少每隔几分钟）

• 如果网络连接发生变化（即，如果您突然使用Wi-Fi），请在几秒钟后重新启动所有等待的连接。没有理由在那一刻全天等待，因为一切都变了

---

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

当你可以做有用的工作时，睡觉没有多大意义，或者使用比你真正能忍受的更短的超时时间也没有多大意义。我会使用（2）

---

以太网或任何东西使用（1）的想法似乎很离奇。你有引用吗？

是套接字或连接的http超时吗？好问题。我认为这两种情况都有可能发生。我将更新描述中的最后一个项目。高网络拥塞是否真的意味着消息传递需要更长的时间，还是意味着一些消息被丢弃？它可能取决于网络和应用程序。以太网使用ExB和应用程序使用ExB的区别在于，应用程序正试图实际建立一个持久通信通道（假设TCP）。。。通读这篇文章有助于反思我的问题情景。我们确实有一个潜在的高数据包丢失网络，尽管它会由于流量负载而发生，而不一定是由于介质的质量。基本上，场景需要分为两部分：A）连接建立和B）连续数据传输。在短连接超时的情况下连续重试对于（a）是理想的，而指数退避（即休眠）对于（B）可能更合适。