Basic features : Stick-tables

Stick-tables are commonly used to store stickiness information, that is, to keep
a reference to the server a certain visitor was directed to. The key is then the
identifier associated with the visitor (its source address, the SSL ID of the
connection, an HTTP or RDP cookie, the customer number extracted from the URL or
from the payload, ...) and the stored value is then the server's identifier.

Stick tables may use 3 different types of samples for their keys : integers,
strings and addresses. Only one stick-table may be referenced in a proxy, and it
is designated everywhere with the proxy name. Up to 8 key may be tracked in
parallel. The server identifier is committed during request or response
processing once both the key and the server are known.

Stick-table contents may be replicated in active-active mode with other HAProxy
nodes known as "peers" as well as with the new process during a reload operation
so that all load balancing nodes share the same information and take the same
routing decision if a client's requests are spread over multiple nodes.

Since stick-tables are indexed on what allows to recognize a client, they are
often also used to store extra information such as per-client statistics. The
extra statistics take some extra space and need to be explicitly declared. The
type of statistics that may be stored includes the input and output bandwidth,
the number of concurrent connections, the connection rate and count over a
period, the amount and frequency of errors, some specific tags and counters,
etc... In order to support keeping such information without being forced to
stick to a given server, a special "tracking" feature is implemented and allows
to track up to 3 simultaneous keys from different tables at the same time
regardless of stickiness rules. Each stored statistics may be searched, dumped
and cleared from the CLI and adds to the live troubleshooting capabilities.

While this mechanism can be used to surclass a returning visitor or to adjust
the delivered quality of service depending on good or bad behaviour, it is
mostly used to fight against service abuse and more generally DDoS as it allows
to build complex models to detect certain bad behaviours at a high processing
speed.