How millions of packets are routed without ever reading their contents.
When you have 10,000 servers, you need a Load Balancer in front to distribute the traffic. But how does the Load Balancer itself not become a bottleneck? If it stops to read every single HTTP request (e.g., GET /video.mp4), it has to decrypt TLS, parse headers, and re-encrypt data—that takes massive CPU. To go blindingly fast, a Layer 4 Load Balancer doesn't read the HTTP data at all. It only looks at the raw TCP/IP packet envelope (Source IP, Destination IP, Port). It rewrites the Destination IP to point to a backend server and forwards the raw bytes blindly. It's essentially a lightning-fast mail sorter that never opens the envelopes.
Layer 4 balancing relies on the OS kernel (like Linux's iptables or IPVS) to rewrite packet headers in hardware/kernel-space, completely bypassing slow user-space applications (like Nginx). The Load Balancer intercepts a packet destined for itself, hashes the Source IP to pick a backend server, rewrites the Destination IP, and sends it on.
// Conceptual Logic of an L4 Balancer (happens in the OS Kernel)
function onPacketReceived(packet) {
// 1. Read ONLY the envelope (Layer 3/4 headers)
const srcIp = packet.headers.sourceIP;
// 2. Hash the Source IP to pick a backend (e.g. 10.0.0.5)
// This ensures the same user always hits the same server
// to maintain their TCP handshake state.
const backendIp = backendList[hash(srcIp) % backendList.length];
// 3. Rewrite the destination on the envelope (NAT)
packet.headers.destIP = backendIp;
// 4. Forward it blindly. We NEVER read packet.payload!
forward(packet);
}Layer 4 balancers are incredibly fast and use almost no CPU. However, because they never decrypt or read the HTTP data, they are "dumb". They cannot route traffic based on the URL (e.g., sending /api to one server and /images to another). They cannot read Cookies to maintain user sessions. For smart routing, you need a slow, CPU-heavy Layer 7 (HTTP) Load Balancer.