1.1. The HTTP transaction model

  1. The HTTP protocol is transaction-driven. This means that each request will lead
  2. to one and only one response. Traditionally, a TCP connection is established
  3. from the client to the server, a request is sent by the client through the
  4. connection, the server responds, and the connection is closed. A new request
  5. will involve a new connection :
  6.  
  7.   [CON1] [REQ1] ... [RESP1] [CLO1] [CON2] [REQ2] ... [RESP2] [CLO2] ...
  8.  
  9. In this mode, called the "HTTP close" mode, there are as many connection
  10. establishments as there are HTTP transactions. Since the connection is closed
  11. by the server after the response, the client does not need to know the content
  12. length.
  13.  
  14. Due to the transactional nature of the protocol, it was possible to improve it
  15. to avoid closing a connection between two subsequent transactions. In this mode
  16. however, it is mandatory that the server indicates the content length for each
  17. response so that the client does not wait indefinitely. For this, a special
  18. header is used: "Content-length". This mode is called the "keep-alive" mode :
  19.  
  20.   [CON] [REQ1] ... [RESP1] [REQ2] ... [RESP2] [CLO] ...
  21.  
  22. Its advantages are a reduced latency between transactions, and less processing
  23. power required on the server side. It is generally better than the close mode,
  24. but not always because the clients often limit their concurrent connections to
  25. a smaller value.
  26.  
  27. Another improvement in the communications is the pipelining mode. It still uses
  28. keep-alive, but the client does not wait for the first response to send the
  29. second request. This is useful for fetching large number of images composing a
  30. page :
  31.  
  32.   [CON] [REQ1] [REQ2] ... [RESP1] [RESP2] [CLO] ...
  33.  
  34. This can obviously have a tremendous benefit on performance because the network
  35. latency is eliminated between subsequent requests. Many HTTP agents do not
  36. correctly support pipelining since there is no way to associate a response with
  37. the corresponding request in HTTP. For this reason, it is mandatory for the
  38. server to reply in the exact same order as the requests were received.
  39.  
  40. The next improvement is the multiplexed mode, as implemented in HTTP/2. This
  41. time, each transaction is assigned a single stream identifier, and all streams
  42. are multiplexed over an existing connection. Many requests can be sent in
  43. parallel by the client, and responses can arrive in any order since they also
  44. carry the stream identifier.
  45.  
  46. By default HAProxy operates in keep-alive mode with regards to persistent
  47. connections: for each connection it processes each request and response, and
  48. leaves the connection idle on both sides between the end of a response and the
  49. start of a new request. When it receives HTTP/2 connections from a client, it
  50. processes all the requests in parallel and leaves the connection idling,
  51. waiting for new requests, just as if it was a keep-alive HTTP connection.
  52.  
  53. HAProxy supports 4 connection modes :
  54.   - keep alive    : all requests and responses are processed (default)
  55.   - tunnel        : only the first request and response are processed,
  56.                     everything else is forwarded with no analysis (deprecated).
  57.   - server close  : the server-facing connection is closed after the response.
  58.   - close         : the connection is actively closed after end of response.
  59.  
  60. For HTTP/2, the connection mode resembles more the "server close" mode : given
  61. the independence of all streams, there is currently no place to hook the idle
  62. server connection after a response, so it is closed after the response. HTTP/2
  63. is only supported for incoming connections, not on connections going to
  64. servers.