Load balancing software runs at L4 (TCP/UDP) or L7 (HTTP). The right one depends on the workload. L4 for raw TCP, where the load balancer does not look at the HTTP content. L7 for HTTP-based routing, where the load balancer can route by URL path, host header, or cookie.
Table of contents
L4 vs L7
L4 load balancing operates at the transport layer. The load balancer does not look at the HTTP content; it just forwards the TCP packets to the target. L4 is the fastest, the simplest, and the most transparent. The trade-off: the load balancer cannot route by URL path, host header, or cookie.
L7 load balancing operates at the application layer. The load balancer looks at the HTTP content; it can route by URL path, host header, or cookie. L7 is the most flexible, the most powerful, and the most common for HTTP-based workloads. The trade-off: L7 is slower than L4 (the load balancer has to parse the HTTP headers).
When to use L4
The team that should use L4:
- The team that has a raw TCP workload (a database, a queue, a custom protocol).
- The team that needs the lowest possible latency.
- The team that has a workload that does not benefit from HTTP-based routing.
- The team that has a workload that is sensitive to the load balancer’s overhead.
When to use L7
The team that should use L7:
- The team that has an HTTP-based workload (a web server, an API).
- The team that needs URL-based routing (e.g., /api/* goes to one service, /static/* goes to another).
- The team that needs host-based routing (e.g., api.example.com goes to one service, app.example.com goes to another).
- The team that needs cookie-based sticky sessions.
The features
The features comparison:
- L4: raw TCP forwarding, health checks, sticky sessions by source IP. The simplest feature set.
- L7: all the L4 features, plus URL-based routing, host-based routing, cookie-based sticky sessions, header rewriting, request rate limiting, response rate limiting, HTTP/2 support, gRPC support. The most flexible feature set.
The performance
The performance comparison:
- L4: the lowest latency. The load balancer does not parse the HTTP content, so the overhead is minimal.
- L7: higher latency. The load balancer has to parse the HTTP headers, which adds overhead. The overhead is small (microseconds), but it is non-zero.
The team that has a latency-sensitive workload should benchmark both L4 and L7 before deciding.
The decision tree
The decision tree:
- Is the workload HTTP-based? Yes -> L7. No -> L4.
- Does the workload need URL-based routing? Yes -> L7. No -> L4.
- Does the workload need host-based routing? Yes -> L7. No -> L4.
- Does the workload need cookie-based sticky sessions? Yes -> L7. No -> L4.
- Is the workload latency-sensitive (under 10ms)? Yes -> consider L4. No -> L7.
- Is the workload a database, a queue, or a custom protocol? Yes -> L4.
FAQ
What is L4 load balancing?
L4 load balancing operates at the transport layer. The load balancer does not look at the HTTP content; it just forwards the TCP packets to the target. L4 is the fastest, the simplest, and the most transparent.
What is L7 load balancing?
L7 load balancing operates at the application layer. The load balancer looks at the HTTP content; it can route by URL path, host header, or cookie. L7 is the most flexible, the most powerful, and the most common for HTTP-based workloads.
When should I use L4?
Raw TCP workloads (database, queue, custom protocol), low-latency workloads, workloads that do not benefit from HTTP-based routing, workloads that are sensitive to the load balancer’s overhead.
When should I use L7?
HTTP-based workloads (web server, API), URL-based routing, host-based routing, cookie-based sticky sessions.
What is the performance difference between L4 and L7?
L4 is the fastest. L7 adds overhead because the load balancer has to parse the HTTP headers. The overhead is small (microseconds), but it is non-zero.
Can I use both L4 and L7 in the same setup?
Yes. The common pattern: L4 load balancer in front, L7 load balancer behind it. The L4 load balancer handles the raw TCP; the L7 load balancer handles the HTTP-based routing.
If you are sizing a load-balancing tier for a new project, the RunxBuild hosting calculator is the place to model the line items. The load balancer, the SSL, the bandwidth, the targets - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual load-balancer performance in one place.