Load Balancing Layer 4 and Layer 7

Layer 4 Load Balancer Benefits & Methods

Layer 4 load balancing works at the Transport layer of the network (see diagram above). It operates via the UDP, TCP, and SCTP protocols. When we say it operates at layer 4, what we mean is that the load balancer reads information such as the source and destination IP addresses from the network packets flowing from clients to servers. Additionally, the IP Port in the destination IP address is used to route connections to the appropriate services on servers.

Layer 4 (L4) load balancing uses several techniques to route network traffic.

Direct Routing

In Direct Routing (DR), the Free LoadMaster L4 load balancer receives incoming client requests and forwards them to the selected server using the target server's actual IP address. However, the client's network address is included in the information so that the server can respond directly to the client, bypassing the load balancer for the return traffic.

Direct routing is useful in situations where the data in the server response is much larger than the incoming request. Examples of this include video streaming and file download services. Other benefits of L4 load balancing DR include:

• Reduction of the load on the load balancer as only incoming traffic has to be processed.
• Improved response times as outflowing traffic goes directly to the clients and doesn't pass through the load balancer.
• Increases the overall throughput capacity of the Free LoadMaster load balancing system, meaning organizations can run it using fewer computing resources.
• Simplified network configuration as servers use their real IP addresses. However, this does mean that careful network configuration is required.

Note that to use DR, the backend server and the L4 load balancer must be on the same network subnet. This is not a general restriction of L4 load balancing, as shown by the following method.

Network Address Translation (NAT)

When using NAT load balancing, an L4 load balancer receives incoming client requests and changes the destination IP address from its own Virtual IP (VIP) to the IP address of the selected server. For outward traffic, the L4 load balancer changes the source IP address from the server's IP back to its own IP before sending the response to the client. This enables the use of private IP addresses for backend servers, which boosts cybersecurity by minimizing the attack surface visible to attackers. Other benefits of L4 load balancing NAT are:

• Simplifies client-side routing as clients only need to know the VIP of the load balancer and not the actual IP addresses of any application servers.
• Simplifies network design and configuration for backend server pools and the infrastructure needed to support them.
• Supports servers on different subnets, making it easier to logically (and physically) separate servers based on ways that make sense for each organization.

As the L4 load balancer needs to manipulate IP addresses in the network packets flowing in and out, there will be a higher load on the free LoadMaster instances. This can cause latency in some edge cases if free LoadMaster is being used to manage high-traffic websites.

System admins often use NAT load balancing due to its flexibility and security benefits. It's particularly useful in scenarios where you want to hide your server infrastructure from external networks or when you have servers distributed across different subnets. The NAT support in free LoadMaster makes it ideal for use in DevSecOps workflows to test application functionality and deployment workflows before rolling out changes to Production infrastructure that is load balanced with commercial LoadMaster.

Source Network Address Translation (SNAT)

In SNAT load balancing, the load balancer modifies the source IP address of incoming packets before forwarding them to the backend servers. Specifically, it replaces the client IP address with the load balancer's IP address. When the server responds, it sends the traffic back to the load balancer, which then translates the IP address back to the client's original IP and forwards the response. SNAT benefits are:

• Enables backend servers to route return traffic to clients even when they don't have a default route back to the internet. This boosts security.
• Enables load balancing in complex network topologies where servers don't have direct return paths to clients.
• Provides an additional layer of security by hiding client IP addresses from backend servers. However, this may interfere with any processes that need to log client IP addresses for any reason.

SNAT has a slightly higher latency for connections, as both inbound and outbound traffic get processed, and the load balancer must maintain state information for every active client connection.

Layer 7 Load Balancer Benefits & Methods

Layer 7 load balancers operate at the top layers of the TCP/IP and OSI models (see diagram above), and they deliver more intelligent and granular traffic distribution than layer 4 load balancing. Layer 7 load balancers can inspect the content of the traffic, including HTTP & HTTPS headers, destination URLs, cookies, and even data within the network packets. These broader and deeper inspection techniques enable Layer 7 load balancers, such as free LoadMaster, to make routing decisions based on more granular information.

Layer 7 (L7) load balancers are ideal for complex applications where advanced traffic management is required, such as content-based routing, security filtering, and session persistence. L7 load balancing uses several methods that are distinct from those used by L4 load balancers.

Content-Based Routing

When doing content-based routing, the L7 load balancer examines specific elements of the application-layer traffic, such as the URL, headers, or cookies. Then, it routes requests to different backend servers based on this information. For example, requests for various types of content (e.g., images, videos, or text) can get routed to different servers optimized for handling those specific types of data. Free LoadMaster has the same functionality as the full commercial release of LoadMaster and fully supports L7 load balancing. Indeed, Free LoadMaster runs on the same codebase as the commercial offerings.

Benefits of content-based routing include:

• By routing traffic based on content, specialized servers can handle specific tasks, improving performance and resource efficiency.
• Delivers faster load times for specific types of content due to the ability to direct requests to the most appropriate server.
• Support for multi-tenant deployments as multiple applications can coexist on the same infrastructure with content-based routing, delivering requests to the correct application.

URL-Based Routing

URL-based routing enables an L7 load balancer to analyze the URL path or query parameters of incoming requests and route them appropriately. For example, routing requests with a URL for a directory of images to a server optimized for handling image files. Or requests for API access to a service can be routed to a dedicated API server.

The benefit of having URL-based routing, especially in a solution such as free LoadMaster, is that it enables IT teams to set up DevSecOps workflows and other development and support workflows tailored specifically for the teams using them, or they can mirror pipelines to production for advanced QAT before live deployments. Other benefits are:

• Highly targeted and specific URL paths can be used to send requests to specialized servers that have the best infrastructure to deal with the request.
• URL-based routing is especially useful when used in microservices deployments where different URL paths represent different services that need to be handled by different server pools.
• URL-based routing allows for additional security policies, such as only allowing specific URL paths to reach sensitive services.
• It makes it easier to scale applications as you know exactly what the load is for each server.

Cookie-Based Routing

In Cookie-Based Routing, the L7 load balancer uses information stored in HTTP cookies to make routing decisions. The load balancer can do this in two ways:

Application-generated cookies - The application sets specific cookies that the load balancer then uses to route requests.

Load balancer-generated cookies - The load balancer generates a cookie during the client's first request and then uses this cookie for subsequent routing decisions.

The cookies typically contain information about which server the client should be routed to, either directly (by containing a server identifier) or indirectly (by containing a hash that the load balancer can map to a server). Cookie-based routing is core to many forms of session persistence that enable client-server connections to persist over multiple sessions. Useful for shopping carts and other applications that need to maintain user's actions between sessions. Other benefits of cookie-based routing include:

• Enables session persistence without relying on client IP address, which can change as users switch between devices.
• Supports complex use cases like gradual rollouts of new application versions to specific user groups over time.
• Can be used to implement A/B testing or limited test releases to production by routing specific users to different application versions.
• Deliver session persistence for a broad range of application types.

A separate section below has more on persistence methods.

Header-Based Routing

In header-based routing, the L7 load balancer examines the HTTP headers of the incoming requests and directs the traffic based on those headers. This could include routing based on user-agent strings to differentiate between mobile and desktop devices. Header-based routing is instrumental in delivering TLS/SSL handling and routing on load balancers, including Free LoadMaster. The benefits of header-based routing include:

• Allows for routing based on device type, enabling optimized application responses for mobile vs. desktop traffic.
• By inspecting cookies or session tokens in the headers, the L7 load balancer can direct a user's subsequent requests to the same backend server they were using before. This delivers sticky sessions between connections and allows the user to return to the point they were at before their last connection ended.
• IT teams can use this method for A/B testing by directing traffic to different servers or different service versions based on the information in the headers.

TLS/SSL Termination & Re-Encryption

We mentioned TLS/SSL handling and routing in the previous subsection. Layer 7 load balancing can take over the processing of TLS/SSL activities within an application delivery infrastructure. The load balancer can terminate TLS/SSL (HTTPS) connections and decrypt the incoming traffic before sending it to backend application servers. L7 load balancers such as Free LoadMaster can also encrypt traffic again before sending it to the servers so that it is secure when flowing over the network at all times. This is desirable even if you control the network in a private data center. The benefits of doing TLS/SSL on a L7 load balancer are:

• Reduce the processing load on backend application servers by offloading the TLS/SSL decryption process to the L7 load balancer, allowing the backend servers to dedicate resources to application tasks.
• The L7 load balancer can open encrypted traffic packets and look for security threats before they reach the application servers, helping with security.
• Simplify TLS/SSL certificate management by centralizing it on the L7 load balancers. This makes it easier to renew and update certificates across the whole estate.

Host-Based Routing

Host-based routing directs traffic based on the host or domain name in the HTTP request header. For example, traffic for www.mysite.com could be routed to one set of servers, while the load balancer can route traffic for api.mysite.com to a different set of servers. The benefits of this include:

• Enables support for multiple domains or subdomains within the same infrastructure, directing traffic to different server pools based on the subdomain in the fully qualified domain name. For example: www, api, docs, and more.
• Enables organizations to manage different services or websites with the same load balancing infrastructure but with separate backend servers.

Layer 7 Persistence Methods

The previous sections mention session persistence a few times. Here, we will list all the ways that an L7 load balancer can deliver session persistence.

Server Cookie Persistence

Server Cookie persistence uses server-generated cookies to control which servers the L7 load balancer directs user session requests. This method is sometimes referred to as "passive cookie", as the load balancer simply observes the cookie in the HTTP stream.

Active Cookie Persistence

The Active Cookie method is an L7 load balancer feature that uses cookies generated by the load balancer, not the server. When a connection is established, the load balancer looks for an active cookie, and if that cookie is not there, it inserts one into the HTTP stream. This does not interfere with existing server and application cookies.

Server Cookie With Source IP Persistence

If expected server cookies aren't available (e.g., if a user's browser refuses cookies), then an L7 load balancer can use the source IP address to deliver persistence.

Active Cookie with Source IP Persistence

Similar to the above, but in the case when it is an active cookie that is missing, the L7 load balancer can revert to using the source IP address to deliver persistence.

Hash All Cookies Persistence

The 'Hash All Cookies' method creates a hash of all cookies in the HTTP stream. The load balancer uses this calculated hash number to uniquely identify client connections and maintain persistence across sessions.

Hash All Cookies with Source IP Persistence

Hash All Cookies with Source IP is similar to Hash All Cookies, with the additional feature that the L7 load balancer will fall back to Source IP persistence in the event that no cookies are in the HTTP stream.

Source IP Address Persistence with L7 Load Balancer

Source IP Address with L7 Load Balancer uses the source IP address of the client request to uniquely identify users. This is the simplest method of persistence and works for all TCP protocols, including those that are not HTTP related. Source IP address persistence can fail if multiple clients connect from the same IP address, as is the case when multiple remote clients are behind a NAT device.

Super HTTP

Super HTTP is the recommended method for achieving persistence for HTTP and HTTPS services with Free LoadMaster load balancers (and all other LoadMaster versions). It creates a fingerprint based on the combined values of the User-Agent field and, if present, the Authorization header to create a unique identifier that the L7 load balancer uses to persist sessions across connections.

Layer 7 vs Layer 4: Which do you need?

In the modern application landscape, you need load balancers that are top-notch at delivering both Layer 4 and layer 7 load balancing. Free LoadMaster provides full support for both, so you can deploy it in ways that suit your specific needs.

If you need to route network packets as quickly as possible between clients and servers, then use the L4 load balancing functionality included with Free LoadMaster.

However, if your requirements are more complex, as they probably will be if you are using Free LoadMaster in DevSecOps workflows, then you have access to the L7 load balancing functionality that all LoadMaster versions provide.

In reality, you will likely use both L4 and L7 load balancing functionality with different servers and services for which you are using Free LoadMaster to manage traffic flows.

How can Free LoadMaster Help You?

As Free LoadMaster is a full member of the LoadMaster family of products, almost everything true for LoadMaster also applies to Free LoadMaster. The almost in the previous sentence highlights that there are some restrictions applied. The restrictions do not change the code in Free LoadMaster or how you configure it. Instead, they target specific capabilities and functionality that are more applicable to larger deployments requiring a commercial license.

The restrictions on Free LoadMaster are:

• A limit of 20Mbps on Application Layer 7 traffic
• Restricted to 50 TLS (SSL) TPS License (2K Keys)
• You cannot configure Free LoadMaster in a High-Availability (HA) pair
• Multi-node clustering is not available
• There is no access to the commercial rules for the Web Application Firewall (However, you can create all the rules you need)
• Each Free LoadMaster installation must communicate with the LoadMaster Licensing Servers every 30 days
• Support for Free LoadMaster is community-based

Note that when a commercial license for LoadMaster is purchased and applied to a Free LoadMaster install, it removes these restrictions. There is no need to remove your Free LoadMaster deployment and reconfigure a new commercial LoadMaster instance from scratch.

Free LoadMaster is an excellent choice for DevSecOps workflows, or where you want to mirror production environments that have LoadMaster instances installed. It's also a great choice for non-revenue-generating and low-traffic websites. It's also great for hobbyists and home power users who want to control access to devices and services that are running from home. Which many people now do - Plex servers, for example. See this 43-minute video that covers deploying Free LoadMaster at home.

What is Layer 4 Definition?

Layer 4, also known as the Transport Layer in the OSI model and in the TCP/IP network stack, enables the network services needed for communication between devices over a network. Layer 4 delivers connection-oriented communication, reliability checking, flow control, and error checking.

The two main protocols operating at this layer are TCP and UDP. TCP tracks network packet delivery status to provide reliable delivery of data packets, while UDP doesn't check delivery status but offers faster communication.

Layer 4 uses port numbers to distinguish between different services and applications that are running on the same IT system. Load balancers operating at L4 make routing decisions based on IP addresses and port numbers without inspecting the content of the packets.

What Does Layer 7 Mean?

Layer 7, known as the Application Layer, is the highest in the OSI model. In the TCP/IP network stack, the TCP/IP Application layer maps to the topmost three layers of the OSI model (Session layer 5, Presentation layer 6, and Application layer 7). See the diagram above.

Application layer software agents directly interact with software applications and provide network services to them. Application-specific protocols such as HTTP, HTTPS, SMTP, IMAP, FTP, NNTP, and DNS operate at the Application layer.

L7 is responsible for functions like data formatting, encryption, and user authentication. Layer 7 enables end-user processes and applications to access network services.

In the context of load balancing, Layer 7 load balancers can make routing decisions based on the content of the request, such as URL paths, HTTP headers, or cookies, allowing for more sophisticated traffic management and application-aware distribution of requests.

What is Layer 4 Load Balancing Used for?

Infrastructure deployments mainly use Layer 4 load balancing when rapid routing of network packets is required. Working at the Transport layer, L4 load balancers can rapidly route requests and packets using IT addresses and ports. L4 load balancers use one of the routing techniques described previously: Direct Routing, NAT, or SNAT.

What is Layer 7 Load Balancing Used for?

The primary use case for L7 load balancing is for applications where advanced traffic management is required, such as content-based routing, security filtering, and session persistence. L7 load balancing gets used for a number of purposes in modern application delivery, such as Intelligent Traffic Distribution, Microservices Support, TLS/SSL Termination, Content-Based Routing, Application-Aware Health Checks, Web Application Firewall (WAF) Integration, Session Persistence, Rate Limiting and DDoS Protection, Content Optimization and for API Gateway Functionality.

By operating at the application layer, load balancers provide a high degree of control and flexibility when managing network traffic and client requests. They enhance application performance, security, and scalability.

What Architectures to Use with Layer 4 Load Balancers?

Layer 4 load balancing typically uses a deployment architecture that employs Direct Routing between clients and the backend server, Network Address Translation (NAT) where clients talk to the load balancer and it changes the IP address in the packets to redirect them to a suitable server, or Source Network Address Translation (SNAT) where the load balancer changes the return address to its own so that responses from the backend server flow to the load balancer, which then sends them back to the clients.

The architecture and method used will depend on what the goal of the load balancing is. See the previous Layer 4 Load Balancer Benefits & Methods section of this page for more details.

What Architectures to Use with Layer 4 Load Balancers?

Layer 7 load balancing typically uses a deployment architecture that employs one of the following load balancing methods - Content-Based Routing, URL-Based Routing, Cookie-Based Routing, Header-Based Routing, TLS/SSL Termination & Re-Encryption, or Host-Based Routing.

The architecture and method used will depend on what the goal of the load balancing is. See the previous Layer 7 Load Balancer Benefits & Methods section of this page for more details.

Is TLS layer 4 or 7?

TLS (and the older SSL) primarily functions at Layer 6 (Presentation Layer) and Layer 7 (Application Layer) of the OSI model. It handles data encryption, integrity, and authentication, which are typically associated with these upper layers.

However, TLS also interacts with Layer 4 (Transport Layer) because it relies on TCP for reliable data transmission. The TLS handshake process occurs after the establishment of the TCP connection.

Is TCP a layer 4?

TCP is a connection protocol that establishes connections between network nodes. It operates at the Transport layer and is a layer 4 protocol in the OSM model. It is also in the Transport layer in the TCP/IP stack.

Is nginx a layer 4?

Yes, nginx provides L4 load balancing.

Is HTTP/HTTPS layer 4?

No. HTTP and HTTPS are application layer protocols that operate at layer 7 in the OSI model. However, HTTP and HTTPS rely on Layer 4 TCP connections to operate.

Is TCP layer 3 or 4?

TCP operates at Layer 4 in the OSI model, the Transport Layer. It is also in the Transport layer on the TCP/IP network stack.