"Layer 4 or Layer 7?" is the first question you answer when creating a Virtual IP, and it shapes everything that follows: which features are available, how much latency you add, and what your load balancer can and cannot see. The two modes are not competing products — they are different tools, and most serious deployments end up using both.
Here is what actually differs, and a straightforward way to choose.
What Layer 4 load balancing does
Layer 4 load balancing operates at the transport layer, making forwarding decisions from IP addresses and TCP or UDP port numbers alone. It never looks inside the application payload.
In Tula, L4 balancing is powered by nftlb, a high-performance engine built on the Linux nftables framework. It runs entirely within the kernel networking stack: packets matching a VIP are rewritten and forwarded to a backend without ever being copied up to a userspace process. There is no proxying — the load balancer acts as a transparent forwarding engine, and the client’s connection is preserved end to end.
Two consequences follow from that design:
- It is protocol-agnostic. Anything running over TCP or UDP can be balanced — databases, mail servers, SSH, DNS, RADIUS, SIP, game traffic — with no protocol-specific configuration.
- It is extremely cheap per packet. With no connection termination and no application parsing, latency overhead is minimal, which suits high-throughput and latency-sensitive workloads.
L4 is also the only mode that supports Direct Server Return, where responses bypass the load balancer entirely.
What Layer 7 load balancing does
Layer 7 load balancing operates at the application layer, and in Tula it is powered by HAProxy, the widely deployed reverse proxy. The architectural difference is fundamental: an L7 VIP terminates the client’s connection. HAProxy accepts the TCP (and optionally TLS) session, parses the HTTP request, evaluates routing rules, then opens a separate connection to the chosen backend and forwards the request.
Sitting in the middle of the conversation costs a little latency, but it buys the load balancer full visibility into the traffic — and that visibility is where the features live:
- Host-based routing. One VIP serving many domains, each routed to its own backend pool based on the
Hostheader —app.example.comto the application servers,api.example.comto the API fleet, all on one IP and port. - Path-based routing.
/api/*to API servers,/static/*to content servers, everything else to the main pool. Rules are evaluated in order; the first match wins. - Header manipulation. Inserting
X-Forwarded-Forso backends see the real client IP, addingX-Forwarded-Proto, setting HSTS headers, stripping or adding custom headers. - SSL/TLS termination. Decrypting HTTPS at the edge, with certificate management and Let’s Encrypt automation, then forwarding plain HTTP to backends or re-encrypting for end-to-end TLS.
- Cookie-based session persistence. Reliable client affinity that survives changing client IPs and shared NAT — something Layer 4 simply cannot do.
- HTTP-aware health checks. Verifying a specific URL returns the expected status code, rather than merely confirming a port is open.
HAProxy also maintains persistent connections to backends and reuses them across client requests, avoiding repeated TCP and TLS handshakes on the backend side — a meaningful saving at high request rates.
The decision in five questions
- Is the traffic HTTP or HTTPS, and do you need to route or modify it? Use L7. Content-aware routing, header insertion, and cookie persistence all require the proxy path.
- Do you need SSL termination with HTTP routing behind it? L7.
- Is it a non-HTTP protocol — a database, SMTP, DNS, a custom TCP service? L4.
- Is raw throughput or minimal added latency the priority, with no need to inspect content? L4. Kernel-level forwarding wins.
- Do you need Direct Server Return? L4 — it is only available there.
Side by side
| Aspect | Layer 4 (nftlb) | Layer 7 (HAProxy) |
|---|---|---|
| Decision inputs | IP address, port | Full HTTP request |
| Connection handling | Transparent forwarding | Terminates and re-proxies |
| Protocols | Any TCP/UDP | HTTP/HTTPS |
| SSL termination | No (passthrough only) | Yes |
| Content routing | No | Host- and path-based |
| Persistence | Source IP hash | Cookies (and more) |
| Health checks | TCP connect | HTTP status and content |
| DSR support | Yes | No |
| Overhead | Minimal, in-kernel | Modest, userspace proxy |
They work better together
The choice is per-VIP, not per-appliance, so a single Tula node routinely runs both engines side by side: an L7 VIP on port 443 terminating TLS for the web application, and L4 VIPs balancing the PostgreSQL replicas and SMTP relays behind it. In larger architectures an L4 VIP can even front multiple HAProxy instances to scale the proxy tier horizontally.
A common pattern for an e-commerce platform, for instance:
- L7 VIP, port 443 — TLS termination, path-based routing (
/api/*to the API pool, everything else to the storefront pool), cookie persistence for baskets, HTTP health checks against/healthz. - L4 VIP, port 5432 — Least Connections across database read replicas, TCP health checks.
- L4 VIP in DSR mode — serving large product imagery and video from a media pool, where responses vastly outweigh requests.
Each service gets the mode that matches its traffic, and none pays for features it does not use.
Getting started
Creating either kind of VIP takes a few minutes in the NetMan interface: choose the protocol (TCP/UDP for L4, HTTP/HTTPS for L7), add backends, attach health checks, and apply. The quick start guide walks through the process, and the detailed references for Layer 4 and Layer 7 cover the full option set for each mode.
The short version: inspect the traffic only if you need to. When you do, L7’s feature set is worth the proxy hop. When you don’t, let the kernel do the work.
