--- title: "L4 vs L7: twelve lines of nginx or a suitcase of ASICs" description: "Traffic is climbing, the servers are wheezing, and one overworked proxy is terminating millions of TCP connections on pure CPU. A field guide to the load balancing split: what layer 4 and layer 7 actually see, why conntrack betrays you, when Direct Server Return saves the network, how far a single nginx really goes, and what the cloud menu renames." slug: l4-vs-l7 status: published published_at: 2024-11-12 author: Arman Obosyan author_url: https://sugra.systems/about section: general primary_keyword: l4 vs l7 load balancer nginx dsr ebpf xdp hero_image: /blog/images/posts/l4-vs-l7-hero.jpg hero_alt: "Start at twelve lines, climb only when it hurts: an escalation ladder from a single nginx box through nginx pairs with keepalived and kernel IPVS or XDP up to an amber hardware ASIC suitcase." og_image: /blog/images/posts/l4-vs-l7-hero.jpg tags: - engineering - networking - infrastructure - reliability --- Traffic is through the ceiling, the backends are wheezing, and one overworked proxy is terminating millions of TCP connections while its CPU burns. Someone in the meeting says "we need a real load balancer," and someone else asks the only question that matters: real how? Smart, or fast? That is the entire L4 versus L7 split, and it fits in one sentence. A layer 4 balancer forwards conversations it never reads. A layer 7 balancer joins every conversation it forwards. ## L4: brute force, and the ways around the kernel A transport-layer balancer - IPVS, HAProxy in TCP mode - looks at IP addresses and ports, and nothing else. No TLS handshake, no HTTP parsing, no opinion about your JSON. Its job is moving packets, and its budget per packet is measured in microseconds. The classic software version leans on the kernel's connection tracking, and that is where it betrays you. Under a DDoS burst - or a perfectly legitimate flood of short-lived connections - the conntrack table fills in seconds, and the kernel starts printing the most honest log line in networking: table full, dropping packet. You tune the limits, you tune them again, and when tuning stops helping, the enterprise answer has traditionally been hardware: the appliance from the F5 and A10 class, ASICs in a box, session handling in silicon. The suitcase. The modern escape hatch skips both the table and the suitcase: eBPF and XDP process packets before the kernel's heavy networking stack ever touches them. Meta's Katran - open-sourced in 2018 and carrying facebook.com's frontend traffic - is the reference implementation of the idea: a software L4 at hardware-adjacent speed, on commodity servers. L4's killer feature deserves its own paragraph: Direct Server Return. The balancer rewrites the destination MAC address (or wraps the packet in IPIP), the backend receives it - and replies to the client directly, bypassing the balancer entirely. For asymmetric traffic - a 1 KB request pulling a 100 MB response, streaming, heavy static - DSR means the balancer carries the trickle in and none of the flood out. The return path simply is not its problem. ## L7: intelligence, billed in CPU cycles An application-layer proxy - nginx, Envoy, Traefik - terminates the TCP connection on itself, decrypts TLS, parses HTTP or gRPC, makes a routing decision, and opens a second connection to the backend. Every request is read, understood, and rewritten. The bill arrives in three lines. First, copies: bytes crossing from kernel space to user space and back, per request, forever. Second, cryptography: TLS termination at hundreds of thousands of requests per second brings serious hardware to its knees and starts conversations about crypto offload. Third, the event loop: epoll-style architectures are magnificent until something blocks - one slow disk write, one overloaded worker - and the tail latency spikes while p99 leaves the atmosphere. In exchange you get total control of the request: route by header, retry idempotent calls, rate-limit by API key, pin canary users to canary backends, terminate one TLS session and open another. Every feature your platform team wants lives at L7, which is exactly why L7 is where CPU goes to die. ![A fourteen-row comparison of kernel L4, nginx, and full L7 proxies: what each sees, protocols, TLS handling, client IP, work per hit, latency, ceilings, algorithms, health checks, stickiness, superpowers, config style, cloud equivalents, and what each dies from](/blog/images/posts/l4-vs-l7/the-split.jpg) *The split, with nginx where it actually sits: one binary in the middle - http is the L7, stream is the budget L4.* ## How far one nginx goes Here is the part the architecture diagrams undersell: a single nginx is a complete L7 load balancer in about twelve lines - an upstream block, a server block, a proxy_pass, and change. One modest VM proxies thousands of requests per second without drama; a fat one carries tens of thousands. The same binary does budget L4 through the stream module - plain TCP and UDP proxying, TLS passthrough included - which covers databases, message brokers, and anything else that speaks bytes rather than HTTP. That is why the honest escalation ladder starts here, and why each rung has a named exit ramp rather than a vibe: One nginx, until the box itself is the risk. Two nginx behind a keepalived VIP, until TLS eats the CPU or you need real horizontal scale. A kernel L4 tier - IPVS, or XDP if you have the appetite - spreading across a pool of L7 proxies, with BGP and ECMP splitting traffic at the edge; this is the shape of most serious bare-metal frontends. And hardware, last, when raw packets per second is genuinely the problem and nothing programmable keeps up. Climbing early buys complexity without buying relief. ## The cloud menu The cloud did not repeal the split; it renamed it and attached a billing meter. On AWS the L4 is NLB and the L7 is ALB. On Azure: Load Balancer versus Application Gateway, with Front Door as the global L7 edge. Google runs its global anycast frontends on the lineage of Maglev, its software L4 - the paper is in the reading list and is the best description of hyperscale L4 design in print. Two honest notes about the managed versions. You gain instant scale, health checks, and zero patching; you lose the sharpest tools - DSR effectively does not exist behind a cloud LB, source-IP preservation comes with per-product asterisks, and the per-LCU pricing has surprised more than one team fronting high-throughput streaming with an L7 product when an L4 one cost a fraction. And the reverse case stands too: on bare metal, at serious egress volume, a BGP-and-ECMP edge feeding your own L4 tier is still the cheapest bandwidth money can buy. ## The verdict Choose L4 - kernel, eBPF, or hardware - when the problem is raw throughput and packets per second rather than routing logic; when traffic is extremely asymmetric and DSR keeps the response flood off the balancer; when you are building the bare-metal edge itself; or when compliance demands end-to-end TLS with no man in the middle. Stay at L7 - nginx, Envoy - when the platform needs application-aware behavior: routing by header for canaries, rate limits per API key, circuit breakers, sticky sessions; when you run a service mesh multiplexing gRPC over HTTP/2; or when one gateway must own authentication, request normalization, and the WAF. And if neither list is obviously yours yet - you are on rung one of the ladder, and rung one is twelve lines long. ## Reading - [Load Balancing at the Frontend](https://sre.google/sre-book/load-balancing-frontend/) - Google SRE Book, chapter 19 (chapter 20 continues into the datacenter) - NGINX Cookbook, 3rd edition - Derek DeJonghe, O'Reilly, 2024: the practical recipe book for everything above rung one - Learning eBPF - Liz Rice, O'Reilly, 2023: the technology behind the XDP escape hatch - [Open-sourcing Katran, a scalable network load balancer](https://engineering.fb.com/2018/05/22/open-source/open-sourcing-katran-a-scalable-network-load-balancer/) - Meta Engineering, 2018 - [Maglev: A Fast and Reliable Software Network Load Balancer](https://www.usenix.org/conference/nsdi16/technical-sessions/presentation/eisenbud) - Google, NSDI 2016 - [Load Balancing is Impossible](https://www.youtube.com/watch?v=kpvbOzHUakA) - Tyler McMullen, 2016