TCP Distribution with L4 Load Balancing for Robust Services

TL;DR

L4 Load Balancing distributes TCP connections based on transport information like IP address and port. Unlike HTTP routing, it does not evaluate URLs, headers, or content. This keeps protocol and payload unchanged, while backend pools, health checks, and failover enable robust services for databases, messaging, VPNs, or proprietary TCP applications.

Introduction

A common architectural mistake is to automatically map every external service through HTTP load balancing. For connection-oriented TCP services, this assumption is incorrect: the load balancer cannot route the application based on URL, host header, or HTTP method because these details either do not exist or are not evaluated. L4 Load Balancing therefore operates differently. It distributes connections based on network and transport information, largely keeping the application layer out of the decision-making process. This reduces protocol dependency but also limits control options. This trade-off is crucial for choosing between Layer 4 and Layer 7.

1. How L4 Load Balancing Distributes TCP Connections

In TCP distribution, a Layer-4 load balancer typically considers source and destination IP, TCP port, and connection state. A client connects to a public address and a port. The edge accepts the connection, selects a server from a backend pool based on defined distribution logic, and forwards the TCP data stream to this backend.

The application does not need to speak HTTP. The method is also suitable for protocols that build on TCP but use their own message formats. The load balancer does not need to understand their content to mediate a connection. This is a key difference from protocol-aware routing: distribution occurs at the connection level, not based on application-specific features.

In a distributed edge architecture, an Anycast address can serve as the public entry point. The connection is directed to an available edge location while the assignment to the backend occurs within the defined pool. The ayedo Edge Cloud supports Anycast-based Layer-4 and Layer-7 load balancing, providing a public, distributed entry for TCP services as well.

2. Backend Pools, States, and Connection Forwarding

Backend pools encapsulate the targets to which incoming TCP connections are distributed. They can contain multiple instances, nodes, or endpoints of a service. Health checks verify whether these targets are generally reachable and ready for service. If a backend fails, it can be removed from distribution. New connections are then forwarded to remaining targets.

It is important to distinguish between connection and request. In HTTP, a proxy can evaluate individual requests and potentially forward them differently. In TCP, however, an existing connection is assigned to a target. This assignment generally remains as long as the connection is active. A backend failure during an ongoing TCP session cannot simply be compensated by a new connection in the background. Failover primarily affects new connection setups.

Depending on the forwarding model, the backend sees either the edge or the original client as the source address. If the client identity is technically required, Proxy Protocol can transmit additional connection information, provided the backend supports this format. Backend cloaking also ensures that internal target systems do not need to be directly publicly addressed.

3. Which Characteristics Remain Compared to HTTP Routing

L4 Load Balancing does not alter the TCP data stream functionally. It does not interpret HTTP headers or URLs and does not require a specific application protocol. This preserves characteristics that can be handled differently with HTTP termination or an HTTP proxy: proprietary message formats, binary payloads, long-lived sessions, and TCP-based protocol states.

This protocol neutrality is particularly relevant when a service does not have HTTP semantics or when an additional processing layer is undesirable. At the same time, L4 cannot distinguish based on criteria like hostname, path, cookie, or API version. Two connections to the same port appear fundamentally the same from a distribution perspective, even if they use different application functions.

This shifts the responsibility for differentiated routing to the service architecture. Separate ports, own virtual addresses, or separate backend pools can partially compensate for this limitation. This is less flexible than HTTP routing but can be more transparent and stable when the application is consciously operated as a long-lived TCP service.

4. Use Cases and Operational Limits

Typical use cases include database access, message brokers, mail and directory services, VPN endpoints, game servers, and proprietary TCP applications. TLS-protected services can also be distributed on Layer 4 if the edge should not route the encrypted data stream based on application content. The decision for or against TLS termination at the edge depends on the security model, certificate management, and required protocol visibility.

For operations, connection duration, session binding, and backend capacity are especially relevant. A pool can evenly distribute many new connections and still heavily load individual backends if long-lived sessions remain there. Health checks must also meaningfully reflect the actual service state; an open TCP port does not automatically prove that the application is functional.

An edge platform like the ayedo Edge Cloud assigns these tasks before the compute infrastructure: public entry, TCP distribution, protection, and forwarding are at the edge, while the actual service runs in the chosen backend. This also applies to Kubernetes clusters outside of ayedo Managed Kubernetes.

Practical and Operational Scenario

A company operates a proprietary TCP service in two backend pools. Both pools belong to the same application but require separate maintenance cycles. Traffic is distributed over defined ports through a common public entry; each port points to the appropriate pool. Health checks remove unreachable targets from the selection.

Compared to HTTP routing, there is no way to distinguish message types within an existing connection. For planned maintenance, new connections are directed to another pool while existing sessions are allowed to terminate naturally. This operational strategy takes into account the central characteristic of TCP: once established, a connection remains bound to its target. For long sessions, failover must therefore occur at the application level or through a renewed connection setup.

FAQ

When is L4 Load Balancing a better choice than L7 routing?

When the service does not speak HTTP, the payload should remain unchanged, or long-lived TCP connections are used. L7 offers more control options but requires an evaluable application protocol.

Can L4 Load Balancing distribute individual messages within a TCP connection?

No. The assignment is for the TCP connection. Individual messages or requests within this connection are not independently distributed to different backends.

What happens in the event of a backend failure?

Health checks can remove a faulty backend from the pool for new connections. Existing TCP sessions, however, may break depending on the error pattern and usually require a renewed connection setup.

Conclusion

L4 Load Balancing is not a simplified version of HTTP routing but a different architectural decision. It preserves protocol neutrality and is suitable for TCP services where content, session state, or proprietary communication should not be interpreted at the edge. Application-specific routing options are therefore omitted. The ayedo Edge Cloud can classify such connections as a central public entrance in front of different compute environments using Anycast, backend pools, health checks, and failover.