How Load Balancers Distribute UDP Traffic
This article provides an overview of how Layer 4 load balancers manage and distribute User Datagram Protocol (UDP) traffic across backend server pools. Unlike TCP, UDP is connectionless, presenting unique challenges for traffic distribution, session persistence, and health monitoring. Below, we explore the mechanisms, algorithms, routing methods, and session-tracking techniques load balancers use to route UDP datagrams efficiently for applications like DNS, VoIP, video streaming, and online gaming.
The Challenge of UDP Load Balancing
TCP relies on a three-way handshake to establish a continuous session, making it straightforward for a load balancer to track active connections. In contrast, UDP sends discrete datagrams without establishing a handshake or maintaining a state.
Because the protocol lacks native connection states, UDP load balancers create “pseudo-connections” or rely on packet-level attributes to decide where each datagram should be routed.
Key Mechanisms for UDP Distribution
1. Tuple Hashing
The primary method for distributing UDP traffic is calculating a hash value from packet header fields:
- 2-Tuple Hashing: Uses Source IP and Destination IP.
- 4-Tuple / 5-Tuple Hashing: Uses Source IP, Source Port, Destination IP, Destination Port, and Protocol.
The hash value maps directly to a specific backend server. This ensures that packets originating from the same client endpoint consistently reach the same backend server.
2. Connection Tracking and Session Tables
For protocols requiring multi-packet exchanges (such as streaming or gaming), the load balancer maintains a state table in memory:
- When the first packet from a client arrives, the load balancer selects a server based on its configured algorithm.
- An entry is created in the session table mapping the client’s 5-tuple to the selected backend server.
- Subsequent packets matching that 5-tuple are routed to the same server.
- Because UDP has no explicit termination signal (like a TCP FIN packet), the load balancer uses an inactivity timeout. If no packets are received within a set window (e.g., 30 to 60 seconds), the session entry expires.
Common Distribution Algorithms
- Round Robin / Weighted Round Robin: Packets or new pseudo-sessions are distributed sequentially across servers, factoring in assigned server weights.
- Least Connections / Least Packets: Routes new traffic to the server currently processing the fewest active pseudo-sessions or datagrams.
- Consistent Hashing: Minimizes session reshuffling when backend servers are added or removed, preventing disruptions in streaming or gaming environments.
Packet Forwarding Methods
Load balancers forward UDP packets using one of several network architectures:
- Network Address Translation (NAT): The load balancer modifies the destination IP of the incoming packet to match the chosen backend server. The return traffic must pass back through the load balancer to translate the source IP back to the virtual IP (VIP).
- Direct Server Return (DSR): The load balancer forwards the packet to the backend server without altering the source or destination IP (often using MAC-layer rewriting). The backend server processes the request and responds directly to the client, bypassing the load balancer on the return path. This reduces bandwidth bottlenecks on the load balancer.
- IP Tunneling (GRE / IP-in-IP): The load balancer encapsulates the original UDP packet in a new IP header and sends it to the backend server across Layer 3 boundaries.
Health Checking for UDP Backends
Because UDP does not acknowledge receipt of packets, load balancers verify backend availability through indirect methods:
- Application-Specific Probes: The load balancer sends a valid protocol-specific query (such as a DNS query or SIP OPTIONS request) and expects a specific response.
- ICMP Port Unreachable: The load balancer sends a UDP packet. If the service is down, the operating system returns an ICMP “Port Unreachable” error, signaling to remove the node from the active pool.
- TCP Side-Channel Checks: If the application exposes a companion TCP service (like an HTTP health endpoint), the load balancer monitors the TCP endpoint to determine overall service health.