配置 HA Proxy 时，如何决定为超时分配什么值？我在各种博客中读过六个示例，每个人都使用不同的超时，但没有人讨论原因。
HAProxy 似乎特别担心客户端、连接和服务器，如果你完全没有设置，HAPRoxy 会发出警告：
While not properly invalid, you will certainly encounter various problems
with such a configuration. To fix this, please ensure that all following
timeouts are set to a non-zero value: 'client', 'connect', 'server'.
这文档在这方面没有帮助：它建议“略高于 3 秒的倍数”，但没有说明为什么选择 1 的倍数而不是 100 或 42 的倍数。
我正在使用的 RPM（Amazon Linux 存储库）设置了以下默认值：
timeout connect 10s
timeout client 1m
timeout server 1m
其中两个是精确的3 秒的倍数，违反了我所见过的唯一官方建议。
如果您没有具体的调整建议，也许一个更简单的问题是：如果超时时间非常短或非常长，我应该预料到会出现什么问题？
答案1
TCP RTO（接收超时）从三秒开始。（RFC 1122）如果传输的数据包在这段时间内没有收到确认，则认为该数据包已丢失并重新传输。这几乎肯定是作者所指的。（请注意，RTO 会通过以下方式动态调高或调低：各种算法，超出了本问题的范围。）
请记住，这实际上仅适用于前端服务器和客户端（即 Web 用户）之间的连接。在正常情况下，HAProxy 和后端服务器之间的连接应在 LAN 上，并且应使用更短的超时时间，以便故障的后端服务器能更快地停止服务。
对于您的网络用户，其中一些用户可能使用延迟非常高的连接（例如卫星），因此可能会遇到比正常情况下更高的重传次数。即使一切正常，使用卫星的连接上的 RTT 也可能超过 2000 毫秒。
考虑到所有这些，您通常会希望的超时时间非常短，timeout connect而的超时时间非常长timeout client。
对于timeout server，这取决于您的 Web 应用程序。设置超时时，请考虑所提供服务的 Web 应用程序的复杂性，以及在最坏情况下处理复杂请求可能需要多长时间。如果有疑问，请提高该值。
答案2
前言
我已经对 HAProxy 进行了一段时间的调优，并对其进行了大量的性能测试。从每秒 100 个 HTTP 请求到每秒 50 000 个 HTTP 请求。
第一个建议是在 HAProxy 上启用统计页面。您需要监控，无一例外。如果您打算超过 10,000 个请求/秒，您还需要进行微调。
超时是一个令人困惑的怪物，因为它们具有大量可能的值，其中大多数没有可观察到的差异。我还没有看到因为数字低 5% 或高 5% 而导致失败的情况。10000 毫秒 vs 11000 毫秒，谁在乎呢？可能不是你的系统。
配置
我无法凭良心给出几个数字作为“每个人有史以来最好的暂停时间”。
我可以说的是，最激进的超时对于 HTTP(S) 负载平衡来说始终是可以接受的。如果您遇到的超时低于这些，则是时候重新配置您的负载平衡器了。
timeout connect 5000
timeout check 5000
timeout client 30000
timeout server 30000
超时客户端：
当客户端需要确认或发送数据时，将应用不活动超时。在 HTTP 模式下，在第一阶段（客户端发送请求时）以及响应期间（客户端读取服务器发送的数据时）考虑此超时尤为重要。
读：这是接收 HTTP 请求的最大时间标题来自客户端。
3G/4G/56k/卫星有时会很慢。不过，它们应该能够在几秒钟内发送 HTTP 标头，而不是 30 秒。
如果某人的连接非常差，以至于请求一个页面需要超过 30 秒（然后请求 10 个嵌入的图像/CSS/JS 需要超过 10*30 秒），我认为拒绝他是可以接受的。
超时服务器：
当服务器需要确认或发送数据时，不活动超时适用。在 HTTP 模式下，在服务器响应的第一阶段（当它必须发送标头时）考虑此超时尤其重要，因为它直接表示服务器处理请求的时间。要找出要在此处放置什么值，通常最好先从被视为不可接受的响应时间开始，然后检查日志以观察响应时间分布，并相应地调整该值。
读：这是接收 HTTP 响应的最大时间标题来自服务器（在收到完整的客户端请求之后）。基本上，这是服务器在开始发送响应之前的处理时间。
如果你的服务器太慢，需要 30 秒以上才能开始给出答案，那么我认为可以接受它已经死了。
特例：某些 RARE 服务执行非常繁重的处理，可能需要整整一分钟或更长时间才能给出答案。对于此特定用途，可能需要大幅增加此超时时间。（注意：这可能是设计不良的情况，请使用异步通信或根本不使用 HTTP。）
超时连接：
设置等待服务器连接尝试成功的最大时间。
读：服务器接受 TCP 连接的最长时间。
服务器与 HAProxy 位于同一 LAN 中，因此速度应该很快。请至少等待 5 秒钟，因为当发生任何意外情况时（丢失 TCP 数据包需要重新传输、服务器分叉新进程以接收新请求、流量激增），可能需要这么长时间。
特例：当服务器位于不同的 LAN 或不可靠的链路上时。此超时可能需要大幅增加。（注意：这可能是架构不良的情况。）
超时检查：
设置额外的检查超时，但仅在连接已经建立后。
设置额外的检查超时，但仅在连接已经设置后，haproxy 使用 min("timeout connect", "inter") 作为检查的连接超时，使用 "timeout check" 作为额外的读取超时。使用 "min" 是为了让运行非常较长的“超时连接”（例如，由于队列或 tarpit 而需要此功能的用户）不会减慢其检查速度。（另请注意，没有理由设置如此长的连接超时，因为始终可以使用“超时队列”和“超时 tarpit”来避免这种情况）。
读：执行健康检查时，服务器必须timeout connect接受连接然后timeout check给出响应。
所有服务器都必须配置 HTTP(S) 健康检查。这是负载均衡器了解服务器是否可用的唯一方法。健康检查是一个简单的/isalive页面，始终回答OK。
给这个超时时间至少 5 秒，因为当任何意外情况发生时（丢失的 TCP 数据包需要重新传输、服务器分叉新进程来接收新请求、流量激增），可能需要这么长时间。
战争故事： 很多人错相信服务器总能在 3 毫秒内回答这个简单的页面。他们设置了一个激进的超时（< 2000 毫秒）和激进的故障转移（2 次检查失败 = 服务器死机）。我见过整个网站因此瘫痪。通常情况下，流量会略有增加，后端服务器会变慢，健康检查会延迟……直到它们突然一起超时，HAProxy 认为所有服务器同时死机，整个网站瘫痪。