Mastering Load Balancing: HTTP Redirect, DNS, Reverse Proxy, and LVS Techniques

1. HTTP Redirection

When an HTTP client requests a URL, the web server can respond with a Location header pointing to a new URL, causing the client to follow the redirect automatically.

Performance drawbacks:

Throughput limitation: The main server’s throughput must be high enough to forward requests to all backend servers. For example, with a round‑robin (RR) scheduler and three backends each handling 1000 req/s, the front‑end must sustain 3000 req/s; otherwise more backends are needed.

Uneven redirect depth: Redirecting static pages versus complex dynamic pages leads to unpredictable load on the actual servers, making pure redirect‑based load balancing suboptimal.

Balancing the overhead of redirection against the cost of handling real requests determines the usefulness of redirects, as seen in many mirror download sites.

2. DNS Load Balancing

DNS resolves domain names to IP addresses. By returning multiple A records, a DNS server can distribute client requests across several servers, acting as a load‑balancing scheduler without the throughput limits of HTTP redirects.

Example (using dig) shows that baidu.com has three A records.

Features:

Intelligent resolution based on client IP, directing users to the nearest server.

Dynamic DNS updates when IP addresses change (subject to caching delays).

Limitations:

Clients cannot see which actual server they reach, complicating debugging.

DNS cannot incorporate HTTP‑level context (e.g., URL‑based routing).

Custom load‑balancing logic based on real‑time server load requires complex DNS configuration.

DNS caching at various levels can obscure real‑time distribution.

3. Reverse Proxy Load Balancing

Most mainstream web servers support reverse‑proxy load balancing, forwarding HTTP requests to backend servers.

Key characteristics:

All client requests pass through the proxy.

The proxy waits for backend responses and relays them to the client.

Rich scheduling options, such as weighted distribution.

High concurrency requirements for the proxy itself.

Additional overhead for establishing TCP connections, thread creation, and header processing.

Ability to monitor backend health (load, response time, connections) and adjust policies.

Support for sticky sessions, keeping a user’s requests on the same backend.

4. IP Load Balancing (LVS‑NAT)

LVS (Linux Virtual Server) operates at the transport layer using NAT. The kernel’s Netfilter module and iptables manage packet filtering, while the IPVS module implements load balancing.

Check if IPVS is installed (output indicates presence).

Configuration steps (commands shown as code):

echo 1 > /proc/sys/net/ipv4/ip_forward

route add default gw <gateway_ip>

ipvsadm -A -t 111.11.11.11:80 -s rr

Adding two real servers (internal IPs) with NAT forwarding:

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

View server status with ipvsadm -L -n. NAT‑based load balancing can double throughput compared to reverse proxy, but large payloads diminish the advantage.

5. Direct Routing (LVS‑DR)

DR works at the data‑link layer, altering the destination MAC address while keeping the IP unchanged, allowing backend responses to bypass the scheduler.

Network setup example: one scheduler, two backends, three public IPs, with an alias IP (e.g., 10.10.120.193) used as the virtual address.

On each backend, add the alias to the loopback interface and adjust ARP settings:

echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce

Configure the DR cluster:

ipvsadm -A -t 10.10.120.193:80 -s rr

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.210:80 -r

ipvsadm -a -t 10.10.120.193:80 -r 10.10.120.211:80 -r

DR removes the scheduler’s bandwidth bottleneck, allowing backend servers to send responses directly to clients, which is advantageous for traffic‑heavy services.

6. IP Tunnel (LVS‑TUN)

TUN encapsulates the incoming IP packet in a new IP header and forwards it to the backend; the backend’s reply can go straight to the client. This works across different WAN subnets, provided each server has a legal IP address.

Both DR and TUN suit asymmetric request/response workloads; the choice depends on deployment topology and the need for geographically distributed backends.

Conclusion : Selecting the appropriate load‑balancing method—HTTP redirect, DNS, reverse proxy, LVS‑NAT, LVS‑DR, or LVS‑TUN—depends on performance requirements, network architecture, and scalability goals.