Layer 4 vs Layer 7 Load Balancing: What Each Layer Sees

01 /What a Layer 4 balancer sees

A Layer 4 balancer works on the transport header: source and destination IP address, protocol number, source and destination port, and TCP flags. It sees the SYN, picks a real server, records the flow and forwards every subsequent packet of that connection by table lookup. It never assembles the byte stream and never knows what the payload is. That is its strength: it balances anything over TCP or UDP, at line rate, with one decision per connection. The basic model is described under server load balancing.

02 /What a Layer 7 balancer sees

A Layer 7 balancer completes the TCP handshake itself, receives the request, parses it and only then chooses a real server, to which it opens a second connection. Because it holds the full request it can route on the Host header, the URL path, a query parameter, a cookie, the method or the content type. It can rewrite headers, insert its own, redirect, compress, cache and apply persistence based on cookies. It is a proxy; every byte in both directions passes through its HTTP engine.

03 /URL switching and content switching

Content switching sends different parts of one site to different pools from one VIP: /images/ to static servers, /api/ to application servers, /admin/ to a restricted pool, with the Host header separating tenants that share the address. Foundry published a URL switching application note around 2001 and grouped the ServerIron GT, 4G and XL under an "application switch" product category, a label that meant Layer 7 aware load balancing in hardware. A whitepaper on balancing Microsoft Office Communications Server 2007 front-end pools belonged to the same family: the balancer had to understand the protocol well enough to keep a signalling session on one server.

04 /TLS termination and its cost

To read HTTP inside HTTPS the balancer must hold the certificate and private key and terminate TLS. That concentrates key management (convenient) and asymmetric cryptography (expensive) in one place. The full handshake dominates: a new TLS session costs orders of magnitude more CPU than forwarding a Layer 4 flow, which is why appliance vendors sold hardware acceleration and why balancer datasheets quote TLS handshakes per second separately from plain connections per second. Session resumption spreads the cost. Traffic to the real servers can be plain HTTP or re-encrypted, which doubles the crypto work.

05 /Performance and latency

Layer 4 adds microseconds: one table lookup and a header rewrite per packet, often in switching silicon. Layer 7 adds a full proxy hop: TCP handshake with the client, request parse, second handshake to the server, then two buffered streams. Expect connections per second to drop by an order of magnitude when a device moves from Layer 4 to Layer 7, and added latency in the low milliseconds per request. Neither matters until the balancer, not the servers, is the bottleneck.

06 /Header insertion: X-Forwarded-For and friends

In NAT or proxy mode the real server sees the balancer as the client, so logs, rate limits and geolocation all break. A Layer 7 balancer fixes this by inserting X-Forwarded-For with the original client address, X-Forwarded-Proto with the original scheme, or the standard Forwarded header (RFC 7239). Servers must trust these headers only from the balancer address and strip any copy a client sent, or the client can forge its own source. Layer 4 balancers cannot insert headers; they preserve the client address instead, which is why direct server return and Layer 4 are often chosen together.

07 /Decision table

The same logic applies one level down, where a Layer 2 versus Layer 3 switch trades simplicity for routing awareness: the higher layer is chosen for what it sees and paid for in throughput.