L4 vs L7 Balancing

An L4 load balancer passes millions of packets per second but does not know what is inside. L7 understands HTTP and can route /api to one set of servers and /static to another. Speed or intelligence - which do you choose?

• **AWS NLB** (Network Load Balancer) - L4, millions of connections, minimal latency
• **AWS ALB** (Application Load Balancer) - L7, URL routing, host-based routing
• **Cloudflare** - L7 LB with DDoS protection, WAF, and edge caching

Предварительные знания

• Load Balancing: Basics

L4 Load Balancing: Transport Layer

An **L4 Load Balancer** operates at the transport layer (TCP/UDP). It sees IP addresses and ports but does not understand the contents of packets. Routing decisions are made based on source and destination IP:port.

**L4 advantages**: very high throughput (millions of connections/sec), minimal latency, protocol-agnostic. Suitable for any TCP/UDP traffic.

L4 LB can use **DSR (Direct Server Return)** - responses from the server go directly to the client, bypassing the load balancer. This reduces load on the LB (responses are usually larger than requests) but makes configuration more complex.

L7 Load Balancing: Application Layer

An **L7 Load Balancer** understands the application protocol (HTTP, gRPC, WebSocket). It can route by URL, headers, cookies, and request body. This provides flexibility but requires more resources.

**Content-based routing** - an L7 LB can route `/api/v1` to old servers and `/api/v2` to new ones. This enables canary deployments and A/B testing.

An L7 LB terminates the TCP connection from the client and opens a new one to the backend. This allows it to modify requests (add headers), cache responses, and compress data.

SSL/TLS Termination

**SSL Termination** - decrypting HTTPS at the load balancer. Backend servers receive plain HTTP. This simplifies certificate management (one cert on the LB instead of N on each server) and reduces backend load.

**SSL Passthrough** - an alternative: the LB does not decrypt traffic, it forwards TCP packets directly. The backend terminates SSL itself. The LB operates at L4 and does not see HTTP.

**SSL Re-encryption** - a compromise: the LB decrypts HTTPS, performs routing, then re-encrypts for the backend. Double encryption/decryption, but traffic is protected end-to-end.

Sticky Sessions: Server Affinity

**Sticky Sessions** (session affinity) - all requests from one client go to the same server. Required when the server stores session state in memory (legacy apps, WebSocket, shopping carts).

**Sticky session problem**: if the server goes down - the user loses their session. The better approach is a stateless backend + external session storage (Redis, PostgreSQL).

**IP Hash** works at L4 but has a problem: thousands of users behind NAT share one IP - all of them land on the same server. Cookie-based sticky works only at L7 but ties a specific user more precisely.

Key Ideas

• **L4 LB** - works with TCP/UDP, fast, supports DSR, but does not see HTTP. For raw performance
• **L7 LB** - understands HTTP, routing by URL/headers, SSL termination, caching. For flexibility
• **Sticky Sessions** - binds a client to a server via cookie/IP hash. Avoid - use stateless + Redis instead

Related Topics

L4/L7 balancing is tied to other infrastructure components:

• Load Balancing Basics — Algorithms and health checks apply at both layers
• Reverse Proxy — Nginx/HAProxy often act as both L7 LB and reverse proxy

Вопросы для размышления

• Why do WebSocket connections usually require sticky sessions even with a stateless backend?
• When is SSL Passthrough better than SSL Termination from a security standpoint?
• How would you implement a canary deployment using an L7 LB?

Связанные уроки

• alg-20-greedy