Load Balancing Part 2: The Layer 4 Workhorse

Layer 7 load balancers are smart—they can read HTTP headers, inspect cookies, and route traffic based on URL paths. But that intelligence comes at a cost: latency. The load balancer must terminate the connection, parse the request, and then open a new connection to the backend. For many workloads—databases, gaming servers, IoT protocols, or raw TCP streams—you do not need that intelligence. You need raw speed. You need the packet to arrive at the backend as fast as physically possible, with its original source IP intact. This is where Layer 4 (TCP/UDP) load balancing comes in.

Google Cloud offers several L4 load balancers, but the most important one for the PCNE exam is the External Network Load Balancer (Passthrough). Unlike the L7 LB, which acts as a reverse proxy, the passthrough LB does exactly what its name suggests: it passes the packet through to the backend without terminating the connection. The backend VM sees the original client IP as the source address. This is critical for protocols that do not tolerate connection termination, like database replication, SIP, or custom UDP applications.

Passthrough vs. Proxy: The Fundamental Choice

This is one of the most commonly tested distinctions on the exam.

Passthrough (Network LB)
  1. The load balancer does not terminate the connection.
  2. The backend VM sees the original client IP in the packet header.
  3. Works for TCP and UDP, including non-HTTP protocols.
  4. Regional resource only.
  5. Uses Maglev consistent hashing for distribution.
Proxy (TCP/SSL Proxy LB)
  1. The load balancer terminates the connection and opens a new one to the backend.
  2. The backend sees the load balancer’s IP as the source (original IP is passed in the X-Forwarded-For header or Proxy Protocol).
  3. Can be global (Premium Tier) for TCP/SSL traffic.
  4. Useful when you need SSL offloading without HTTP routing.

If the exam asks “The application needs to see the original client IP in the packet header,” the answer is always Passthrough.

Maglev: Google’s Secret Weapon

Behind the scenes, Google’s passthrough LB uses a system called Maglev. It is a distributed consistent-hashing algorithm that runs on Google’s network edge. It does not run on a single machine—it runs on every machine in the fleet simultaneously.

What makes Maglev special?

  1. No single point of failure. If one Maglev node dies, the others continue without session disruption.
  2. Consistent hashing. The same client IP always lands on the same backend, enabling connection affinity without sticky sessions.
  3. Millions of connections per second. This is the same technology that powers Google Search and YouTube.
Health Checks: The Silent Watchdog

Every load balancer, L4 or L7, depends on health checks to know which backends are alive. If a backend fails its health check, the LB stops sending traffic to it.

  1. Protocol: You can health-check via HTTP, HTTPS, TCP, SSL, or gRPC.
  2. Interval: How often the check runs (default: 5 seconds for HTTP).
  3. Unhealthy Threshold: How many consecutive failures before marking a backend as down (default: 2).
  4. Source Range: Health check probes come from well-known Google IP ranges: 35.191.0.0/16 and 130.211.0.0/22. You must allow these ranges in your firewall rules, or your backends will always appear unhealthy.
Internal TCP/UDP Load Balancer

The Internal L4 LB is the workhorse for internal traffic. It provides a single internal IP that distributes traffic to backend VMs within your VPC.

  1. Use as Next Hop: You can set an Internal LB as the “next hop” in a custom route. This is how you route all traffic through an NVA (network virtual appliance) for inspection—without a single point of failure.
  2. Failover: If your active NVA dies, the LB automatically sends traffic to the standby NVA.
  3. Connection Draining: When a backend is removed, existing connections are allowed to complete gracefully before the backend is fully deregistered.
Putting it Together: A Pro-Engineer View

Imagine you are running a multiplayer gaming platform. Your game servers use a custom UDP protocol on port 7777. Players need sub-10ms response times, and the server must see the player’s real IP for anti-cheat validation. You deploy an External Passthrough Network LB on Premium Tier. Maglev hashes each player’s IP to a consistent backend, so their session stays on the same server. Health checks ping UDP port 7777 every 3 seconds. If a game server crashes mid-match, the health check threshold of 2 means it is removed in 6 seconds, and new players are routed to healthy servers. The player’s real IP is preserved in every packet. No proxy overhead. No connection termination. Pure speed.

Related Posts