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