haproxy的timout参数

ewreew

第一个参数：timeout queue <timeout>
  Set the maximum time to wait in the queue for a connection slot to be free
设置一个连接位置在一个队列中等待被释放的最大时间。
  When a server's maxconn is reached, connections are left pending in a queue
  which may be server-specific or global to the backend. In order not to wait
  indefinitely, a timeout is applied to requests pending in the queue. If the
  timeout is reached, it is considered that the request will almost never be
  served, so it is dropped and a 503 error is returned to the client.
当一个服务器的最大连接到达时，连接会被放在队列中，它可能是具体的服务器或者全局对于后台。为了不无限期的等待，在一个队列中超时会被用到请求挂起。如果达到超时，被认为请求几乎不被服务，因此请求会被丢掉并且返回503到客户端。
  The "timeout queue" statement allows to fix the maximum time for a request to
  be left pending in a queue. If unspecified, the same value as the backend's
  connection timeout ("timeout connect") is used, for backwards compatibility
  with older versions with no "timeout queue" parameter.
"timeout queue"这个语句允许固定请求在队列中挂起的最大时间。如果是没有指定，那么和后台连接超时"timeout connect"的值相同。

第二个参数：

timeout server <timeout>
  Set the maximum inactivity time on the server side.
设置在服务器一侧的最大非活动时间。


  The inactivity timeout applies when the server is expected to acknowledge or
  send data. In HTTP mode, this timeout is particularly important to consider
  during the first phase of the server's response, when it has to send the
  headers, as it directly represents the server's processing time for the
  request. To find out what value to put there, it's often good to start with
  what would be considered as unacceptable response times, then check the logs
  to observe the response time distribution, and adjust the value accordingly.
当服务器希望接收或者发送数据的时候，非活动超时会被应用。
它直接代表服务器的处理请求时间。
为了弄清楚应该放什么值，最好是从不可接受的响应时间着手，并相应的调整该值。

In TCP mode (and to a lesser extent更小来说, in HTTP mode), it is highly

  recommended that the client timeout remains equal to the server timeout in
  order to avoid complex situations to debug. Whatever the expected server
  response times, it is a good practice to cover at least one or several TCP
  packet losses by specifying timeouts that are slightly above multiples of 3
  seconds (eg: 4 or 5 seconds minimum). If some long-lived sessions are mixed
  with short-lived sessions (eg: WebSocket and HTTP), it's worth considering
  "timeout tunnel", which overrides "timeout client" and "timeout server" for
  tunnels.通过制定超时略微高于3秒的倍数（最小是4秒或者5秒）来解决至少一个或者多个tcp包的丢失。
如果是一些长会话混合了一些短会话，最好考虑"timeout tunnel"。

  This parameter is specific to backends, but can be specified once for all in
  "defaults" sections. 可以在“defaults”区域一次性指定。
This is in fact one of the easiest solutions not to
  forget about it. An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may results in accumulation of expired sessions in
  the system if the system's timeouts are not configured either.

  This parameter replaces the old, deprecated "srvtimeout". It is recommended
  to use it to write new configurations. The form "timeout srvtimeout" is
  provided only by backwards compatibility but its use is strongly discouraged.


第三个参数：
timeout client <timeout>
timeout clitimeout <timeout> (deprecated)
  Set the maximum inactivity time on the client side.
设置客户端侧的最大非活动时间。

  The inactivity timeout applies when the client is expected to acknowledge or
  send data. In HTTP mode, this timeout is particularly important to consider
  during the first phase, when the client sends the request, and during the
  response while it is reading data sent by the server. That said, for the
  first phase, it is preferable to set the "timeout http-request" to better
  protect HAProxy from Slowloris like attacks.
It is a good practice to cover one or several TCP packet

  losses by specifying timeouts that are slightly above multiples of 3 seconds
  (eg: 4 or 5 seconds). If some long-lived sessions are mixed with short-lived
  sessions (eg: WebSocket and HTTP), it's worth considering "timeout tunnel",
  which overrides "timeout client" and "timeout server" for tunnels, as well as
  "timeout client-fin" for half-closed connections.

  This parameter is specific to frontends, but can be specified once for all in
  "defaults" sections. This is in fact one of the easiest solutions not to
  forget about it. An unspecified timeout results in an infinite timeout, which
  is not recommended. Such a usage is accepted and works but reports a warning
  during startup because it may results in accumulation of expired sessions in
  the system if the system's timeouts are not configured either.