Load balancers: layer 4 versus layer 7
In short: A load balancer gives clients one address and spreads their traffic across healthy backend servers. Layer 4 balancers forward TCP or UDP connections quickly; layer 7 balancers read HTTP requests and can route by path or host, terminate TLS and apply security rules.
What a load balancer does
A load balancer presents a single virtual IP (VIP) or DNS name to clients and distributes their requests across a pool of backend servers. It improves availability, because failed servers are taken out of rotation, and scalability, because you can add servers behind the same address. It also lets you take a server out for patching without users noticing.
Layer 4 versus layer 7
A layer 4 balancer works at the transport layer of the OSI model. It sees source and destination IP addresses and ports, picks a backend and forwards the connection. It does not read the content, so it is very fast and works for any TCP or UDP protocol, such as databases, mail or game traffic.
A layer 7 balancer works at the application layer. It reads HTTP methods, hostnames, paths, headers and cookies. It can send /api to one pool and /images to another, host several sites on one IP, rewrite headers, compress responses and apply a web application firewall (WAF). It usually terminates the client connection and opens a new one to the backend.
| Need | Better choice |
|---|---|
| Non-HTTP protocols or very high throughput | Layer 4 |
| Route by URL path or hostname | Layer 7 |
| Inspect or block malicious HTTP requests | Layer 7 with WAF |
| Keep end-to-end encryption without decrypting | Layer 4 TLS passthrough |
Algorithms, health checks and persistence
- Round robin: each server in turn. Simple; weighted versions favour larger servers.
- Least connections: send to the server with fewest active connections; good for long or uneven requests.
- Hash-based: hash of client IP or a key picks the server, so the same client usually lands on the same backend.
Health checks probe each backend regularly. A TCP check only proves the port is open; an HTTP check against a page such as /health that also tests the database is much better. Session persistence (sticky sessions) keeps a user on one server, often with a cookie, but it weakens balancing and loses sessions if that server fails. Storing sessions in a shared cache is more robust.
A minimal HAProxy example of a layer 7 pool with health checks:
frontend web_in
bind *:443 ssl crt /etc/haproxy/certs/example.com.pem
default_backend web_pool
backend web_pool
balance leastconn
option httpchk GET /health
server web1 192.168.10.11:8080 check
server web2 192.168.10.12:8080 checkAvoiding a new single point of failure
The balancer itself must be redundant: a pair of appliances using VRRP to share the VIP, or a managed cloud load balancer that spans several availability zones. For global services, combine local balancers with DNS-based global load balancing.
Tip: when you terminate TLS at a layer 7 balancer, the backend sees the balancer's IP. Pass the real client IP in the X-Forwarded-For header or with the PROXY protocol so logs stay useful for security investigations.
Practice
You need to balance traffic to a cluster of SMTP servers. Layer 4 or layer 7 HTTP?
Why is an HTTP health check better than a TCP port check?
What is a drawback of sticky sessions?
Key takeaways
- Load balancers give one address and spread traffic across healthy servers.
- Layer 4 forwards connections fast for any TCP or UDP protocol.
- Layer 7 reads HTTP, routes by path or host, and can terminate TLS.
- Use meaningful health checks and avoid relying on sticky sessions.
- Make the load balancer itself redundant.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.