L4 – L7 Load Balancing – Netwerk

Sharing is caring

This entry is part 3 of 3 in the series F5 Local Traffic Manager (LTM)

F5 Local Traffic Manager (LTM)

Table of Contents

Load Balancers

Despite the name, a Load Balancer does not only balance the load: some of its core functionalities are:

Load Balancing: of course, it has a way to determine which server will handle a specific request;
Service Discovery: to understand where to redirect requests, a Load Balancer need to keep track of the available resources and their addresses;
Abstraction: clients will not know the real address of the destination servers: they will only know the address of the Load Balancer;
Health Checking: a destination server must not only exist, but it must also be in a healthy state. Unhealthy servers are excluded from the possible destination servers.

L4 to L7 Network Services Definition

L4-L7 Network Services Definition are a set of functions such as: load balancing, web application firewalls, service discovery, and monitoring for network layers within the Open Systems Interconnection (OSI) model. The OSI model is a standard for telecommunications and computing systems. Within this communication system there are partitions called abstraction layers. Layers 4 to 7 (L4-L7) are delineated by function:

L4 – the Transport Layer is for transmission of data between points on a network. Example protocols: TCP/UDP.

L5 – the Session Layer is for managing the dialogues between computers. L5 establishes and manages connections between applications.

L6 – the Presentation Layer is responsible for establishing context within the applications, in which different syntax and semantics are present. This layer provides mapping and communication to various applications. Example protocols: SSL/TLS.

L7- the Application Layer is nearest to the end user. The user and the application are directly interacting, communicating with both. Example protocols: HTTP/SIP.

Difference between L4 and L7 Load Balancing

L4 load balancing offers traffic management of transactions at the network protocol layer (TCP/UDP). L4 load balancing delivers traffic with limited network information with a load balancing algorithm (i.e. round-robin) and by calculating the best server based on fewest connections and fastest server response times.

L7 load balancing works at the highest level of the OSI model. L7 bases its routing decisions on various characteristics of the HTTP/HTTPS header, the content of the message, the URL type, and information in cookies.

Layer4 Load Balancing (connection/session load balancing)

L4 as the name suggests works on Layer4 (and Layer3) of the OSI model. When a client makes a request, it creates a TCP connection with the load balancer. The Load Balancer then uses the same TCP connection that the client created with it, to connect with one of the upstream servers.

There is another type of L4 load balancer known as TCP/UDP termination load balancers where there are two different TCP connections.

L4 load balancers are unaware of the data. This means they cannot make any decisions based on data in our request. The data could be HTTP, Redis, MongoDB, or any other application protocol. They have only the IPs (source and destination) and ports information.Thus the load balancer roughly shuffles bytes back and forth, and makes sure that bytes from the same session wind up at the same backend.

With L4 load balancers, load balancing multiplexing (HTTP/2 streams), keepalive protocol is an issue. (Multiplexing is sending concurrent application requests over a single L4 connection, and kept-alive means not closing the connection when there are no active requests). Consider a case where two clients C1 and C2 make a request to a load balancer with two upstream servers S1 and S2 (assume both are keepalive connections). Let’s say C1 is connected to server S1 and C2 is connected to the server S2. If C1 makes 1 requests per second and C2 makes 50 requests per second then S2 is handling 50x more requests than server S1 which actually defeats the purpose of load balancing.

All modern protocols are evolving to be both multiplexing and kept-alive for efficiency reasons (it is generally expensive to create connections, especially when the connections are encrypted using TLS), so the L4 load balancer impedance mismatch is becoming more pronounced over time. This problem is fixed by the L7 load balancer.

L7 Load Balancing (application load balancing)

The below diagram shows an L7 HTTP/2 load balancer. In this case, the client makes a single HTTP/2 TCP connection to the load balancer. The load balancer then proceeds to make two backend connections. When the client sends two HTTP/2 streams to the load balancer, stream 1 is sent to S1 while stream 2 is sent to S2. Thus, even multiplexing clients that have vastly different request loads will be balanced efficiently across the backends. This is why L7 load balancing is so important for modern protocols.

Summary

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:

Routing: since it knows the full URL, it can redirect the request to a specific server. For instance, if the path is /images/avatar.png, the Load Balancer can send the request to a server dedicated to images;
SSL Termination: encryption and decryption are resource-expensive operations. You can free up some resources on the destination servers by delegating encryption and decryption to the Load Balancer, making your applications able to handle more requests (because they no longer need to encrypt and decrypt data);
Authentication: given that an L7 Load Balancer has access to all the metadata related to a request, such as HTTP Headers, it can work as an authentication layer that returns 401 – Unauthorized in case, for example, a specific HTTP Header is missing;
Observability: an L7 Load Balancer can be used to apply observability to a resource, by tracing the incoming requests, the response time, and more;
Security: an L7 Load Balancer can protect your application from DDoS attacks ;

Examples,

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, but still, has some advantages:

Since it works at the transport layer, and does not perform any check on the request payload, it’s way faster than an L7 Load balancer;
It’s unaware of the type of data it is receiving: bytes can come from an HTTP request as well as from a MongoDB connection;
Can choose the destination server based on the IP address;