Layer 4 Load Balancing

Layer 4 load balancers inspect only the IP packet headers, specifically the source and destination IP addresses and TCP/UDP port numbers. They do not decrypt or inspect the payload content of packets. This allows for extremely fast routing decisions, often implemented in hardware or kernel-space software, with latencies typically under 1 millisecond. Decisions are based on simple, stateless rules like directing all traffic on port 80 (HTTP) to one server pool and traffic on port 443 (HTTPS) to another.

Routing is performed on a per-connection basis. Once a client initiates a TCP handshake (SYN packet) with the load balancer's Virtual IP (VIP), the load balancer selects a backend server and forwards all subsequent packets for that connection's 5-tuple (source IP, source port, destination IP, destination port, protocol) to the same server. This provides basic session persistence for the duration of the TCP connection, but does not inherently maintain persistence across multiple connections from the same client.

Due to its simplicity, Layer 4 load balancing is designed for maximum throughput and minimum latency. It is ideal for handling massive volumes of raw network traffic, such as:

• Streaming media (video, audio)
• Online gaming traffic
• Voice over IP (VoIP)
• Database clustering protocols
• Any protocol where packet-level speed is more critical than content-aware routing. It efficiently distributes millions of packets per second with minimal computational overhead.

A Layer 4 load balancer typically operates in Direct Server Return (DSR) or Network Address Translation (NAT) mode. In NAT mode, the load balancer modifies the destination IP of the incoming packet to that of the selected backend server. The server sees the load balancer's IP as the source. This provides transparency but requires the return traffic to flow back through the load balancer. In DSR mode, the server responds directly to the client, improving efficiency but requiring more complex network configuration.

Health checks are simple and network-focused. The load balancer periodically probes backend servers by attempting to establish a TCP connection to a specified port (e.g., port 22 for SSH, 80 for HTTP). If the connection succeeds, the server is considered healthy. More advanced checks might send a basic protocol-specific probe (like an HTTP GET request) but still operate at the connection level. This is less granular than Layer 7 health checks but is faster and consumes fewer resources.

Primary Use Cases:

• Distributing non-HTTP(S) protocols (e.g., DNS, FTP, SMTP, custom TCP/UDP).
• SSL/TLS Passthrough, where encrypted traffic is forwarded to backend servers for decryption.
• Building high-performance, scalable foundations for applications where content-aware routing is not required.

Key Limitations:

• Cannot make routing decisions based on HTTP headers, URLs, or cookies.
• Cannot perform content-based switching (e.g., route /api/ to one pool and /images/ to another).
• Provides less intelligent traffic management compared to Layer 7 (Application Layer) load balancers.

Layer 4 load balancers excel at distributing massive volumes of raw TCP and UDP traffic. They inspect only the IP header and port numbers, making routing decisions with ultra-low latency (often sub-millisecond). This is critical for:

• Real-time applications like gaming, VoIP, and live video streaming.
• Database clusters requiring fast connection routing for read replicas.
• DNS servers handling billions of UDP-based queries. The algorithm is typically simple (e.g., round-robin, least connections), minimizing computational overhead and maximizing throughput for connection-oriented and connectionless protocols.

Operating at the transport layer allows these balancers to act as a first line of defense. They can perform TCP SYN flood mitigation by terminating client connections and validating them before proxying to backend servers. Key security functions include:

• IP whitelisting/blacklisting based on source IP addresses.
• Rate limiting connections per second from a single IP.
• SSL/TLS termination, offloading expensive decryption/encryption cycles from application servers.
• Absorbing volumetric attacks before they reach vulnerable application logic, providing a security perimeter for the entire server fleet.

This is the quintessential use case for enabling elastic scalability. A Layer 4 load balancer presents a single Virtual IP (VIP) to clients while distributing requests across a dynamically changing pool of identical backend instances. It is ideal for:

• Web server farms (e.g., Nginx, Apache clusters) where sessions are not stored locally.
• Microservices with stateless APIs.
• Environments using auto-scaling groups, where the balancer's health checks automatically add or remove instances from the pool. This decouples client endpoints from the underlying infrastructure, allowing for zero-downtime deployments and repairs.

Layer 4 balancers provide robust active-active or active-passive failover configurations for non-HTTP services. By continuously monitoring backend health via TCP health checks, they ensure traffic is only directed to healthy nodes. This is essential for:

• Database proxy layers (e.g., for PostgreSQL or MySQL read pools).
• Mail servers (SMTP, IMAP).
• Custom TCP-based enterprise applications and legacy systems. The use of protocols like VRRP (Virtual Router Redundancy Protocol) allows multiple physical load balancers to share a VIP, creating a highly available load balancing service itself.

Layer 4 principles are extended geographically in Global Server Load Balancing. A GSLB solution uses DNS and Layer 4 health checks to direct users to the optimal data center based on:

• Geographic proximity (latency-based routing).
• Data center health (active/available capacity).
• Explicit policies (e.g., disaster recovery failover). When a user's request arrives at the chosen data center, the local Layer 4 load balancer then distributes it within the server pool. This creates a resilient, multi-region architecture for global applications.

Unlike HTTP-based (Layer 7) balancers that may inspect each request/response, Layer 4 balancers establish a connection and then largely let the packet flow. This makes them optimal for:

• SSH, RDP, or VPN access to a pool of bastion hosts.
• Real-time messaging protocols like MQTT or XMPP.
• Streaming media where a single TCP connection carries a continuous flow of data.
• Financial trading platforms requiring persistent, low-latency sockets. Once the initial routing decision is made, all packets for that connection follow the same path, ensuring consistency and performance for stateful, long-duration sessions.