我正在开发网络客户端和 API 服务器。我一直在做一些关于默认超时的研究，有些是 800 毫秒，有些是 1200 毫秒。但是，我找不到任意数字背后的原因。有人可以帮我解决这个问题吗？任意数字背后的解释会很有帮助。
谢谢，
【问题讨论】：
TLDR：请参阅下面以“任意数字”开头的粗体段落。其余的只是有关该主题的额外信息。
虽然您可能知道或已经在您的研究中阅读过此内容，但我可以分享以下想法：
通常根据查询的预期复杂性、要处理的数据量以及查询发生时系统的预期负载（或在修改方面可能需要注意的任何其他预期操作）设置超时超时）。此外，这可以基于某个 API 向其他 API 发出的请求以处理传入请求的数量以及这些预期可能是什么。
任意数字（开发该软件的人的“最佳猜测”）通常会在计划“如果不存在任何问题的情况下，大多数请求应该在这段时间内完成，无论发生了什么”或“这没什么好担心的”类型的场景。因此，超时的默认值几乎是基于这样的假设，即它们代表了绝大多数“可接受的”已完成请求，其中不存在任何问题。它通常设置在“这应该有足够的时间”和“这个请求很可能有严重问题，让我们结束它”之间的某个位置，并且大多数成功的请求都“默认”通过了这个测试。
如果您的操作可能需要几分钟，并且您希望这可能发生而没有实际问题存在，您可能希望将超时设置为高于默认值，以便您的请求在出现没有实际问题（例如，大多数商业 API 对请求数量和它们必须完成的时间有限制，因此有问题的请求不会阻塞系统以及开发人员认为的其他原因）。
因此，除了查看要处理的数据/请求的数量、规划合理的服务器负载起伏、优化您的代码与预期负载相比，等等......这几乎就像错误处理，但对于您不知道可能发生的事情（例如意外错误）但基于您已经了解的关于您的系统及其预期的事情用法。
一般来说，你不会遇到很多情况下超时真的很重要，但你总是希望有一个（至少是默认值）来为意外做好准备。
如果您还没有看过，我发现以下文章讨论了该主题以及我提到的一些内容：
https://medium.com/@masnun/always-use-a-timeout-for-http-requests-de4da538b9e3
【讨论】：
tl;dr - 主要根据 SLA [服务水平协议]。如果没有，请尝试尽可能优化代码以减少以毫秒为单位发出响应所需的时间
我会用外行的话来回答，因为它确实取决于各种因素。
假设您有一个 API，它执行一些操作并返回结果。这很简单，如果他们不执行任何复杂的操作，您将在几毫秒内得到响应。
当我们进入一个越来越复杂的系统时，一个 API 与另一个 API 通信，它会增加时间，最坏的情况是，第一个启动请求的 API 可能会在 5 秒后得到最终响应，30秒，甚至 60 秒，具体取决于 API 调用的数量和系统设计的好坏。
我们只考虑快乐的流程。如果其中一个在内部调用的 API 出现问题怎么办？
为了避免这种糟糕的体验，客户将制定一个 SLA，要求公司/开发人员以这样的方式设计代码，以便在某个可接受的范围内给出响应。
我曾经在Google Groups conversation 上看到过这个对话，它可能会提供一些见解。
所以要回答关于可接受范围的问题，如果您没有 SLA，请尝试尽可能优化代码，以减少以毫秒为单位发出响应所需的时间.
【讨论】：
通常认为 1 秒是可以接受的。造成这种情况以及建议的数字变化如此之大的原因是，如果您快速发送请求，大多数 API 都会被锁定。但是，某些 API 可以让您更快地发送请求。根据我的经验，我看到的所有 API 都要求请求之间有 1 秒（1000 毫秒）的延迟，以防止过载/意外 DDOS，并且超时时间为 30-60 秒。
编辑：重要的是要提到，如果第一个请求仍在等待，则不要让来自同一 IP 的另一个请求得到响应，因为这会使 DDoS 变得容易
【讨论】：