3.4.2. Advanced features : System-specific capabilities

  1. Depending on the operating system HAProxy is deployed on, certain extra features
  2. may be available or needed. While it is supported on a number of platforms,
  3. HAProxy is primarily developed on Linux, which explains why some features are
  4. only available on this platform.
  5.  
  6. The transparent bind and connect features, the support for binding connections
  7. to a specific network interface, as well as the ability to bind multiple
  8. processes to the same IP address and ports are only available on Linux and BSD
  9. systems, though only Linux performs a kernel-side load balancing of the incoming
  10. requests between the available processes.
  11.  
  12. On Linux, there are also a number of extra features and optimizations including
  13. support for network namespaces (also known as "containers") allowing HAProxy to
  14. be a gateway between all containers, the ability to set the MSS, Netfilter marks
  15. and IP TOS field on the client side connection, support for TCP FastOpen on the
  16. listening side, TCP user timeouts to let the kernel quickly kill connections
  17. when it detects the client has disappeared before the configured timeouts, TCP
  18. splicing to let the kernel forward data between the two sides of a connections
  19. thus avoiding multiple memory copies, the ability to enable the "defer-accept"
  20. bind option to only get notified of an incoming connection once data become
  21. available in the kernel buffers, and the ability to send the request with the
  22. ACK confirming a connect (sometimes called "piggy-back") which is enabled with
  23. the "tcp-smart-connect" option. On Linux, HAProxy also takes great care of
  24. manipulating the TCP delayed ACKs to save as many packets as possible on the
  25. network.
  26.  
  27. Some systems have an unreliable clock which jumps back and forth in the past
  28. and in the future. This used to happen with some NUMA systems where multiple
  29. processors didn't see the exact same time of day, and recently it became more
  30. common in virtualized environments where the virtual clock has no relation with
  31. the real clock, resulting in huge time jumps (sometimes up to 30 seconds have
  32. been observed). This causes a lot of trouble with respect to timeout enforcement
  33. in general. Due to this flaw of these systems, HAProxy maintains its own
  34. monotonic clock which is based on the system's clock but where drift is measured
  35. and compensated for. This ensures that even with a very bad system clock, timers
  36. remain reasonably accurate and timeouts continue to work. Note that this problem
  37. affects all the software running on such systems and is not specific to HAProxy.
  38. The common effects are spurious timeouts or application freezes. Thus if this
  39. behavior is detected on a system, it must be fixed, regardless of the fact that
  40. HAProxy protects itself against it.