Load Balancing Deep Dive: HTTP Redirects, DNS, Reverse Proxy, and LVS Techniques

Load balancing aims to keep each server from being overloaded while maximizing the total service capacity. Because servers differ in hardware, bandwidth, or role, a balanced system distributes traffic according to each server’s actual capability.

1. HTTP Redirection

A web server can return a Location header, causing the client to issue a second request to a different URL. This method is simple but has two major drawbacks:

Throughput limitation – The front‑end server must handle the combined request rate of all back‑ends. For example, with three back‑ends each capable of 1000 req/s under round‑robin, the front‑end must sustain 3000 req/s. Scaling to dozens of back‑ends quickly exceeds realistic front‑end capacity.

Variable redirect depth – Static and dynamic pages generate different processing loads, which the front‑end cannot predict, making pure HTTP redirects unsuitable for fine‑grained balancing.

Redirection is useful only when the extra round‑trip latency is negligible compared with the actual request processing (e.g., download mirrors).

2. DNS Load Balancing

DNS can return multiple A records for a single domain name. Resolvers select one of the IPs, effectively distributing clients across several servers.

Advantages

Resolver can choose the nearest IP based on client address, providing geographic proximity.

Dynamic DNS updates allow rapid IP changes; caching delays are the only limitation.

Limitations

Operators cannot directly observe which back‑end a client reaches, complicating troubleshooting.

DNS operates below the HTTP layer, so it cannot use URL paths or other HTTP‑level context for routing decisions.

Health‑check‑driven routing requires custom development or third‑party services.

Cache propagation across the DNS hierarchy can cause temporary routing inconsistencies.

3. Reverse‑Proxy Load Balancing

Most modern web servers (nginx, Apache, HAProxy, etc.) can act as reverse proxies, receiving every client request, forwarding it to a back‑end, waiting for the response, and relaying the response back to the client.

Key characteristics

All traffic passes through the proxy, allowing centralized logging and TLS termination.

The proxy can implement rich scheduling policies (round‑robin, weighted round‑robin, least connections, etc.).

High concurrency is required because the proxy operates at the HTTP layer.

Forwarding incurs overhead: thread or coroutine creation, TCP connection setup, header parsing, and user‑kernel context switches. This overhead becomes noticeable when back‑end processing is very fast (e.g., static file serving).

Proxies can monitor back‑end metrics (CPU load, latency, connection count) and adjust routing dynamically.

Sticky sessions (session affinity) keep a client’s subsequent requests on the same back‑end.

4. IP Load Balancing (LVS‑NAT)

Linux Virtual Server (LVS) can perform load balancing at the IP layer using Network Address Translation (NAT). The scheduler rewrites the destination IP of incoming packets and forwards them to real servers.

Prerequisites

Kernel 2.4+ provides Netfilter; kernel 2.6+ includes the IPVS module.

Install ipvsadm to manage IPVS rules.

Configuration steps

# Enable IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward

# Ensure each real server uses the NAT box as its default gateway
route add default gw <NAT_IP>

# Create a virtual service on the scheduler (IP:port) with round‑robin
ipvsadm -A -t 111.11.11.11:80 -s rr

# Add real servers (NAT mode = -m)
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.210:8000 -m
ipvsadm -a -t 111.11.11.11:80 -r 10.10.120.211:8000 -m

# Verify the configuration
ipvsadm -L -n

Performance observations

In low‑latency workloads, NAT‑based LVS can double throughput compared with a reverse‑proxy because packet forwarding occurs in kernel space.

When payload size grows, the advantage diminishes because the network bandwidth becomes the bottleneck.

5. Direct Routing (LVS‑DR)

Direct Routing operates at the data‑link layer: the scheduler rewrites only the destination MAC address, leaving the IP unchanged. Real servers send responses directly to the client, bypassing the scheduler.

Typical topology: one scheduler, two real servers, three public IPs, plus an IP alias (e.g., 10.10.120.193) on the scheduler.

ARP handling to avoid address conflicts

echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore
echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce
echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore
echo 1 > /proc/sys/net/ipv4/conf/all/arp_announce

Configure LVS‑DR

ipvsadm -A -t 10.10.120.193:80 -s rr
ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:8000 -g
ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:8000 -g

Because responses bypass the scheduler, the system’s outbound bandwidth is limited only by the real servers’ WAN links, not by the scheduler’s NIC. This makes DR ideal for services where response traffic far exceeds request traffic (e.g., file download or video streaming).

6. IP Tunnel (LVS‑TUN)

LVS‑TUN encapsulates the original packet in a new IP header and sends it through a tunnel to a remote real server that may reside in a different subnet or data center. The real server’s reply is sent directly to the client, preserving the original source address.

Use cases

Geographically distributed back‑ends where direct routing is impossible because the servers are not on the same LAN.

Scenarios requiring asymmetric routing (request path differs from response path).

Both DR and TUN remove the scheduler’s bandwidth bottleneck and are suited for asymmetric web services; the choice depends on network topology and whether cross‑region deployment is needed.