This document doesn't provide any configuration help or hints, but it explains
where to find the relevant documents. The summary below is meant to help you
search sections by name and navigate through the document.

Note to documentation contributors :
    This document is formatted with 80 columns per line, with even number of
    spaces for indentation and without tabs. Please follow these rules strictly
    so that it remains easily printable everywhere. If you add sections, please
    update the summary below for easier searching.

The complete HAProxy documentation is contained in the following documents.
Please ensure to consult the relevant documentation to save time and to get the
most accurate response to your needs. Also please refrain from sending questions
to the mailing list whose responses are present in these documents.

  - intro.txt (this document) : it presents the basics of load balancing,
    HAProxy as a product, what it does, what it doesn't do, some known traps to
    avoid, some OS-specific limitations, how to get it, how it evolves, how to
    ensure you're running with all known fixes, how to update it, complements
    and alternatives.

  - management.txt : it explains how to start haproxy, how to manage it at
    runtime, how to manage it on multiple nodes, and how to proceed with
    seamless upgrades.

  - configuration.txt : the reference manual details all configuration keywords
    and their options. It is used when a configuration change is needed.

  - coding-style.txt : this is for developers who want to propose some code to
    the project. It explains the style to adopt for the code. It is not very
    strict and not all the code base completely respects it, but contributions
    which diverge too much from it will be rejected.

  - proxy-protocol.txt : this is the de-facto specification of the PROXY
    protocol which is implemented by HAProxy and a number of third party
    products.

  - README : how to build HAProxy from sources

Load balancing consists in aggregating multiple components in order to achieve
a total processing capacity above each component's individual capacity, without
any intervention from the end user and in a scalable way. This results in more
operations being performed simultaneously by the time it takes a component to
perform only one. A single operation however will still be performed on a single
component at a time and will not get faster than without load balancing. It
always requires at least as many operations as available components and an
efficient load balancing mechanism to make use of all components and to fully
benefit from the load balancing. A good example of this is the number of lanes
on a highway which allows as many cars to pass during the same time frame
without increasing their individual speed.

Examples of load balancing :

  - Process scheduling in multi-processor systems
  - Link load balancing (e.g. EtherChannel, Bonding)
  - IP address load balancing (e.g. ECMP, DNS round-robin)
  - Server load balancing (via load balancers)

The mechanism or component which performs the load balancing operation is
called a load balancer. In web environments these components are called a
"network load balancer", and more commonly a "load balancer" given that this
activity is by far the best known case of load balancing.

A load balancer may act :

  - at the link level : this is called link load balancing, and it consists in
    choosing what network link to send a packet to;

  - at the network level : this is called network load balancing, and it
    consists in choosing what route a series of packets will follow;

  - at the server level : this is called server load balancing and it consists
    in deciding what server will process a connection or request.

Two distinct technologies exist and address different needs, though with some
overlapping. In each case it is important to keep in mind that load balancing
consists in diverting the traffic from its natural flow and that doing so always
requires a minimum of care to maintain the required level of consistency between
all routing decisions.

The first one acts at the packet level and processes packets more or less
individually. There is a 1-to-1 relation between input and output packets, so
it is possible to follow the traffic on both sides of the load balancer using a
regular network sniffer. This technology can be very cheap and extremely fast.
It is usually implemented in hardware (ASICs) allowing to reach line rate, such
as switches doing ECMP. Usually stateless, it can also be stateful (consider
the session a packet belongs to and called layer4-LB or L4), may support DSR
(direct server return, without passing through the LB again) if the packets
were not modified, but provides almost no content awareness. This technology is
very well suited to network-level load balancing, though it is sometimes used
for very basic server load balancing at high speed.

The second one acts on session contents. It requires that the input streams is
reassembled and processed as a whole. The contents may be modified, and the
output stream is segmented into new packets. For this reason it is generally
performed by proxies and they're often called layer 7 load balancers or L7.
This implies that there are two distinct connections on each side, and that
there is no relation between input and output packets sizes nor counts. Clients
and servers are not required to use the same protocol (for example IPv4 vs
IPv6, clear vs SSL). The operations are always stateful, and the return traffic
must pass through the load balancer. The extra processing comes with a cost so
it's not always possible to achieve line rate, especially with small packets.
On the other hand, it offers wide possibilities and is generally achieved by
pure software, even if embedded into hardware appliances. This technology is
very well suited for server load balancing.

Packet-based load balancers are generally deployed in cut-through mode, so they
are installed on the normal path of the traffic and divert it according to the
configuration. The return traffic doesn't necessarily pass through the load
balancer. Some modifications may be applied to the network destination address
in order to direct the traffic to the proper destination. In this case, it is
mandatory that the return traffic passes through the load balancer. If the
routes doesn't make this possible, the load balancer may also replace the
packets' source address with its own in order to force the return traffic to
pass through it.

Proxy-based load balancers are deployed as a server with their own IP addresses
and ports, without architecture changes. Sometimes this requires to perform some
adaptations to the applications so that clients are properly directed to the
load balancer's IP address and not directly to the server's. Some load balancers
may have to adjust some servers' responses to make this possible (e.g. the HTTP
Location header field used in HTTP redirects). Some proxy-based load balancers
may intercept traffic for an address they don't own, and spoof the client's
address when connecting to the server. This allows them to be deployed as if
they were a regular router or firewall, in a cut-through mode very similar to
the packet based load balancers. This is particularly appreciated for products
which combine both packet mode and proxy mode. In this case DSR is obviously
still not possible and the return traffic still has to be routed back to the
load balancer.

A very scalable layered approach would consist in having a front router which
receives traffic from multiple load balanced links, and uses ECMP to distribute
this traffic to a first layer of multiple stateful packet-based load balancers
(L4). These L4 load balancers in turn pass the traffic to an even larger number
of proxy-based load balancers (L7), which have to parse the contents to decide
what server will ultimately receive the traffic.

The number of components and possible paths for the traffic increases the risk
of failure; in very large environments, it is even normal to permanently have
a few faulty components being fixed or replaced. Load balancing done without
awareness of the whole stack's health significantly degrades availability. For
this reason, any sane load balancer will verify that the components it intends
to deliver the traffic to are still alive and reachable, and it will stop
delivering traffic to faulty ones. This can be achieved using various methods.

The most common one consists in periodically sending probes to ensure the
component is still operational. These probes are called "health checks". They
must be representative of the type of failure to address. For example a ping-
based check will not detect that a web server has crashed and doesn't listen to
a port anymore, while a connection to the port will verify this, and a more
advanced request may even validate that the server still works and that the
database it relies on is still accessible. Health checks often involve a few
retries to cover for occasional measuring errors. The period between checks
must be small enough to ensure the faulty component is not used for too long
after an error occurs.

Other methods consist in sampling the production traffic sent to a destination
to observe if it is processed correctly or not, and to evict the components
which return inappropriate responses. However this requires to sacrifice a part
of the production traffic and this is not always acceptable. A combination of
these two mechanisms provides the best of both worlds, with both of them being
used to detect a fault, and only health checks to detect the end of the fault.
A last method involves centralized reporting : a central monitoring agent
periodically updates all load balancers about all components' state. This gives
a global view of the infrastructure to all components, though sometimes with
less accuracy or responsiveness. It's best suited for environments with many
load balancers and many servers.

Layer 7 load balancers also face another challenge known as stickiness or
persistence. The principle is that they generally have to direct multiple
subsequent requests or connections from a same origin (such as an end user) to
the same target. The best known example is the shopping cart on an online
store. If each click leads to a new connection, the user must always be sent
to the server which holds his shopping cart. Content-awareness makes it easier
to spot some elements in the request to identify the server to deliver it to,
but that's not always enough. For example if the source address is used as a
key to pick a server, it can be decided that a hash-based algorithm will be
used and that a given IP address will always be sent to the same server based
on a divide of the address by the number of available servers. But if one
server fails, the result changes and all users are suddenly sent to a different
server and lose their shopping cart. The solution against this issue consists
in memorizing the chosen target so that each time the same visitor is seen,
he's directed to the same server regardless of the number of available servers.
The information may be stored in the load balancer's memory, in which case it
may have to be replicated to other load balancers if it's not alone, or it may
be stored in the client's memory using various methods provided that the client
is able to present this information back with every request (cookie insertion,
redirection to a sub-domain, etc). This mechanism provides the extra benefit of
not having to rely on unstable or unevenly distributed information (such as the
source IP address). This is in fact the strongest reason to adopt a layer 7
load balancer instead of a layer 4 one.

In order to extract information such as a cookie, a host header field, a URL
or whatever, a load balancer may need to decrypt SSL/TLS traffic and even
possibly to re-encrypt it when passing it to the server. This expensive task
explains why in some high-traffic infrastructures, sometimes there may be a
lot of load balancers.

Since a layer 7 load balancer may perform a number of complex operations on the
traffic (decrypt, parse, modify, match cookies, decide what server to send to,
etc), it can definitely cause some trouble and will very commonly be accused of
being responsible for a lot of trouble that it only revealed. Often it will be
discovered that servers are unstable and periodically go up and down, or for
web servers, that they deliver pages with some hard-coded links forcing the
clients to connect directly to one specific server without passing via the load
balancer, or that they take ages to respond under high load causing timeouts.
That's why logging is an extremely important aspect of layer 7 load balancing.
Once a trouble is reported, it is important to figure if the load balancer took
a wrong decision and if so why so that it doesn't happen anymore.

HAProxy is written as "HAProxy" to designate the product, and as "haproxy" to
designate the executable program, software package or a process. However, both
are commonly used for both purposes, and are pronounced H-A-Proxy. Very early,
"haproxy" used to stand for "high availability proxy" and the name was written
in two separate words, though by now it means nothing else than "HAProxy".

HAProxy is :

  - a TCP proxy : it can accept a TCP connection from a listening socket,
    connect to a server and attach these sockets together allowing traffic to
    flow in both directions; IPv4, IPv6 and even UNIX sockets are supported on
    either side, so this can provide an easy way to translate addresses between
    different families.

  - an HTTP reverse-proxy (called a "gateway" in HTTP terminology) : it presents
    itself as a server, receives HTTP requests over connections accepted on a
    listening TCP socket, and passes the requests from these connections to
    servers using different connections. It may use any combination of HTTP/1.x
    or HTTP/2 on any side and will even automatically detect the protocol
    spoken on each side when ALPN is used over TLS.

  - an SSL terminator / initiator / offloader : SSL/TLS may be used on the
    connection coming from the client, on the connection going to the server,
    or even on both connections. A lot of settings can be applied per name
    (SNI), and may be updated at runtime without restarting. Such setups are
    extremely scalable and deployments involving tens to hundreds of thousands
    of certificates were reported.

  - a TCP normalizer : since connections are locally terminated by the operating
    system, there is no relation between both sides, so abnormal traffic such as
    invalid packets, flag combinations, window advertisements, sequence numbers,
    incomplete connections (SYN floods), or so will not be passed to the other
    side. This protects fragile TCP stacks from protocol attacks, and also
    allows to optimize the connection parameters with the client without having
    to modify the servers' TCP stack settings.

  - an HTTP normalizer : when configured to process HTTP traffic, only valid
    complete requests are passed. This protects against a lot of protocol-based
    attacks. Additionally, protocol deviations for which there is a tolerance
    in the specification are fixed so that they don't cause problem on the
    servers (e.g. multiple-line headers).

  - an HTTP fixing tool : it can modify / fix / add / remove / rewrite the URL
    or any request or response header. This helps fixing interoperability issues
    in complex environments.

  - a content-based switch : it can consider any element from the request to
    decide what server to pass the request or connection to. Thus it is possible
    to handle multiple protocols over a same port (e.g. HTTP, HTTPS, SSH).

  - a server load balancer : it can load balance TCP connections and HTTP
    requests. In TCP mode, load balancing decisions are taken for the whole
    connection. In HTTP mode, decisions are taken per request.

  - a traffic regulator : it can apply some rate limiting at various points,
    protect the servers against overloading, adjust traffic priorities based on
    the contents, and even pass such information to lower layers and outer
    network components by marking packets.

  - a protection against DDoS and service abuse : it can maintain a wide number
    of statistics per IP address, URL, cookie, etc and detect when an abuse is
    happening, then take action (slow down the offenders, block them, send them
    to outdated contents, etc).

  - an observation point for network troubleshooting : due to the precision of
    the information reported in logs, it is often used to narrow down some
    network-related issues.

  - an HTTP compression offloader : it can compress responses which were not
    compressed by the server, thus reducing the page load time for clients with
    poor connectivity or using high-latency, mobile networks.

  - a caching proxy : it may cache responses in RAM so that subsequent requests
    for the same object avoid the cost of another network transfer from the
    server as long as the object remains present and valid. It will however not
    store objects to any persistent storage. Please note that this caching
    feature is designed to be maintenance free and focuses solely on saving
    haproxy's precious resources and not on save the server's resources. Caches
    designed to optimize servers require much more tuning and flexibility. If
    you instead need such an advanced cache, please use Varnish Cache, which
    integrates perfectly with haproxy, especially when SSL/TLS is needed on any
    side.

  - a FastCGI gateway : FastCGI can be seen as a different representation of
    HTTP, and as such, HAProxy can directly load-balance a farm comprising any
    combination of FastCGI application servers without requiring to insert
    another level of gateway between them. This results in resource savings and
    a reduction of maintenance costs.

HAProxy is not :

  - an explicit HTTP proxy, i.e. the proxy that browsers use to reach the
    internet. There are excellent open-source software dedicated for this task,
    such as Squid. However HAProxy can be installed in front of such a proxy to
    provide load balancing and high availability.

  - a data scrubber : it will not modify the body of requests nor responses.

  - a static web server : during startup, it isolates itself inside a chroot
    jail and drops its privileges, so that it will not perform any single file-
    system access once started. As such it cannot be turned into a static web
    server (dynamic servers are supported through FastCGI however). There are
    excellent open-source software for this such as Apache or Nginx, and
    HAProxy can be easily installed in front of them to provide load balancing,
    high availability and acceleration.

  - a packet-based load balancer : it will not see IP packets nor UDP datagrams,
    will not perform NAT or even less DSR. These are tasks for lower layers.
    Some kernel-based components such as IPVS (Linux Virtual Server) already do
    this pretty well and complement perfectly with HAProxy.

HAProxy is an event-driven, non-blocking engine combining a very fast I/O layer
with a priority-based, multi-threaded scheduler. As it is designed with a data
forwarding goal in mind, its architecture is optimized to move data as fast as
possible with the least possible operations. It focuses on optimizing the CPU
cache's efficiency by sticking connections to the same CPU as long as possible.
As such it implements a layered model offering bypass mechanisms at each level
ensuring data doesn't reach higher levels unless needed. Most of the processing
is performed in the kernel, and HAProxy does its best to help the kernel do the
work as fast as possible by giving some hints or by avoiding certain operation
when it guesses they could be grouped later. As a result, typical figures show
15% of the processing time spent in HAProxy versus 85% in the kernel in TCP or
HTTP close mode, and about 30% for HAProxy versus 70% for the kernel in HTTP
keep-alive mode.

A single process can run many proxy instances; configurations as large as
300000 distinct proxies in a single process were reported to run fine. A single
core, single CPU setup is far more than enough for more than 99% users, and as
such, users of containers and virtual machines are encouraged to use the
absolute smallest images they can get to save on operational costs and simplify
troubleshooting. However the machine HAProxy runs on must never ever swap, and
its CPU must not be artificially throttled (sub-CPU allocation in hypervisors)
nor be shared with compute-intensive processes which would induce a very high
context-switch latency.

Threading allows to exploit all available processing capacity by using one
thread per CPU core. This is mostly useful for SSL or when data forwarding
rates above 40 Gbps are needed. In such cases it is critically important to
avoid communications between multiple physical CPUs, which can cause strong
bottlenecks in the network stack and in HAProxy itself. While counter-intuitive
to some, the first thing to do when facing some performance issues is often to
reduce the number of CPUs HAProxy runs on.

HAProxy only requires the haproxy executable and a configuration file to run.
For logging it is highly recommended to have a properly configured syslog daemon
and log rotations in place. Logs may also be sent to stdout/stderr, which can be
useful inside containers. The configuration files are parsed before starting,
then HAProxy tries to bind all listening sockets, and refuses to start if
anything fails. Past this point it cannot fail anymore. This means that there
are no runtime failures and that if it accepts to start, it will work until it
is stopped.

Once HAProxy is started, it does exactly 3 things :

  - process incoming connections;

  - periodically check the servers' status (known as health checks);

  - exchange information with other haproxy nodes.

Processing incoming connections is by far the most complex task as it depends
on a lot of configuration possibilities, but it can be summarized as the 9 steps
below :

  - accept incoming connections from listening sockets that belong to a
    configuration entity known as a "frontend", which references one or multiple
    listening addresses;

  - apply the frontend-specific processing rules to these connections that may
    result in blocking them, modifying some headers, or intercepting them to
    execute some internal applets such as the statistics page or the CLI;

  - pass these incoming connections to another configuration entity representing
    a server farm known as a "backend", which contains the list of servers and
    the load balancing strategy for this server farm;

  - apply the backend-specific processing rules to these connections;

  - decide which server to forward the connection to according to the load
    balancing strategy;

  - apply the backend-specific processing rules to the response data;

  - apply the frontend-specific processing rules to the response data;

  - emit a log to report what happened in fine details;

  - in HTTP, loop back to the second step to wait for a new request, otherwise
    close the connection.

Frontends and backends are sometimes considered as half-proxies, since they only
look at one side of an end-to-end connection; the frontend only cares about the
clients while the backend only cares about the servers. HAProxy also supports
full proxies which are exactly the union of a frontend and a backend. When HTTP
processing is desired, the configuration will generally be split into frontends
and backends as they open a lot of possibilities since any frontend may pass a
connection to any backend. With TCP-only proxies, using frontends and backends
rarely provides a benefit and the configuration can be more readable with full
proxies.

This section will enumerate a number of features that HAProxy implements, some
of which are generally expected from any modern load balancer, and some of
which are a direct benefit of HAProxy's architecture. More advanced features
will be detailed in the next section.

Proxying is the action of transferring data between a client and a server over
two independent connections. The following basic features are supported by
HAProxy regarding proxying and connection management :

  - Provide the server with a clean connection to protect them against any
    client-side defect or attack;

  - Listen to multiple IP addresses and/or ports, even port ranges;

  - Transparent accept : intercept traffic targeting any arbitrary IP address
    that doesn't even belong to the local system;

  - Server port doesn't need to be related to listening port, and may even be
    translated by a fixed offset (useful with ranges);

  - Transparent connect : spoof the client's (or any) IP address if needed
    when connecting to the server;

  - Provide a reliable return IP address to the servers in multi-site LBs;

  - Offload the server thanks to buffers and possibly short-lived connections
    to reduce their concurrent connection count and their memory footprint;

  - Optimize TCP stacks (e.g. SACK), congestion control, and reduce RTT impacts;

  - Support different protocol families on both sides (e.g. IPv4/IPv6/Unix);

  - Timeout enforcement : HAProxy supports multiple levels of timeouts depending
    on the stage the connection is, so that a dead client or server, or an
    attacker cannot be granted resources for too long;

  - Protocol validation: HTTP, SSL, or payload are inspected and invalid
    protocol elements are rejected, unless instructed to accept them anyway;

  - Policy enforcement : ensure that only what is allowed may be forwarded;

  - Both incoming and outgoing connections may be limited to certain network
    namespaces (Linux only), making it easy to build a cross-container,
    multi-tenant load balancer;

  - PROXY protocol presents the client's IP address to the server even for
    non-HTTP traffic. This is an HAProxy extension that was adopted by a number
    of third-party products by now, at least these ones at the time of writing :
      - client : haproxy, stud, stunnel, exaproxy, ELB, squid
      - server : haproxy, stud, postfix, exim, nginx, squid, node.js, varnish

HAProxy's SSL stack is recognized as one of the most featureful according to
Google's engineers (http://istlsfastyet.com/). The most commonly used features
making it quite complete are :

  - SNI-based multi-hosting with no limit on sites count and focus on
    performance. At least one deployment is known for running 50000 domains
    with their respective certificates;

  - support for wildcard certificates reduces the need for many certificates ;

  - certificate-based client authentication with configurable policies on
    failure to present a valid certificate. This allows to present a different
    server farm to regenerate the client certificate for example;

  - authentication of the backend server ensures the backend server is the real
    one and not a man in the middle;

  - authentication with the backend server lets the backend server know it's
    really the expected haproxy node that is connecting to it;

  - TLS NPN and ALPN extensions make it possible to reliably offload SPDY/HTTP2
    connections and pass them in clear text to backend servers;

  - OCSP stapling further reduces first page load time by delivering inline an
    OCSP response when the client requests a Certificate Status Request;

  - Dynamic record sizing provides both high performance and low latency, and
    significantly reduces page load time by letting the browser start to fetch
    new objects while packets are still in flight;

  - permanent access to all relevant SSL/TLS layer information for logging,
    access control, reporting etc. These elements can be embedded into HTTP
    header or even as a PROXY protocol extension so that the offloaded server
    gets all the information it would have had if it performed the SSL
    termination itself.

  - Detect, log and block certain known attacks even on vulnerable SSL libs,
    such as the Heartbleed attack affecting certain versions of OpenSSL.

  - support for stateless session resumption (RFC 5077 TLS Ticket extension).
    TLS tickets can be updated from CLI which provides them means to implement
    Perfect Forward Secrecy by frequently rotating the tickets.

HAProxy focuses a lot on availability. As such it cares about servers state,
and about reporting its own state to other network components :

  - Servers' state is continuously monitored using per-server parameters. This
    ensures the path to the server is operational for regular traffic;

  - Health checks support two hysteresis for up and down transitions in order
    to protect against state flapping;

  - Checks can be sent to a different address/port/protocol : this makes it
    easy to check a single service that is considered representative of multiple
    ones, for example the HTTPS port for an HTTP+HTTPS server.

  - Servers can track other servers and go down simultaneously : this ensures
    that servers hosting multiple services can fail atomically and that no one
    will be sent to a partially failed server;

  - Agents may be deployed on the server to monitor load and health : a server
    may be interested in reporting its load, operational status, administrative
    status independently from what health checks can see. By running a simple
    agent on the server, it's possible to consider the server's view of its own
    health in addition to the health checks validating the whole path;

  - Various check methods are available : TCP connect, HTTP request, SMTP hello,
    SSL hello, LDAP, SQL, Redis, send/expect scripts, all with/without SSL;

  - State change is notified in the logs and stats page with the failure reason
    (e.g. the HTTP response received at the moment the failure was detected). An
    e-mail can also be sent to a configurable address upon such a change ;

  - Server state is also reported on the stats interface and can be used to take
    routing decisions so that traffic may be sent to different farms depending
    on their sizes and/or health (e.g. loss of an inter-DC link);

  - HAProxy can use health check requests to pass information to the servers,
    such as their names, weight, the number of other servers in the farm etc.
    so that servers can adjust their response and decisions based on this
    knowledge (e.g. postpone backups to keep more CPU available);

  - Servers can use health checks to report more detailed state than just on/off
    (e.g. I would like to stop, please stop sending new visitors);

  - HAProxy itself can report its state to external components such as routers
    or other load balancers, allowing to build very complete multi-path and
    multi-layer infrastructures.

Just like any serious load balancer, HAProxy cares a lot about availability to
ensure the best global service continuity :

  - Only valid servers are used ; the other ones are automatically evicted from
    load balancing farms ; under certain conditions it is still possible to
    force to use them though;

  - Support for a graceful shutdown so that it is possible to take servers out
    of a farm without affecting any connection;

  - Backup servers are automatically used when active servers are down and
    replace them so that sessions are not lost when possible. This also allows
    to build multiple paths to reach the same server (e.g. multiple interfaces);

  - Ability to return a global failed status for a farm when too many servers
    are down. This, combined with the monitoring capabilities makes it possible
    for an upstream component to choose a different LB node for a given service;

  - Stateless design makes it easy to build clusters : by design, HAProxy does
    its best to ensure the highest service continuity without having to store
    information that could be lost in the event of a failure. This ensures that
    a takeover is the most seamless possible;

  - Integrates well with standard VRRP daemon keepalived : HAProxy easily tells
    keepalived about its state and copes very well with floating virtual IP
    addresses. Note: only use IP redundancy protocols (VRRP/CARP) over cluster-
    based solutions (Heartbeat, ...) as they're the ones offering the fastest,
    most seamless, and most reliable switchover.

HAProxy offers a fairly complete set of load balancing features, most of which
are unfortunately not available in a number of other load balancing products :

  - no less than 10 load balancing algorithms are supported, some of which apply
    to input data to offer an infinite list of possibilities. The most common
    ones are round-robin (for short connections, pick each server in turn),
    leastconn (for long connections, pick the least recently used of the servers
    with the lowest connection count), source (for SSL farms or terminal server
    farms, the server directly depends on the client's source address), URI (for
    HTTP caches, the server directly depends on the HTTP URI), hdr (the server
    directly depends on the contents of a specific HTTP header field), first
    (for short-lived virtual machines, all connections are packed on the
    smallest possible subset of servers so that unused ones can be powered
    down);

  - all algorithms above support per-server weights so that it is possible to
    accommodate from different server generations in a farm, or direct a small
    fraction of the traffic to specific servers (debug mode, running the next
    version of the software, etc);

  - dynamic weights are supported for round-robin, leastconn and consistent
    hashing ; this allows server weights to be modified on the fly from the CLI
    or even by an agent running on the server;

  - slow-start is supported whenever a dynamic weight is supported; this allows
    a server to progressively take the traffic. This is an important feature
    for fragile application servers which require to compile classes at runtime
    as well as cold caches which need to fill up before being run at full
    throttle;

  - hashing can apply to various elements such as client's source address, URL
    components, query string element, header field values, POST parameter, RDP
    cookie;

  - consistent hashing protects server farms against massive redistribution when
    adding or removing servers in a farm. That's very important in large cache
    farms and it allows slow-start to be used to refill cold caches;

  - a number of internal metrics such as the number of connections per server,
    per backend, the amount of available connection slots in a backend etc makes
    it possible to build very advanced load balancing strategies.