If you need to handle lots of incoming requests, you should manage the incoming traffic by balancing the load across different servers. You should consider adding a Load Balancer: it’s a layer of abstraction that handles requests, availability, and security in a centralized place.
When handling a massive amount of requests, a system generally needs to balance the incoming load to avoid overloading a single server. To do that, we typically use a Load Balancer in front of our applications to handle all the incoming traffic.
In this article, we will learn what a Load Balancer is and what problems it solves, and we will delve into the main categories of Load Balancing: L7 and L4.
A Load Balancer is a piece of the network architecture that deals with incoming requests and, through a specific process, forwards each request to a specific node of the “internal” architecture.
It can be a distinct piece of hardware, as well as a software component already part of the network architecture.
Despite the name, a Load Balancer does not only balance the load; some of its core functionalities are:
Health checking is one of the vital parts of a Load Balancer, and how to handle unhealthy services is a complex topic.
Suppose you have two servers, Server1 and Server2 that can handle 50 requests per second each. Suddenly, Server1 becomes unhealthy, and the Load Balancer removes it from the list of available servers. The same 100 users keep accessing the service, but now, since Server1 is unavailable, Server2 will have to handle 100 requests/sec. If it’s not able to handle that spike, the whole application will be offline, and none of the users will be able to access the system. So, just moving all the traffic to a single instance should be avoided, and you must think of a more complex mechanism.
Depending on the type of Load Balancer (L4 vs L7), you can also have more functionalities, such as Authentication and Observability.
Before moving to L4 and L7, we need to have a look at the OSI model.
The OSI Model is the definition of the abstractions used in networking. It’s composed of 7 different layers (L1 to L7), each with its specific responsibilities, protocols, and behaviors.
When a client tries to access a host, every request passes through all seven layers. A Load Balancer that works on a specific layer can perform different operations because it “knows” different metadata of the same connection.
An L7 Load Balancer acts on the Application layer. Since it works at this layer, the Load Balancer can balance requests based on the whole payload of the request.
For instance, an L7 Load Balancer can handle:
You can find a lot of Load Balancers that work at the Application layer, such as:
An L4 Load Balancer acts at the TCP/UDP level: it does not have access to the request Body or its HTTP Headers, so it cannot perform smart decisions based on the actual content of the request.
Even though it’s not as smart as an L7 Load Balancer, it still has some advantages:
As you can imagine, many teams prefer an L7 Load Balancer over an L4 Load Balancer.
However, you can find some good L4 Load Balancers on the web:
We’ve just scratched the surface of the topic.
For sure, to understand better the differences between L7 and L4, have a look at the definition and the structure of the OSI Model:
Then, an amazing article about all the possible functionalities of a Load Balancer, as well as the different types (Edge, Sidecar, Middle):
🔗 Introduction to modern network load balancing and proxying | Matt Klein
This article first appeared on Code4IT 🐧
Finally, a short but valuable article about L4 and L7 Load Balancers, with a demo created using Docker and Envoy:
🔗 L4 vs L7 Load Balancing | Mohak Puri
In this article, we’ve learned how L7 and L4 Load Balancers differ, and what are the functionalities provided by both types.
Here’s a short table to sum up the differences.
L4 Load Balancing |
L7 Load Balancing |
---|---|
Works at the transport layer |
Works at the application layer |
Uses TCP and UDP protocols |
Uses HTTP and SMTP protocols |
Makes routing decisions based on simple algorithms and network information such as ports and protocols |
Makes routing decisions based on content information such as headers, message content, URL type, and cookie data |
Does not inspect or decrypt messages |
Terminates, inspects, and decrypts messages |
Fast, efficient, and secure |
Complex, informed, and application-aware |
Deals with individual connection flows |
Deals with individual requests |
Cannot do smart load balancing or content optimization based on the media type, localization rules, etc. |
Can do smart load balancing and content optimization based on the media type, localization rules, etc. |
I hope you enjoyed this article! Let’s keep in touch on Twitter or LinkedIn! 🤜🤛
Happy coding!
🐧
Also published here.