Layer 4 vs. Layer 7 Load Balancer: Ein praktischer Guide

Wenn deine Website oder App wächst, geht einem einzelnen Server irgendwann der Platz aus. Ein Load Balancer verteilt den Traffic auf mehrere Server, damit deine User zufrieden bleiben und nichts abstürzt. Außerdem hältst du so deine Dienste hochverfügbar, falls ein einzelner Server ausfällt. Es gibt zwei Varianten, die du kennen solltest: den Network Load Balancer (Layer 4) und den Application Load Balancer (Layer 7). Ein L4 Load Balancer kümmert sich um IP-Adressen und Ports. Ein L7 Load Balancer kümmert sich um das, was sich innerhalb der Anfrage befindet. Die beiden Varianten sind nicht immer getrennte Produkte. Einige Load Balancer, einschließlich des demnächst verfügbaren Contabo Load Balancers, können sowohl L4 als auch L7 im selben Dienst verarbeiten. Lass uns einen Blick auf die Unterschiede werfen, damit du den perfekten Modus für deine Workload auswählen kannst.

OSI-Modell Kurzerklärung: Was Layer 4 und Layer 7 bedeuten

Das OSI-Modell unterteilt das Netzwerk in sieben Schichten. Zwei davon sind hier wichtig. Layer 4 ist die Transportschicht, auf der TCP und UDP leben. Ein Paket auf dieser Schicht enthält eine Quell-IP, eine Ziel-IP, einen Quellport, einen Zielport und eine Nutzlast (Payload), die der Load Balancer niemals öffnet. Layer 7 ist die Anwendungsschicht, auf der HTTP, HTTPS, gRPC und WebSockets leben. Der Proxy liest die komplette Anfrage aus – einschließlich URL-Pfad, Host-Header, Cookies und der HTTP-Methode. Die OSI-Schicht, die du auswählst, bestimmt, wie viel der Proxy sehen darf – und genau dieser einzige Unterschied beeinflusst jeden einzelnen Kompromiss, den wir uns unten ansehen.

Was ist ein Layer 4 Load Balancer?

Ein Layer 4 Load Balancer, auch Network Load Balancer oder TCP Load Balancer genannt, verteilt den Traffic basierend auf der IP-Adresse und dem Port jeder Verbindung. Er überprüft die Nutzlast nicht. Wenn ein Client eine TCP-Verbindung öffnet, wählt der L4-Proxy über einen Balancing-Algorithmus wie Round-Robin oder Least-Connections ein Backend aus und leitet die Pakete dann direkt zwischen den Endpunkten weiter. Sticky Sessions, bei denen derselbe Client immer auf demselben Backend landet, sind ein separates Thema und werden meistens über das Hashing der Quell-IP umgesetzt, obwohl es auch andere Methoden gibt. Ein UDP Load Balancer funktioniert exakt genauso für verbindungslosen Traffic wie DNS, QUIC oder Gaming-Protokolle. Da der L4 Load Balancer die Nutzlast niemals parst, kann er extrem hohe Paketraten bei minimaler CPU-Auslastung und vorhersagbarer Latenz bewältigen. Er fungiert als High-Speed-Verkehrsleiter, der weiß, wohin er eine Verbindung schicken muss, aber nicht, was über diese Verbindung kommuniziert wird.

Layer 4 Load Balancer: Vor- und Nachteile

Vorteile eines L4 Load Balancers:

• Extrem hoher Durchsatz und niedrige Latenz, da keinerlei Nutzlast-Parsing stattfindet.
• Funktioniert für jeden Dienst, der über die vom Load Balancer unterstützten Protokolle läuft – typischerweise TCP und UDP. Nicht auf HTTP beschränkt.
• Einfachere Konfiguration und weniger bewegliche Teile.

Nachteile eines L4 Load Balancers:

• Kein inhaltsbasiertes Routing. Er kann nicht <wpml_ignored_tag wpml_name=“code“ wpml_value=“L2FwaQ==“ wpml_attrs=““/> an einen bestimmten Pool und <wpml_ignored_tag wpml_name=“code“ wpml_value=“L3N0YXRpYw==“ wpml_attrs=““/> an einen anderen senden.
• In den meisten Setups findet keine TLS-Terminierung am Proxy statt. Die Zertifikate verbleiben direkt auf den Backends.
• Keine Health Checks auf Anwendungsebene. Der Proxy kann zwar erkennen, ob ein TCP-Port offen ist, aber nicht, ob die Anwendung dahinter auch wirklich fehlerfrei läuft.
• Begrenzte Observability. Du siehst nur die Verbindungen, keine einzelnen Anfragen.

Was ist ein Layer 7 Load Balancer?

Ein Layer 7 Load Balancer, auch Application Load Balancer oder HTTP Load Balancer genannt, trifft seine Routing-Entscheidungen anhand des tatsächlichen Inhalts der HTTP-Anfragen. Er terminiert die Client-Verbindung, prüft die Request-Zeile sowie die Header, wendet definierte Regeln an und öffnet anschließend eine neue Verbindung zum ausgewählten Backend. Genau diese eine Eigenschaft ermöglicht pfadbasiertes Routing, hostbasiertes Routing, Regeln für Header und Cookies, Request Rewriting, Antwortkompression und die TLS-Terminierung an einem zentralen Punkt. Das ist ideal für eine Routing-Logik, die davon abhängt, wonach der User fragt, und nicht nur, wohin die Datenpakete geschickt werden.

Layer 7 Load Balancer: Vor- und Nachteile

Vorteile eines L7 Load Balancers:

• Pfadbasiertes und hostbasiertes Routing für Microservices und Multi-Tenant-Apps.
• TLS-Terminierung direkt am Proxy mit zentralem Zertifikatsmanagement.
• Native Unterstützung für HTTP/2, HTTP/3, WebSockets und gRPC.
• Sticky Sessions über Cookies, sodass derselbe User unabhängig von seiner Quell-IP immer auf demselben Backend landet.
• WAF-Integration zur Filterung böswilliger Anfragen, bevor sie überhaupt deine App erreichen.
• Detaillierte Observability pro Anfrage und umfassende Access-Logs.

Nachteile eines L7 Load Balancers:

• Höhere CPU-Kosten pro Anfrage, da die Nutzlast komplett parsed werden muss.
• Größere Konfigurationsfläche und damit mehr Möglichkeiten für Fehlkonfigurationen.
• Anwendungsbezogene Features helfen dir nur bei Protokollen, die der Proxy auch wirklich versteht.

Layer 4 vs. Layer 7 Load Balancer: Direktvergleich

Hier ist der L4 vs. L7 Load Balancer Vergleich auf einen Blick. Die gleichen Dimensionen tauchen in fast jedem Gespräch über L7 vs. L4 Load Balancer auf. Diese Vergleichstabelle für Layer 4 vs. Layer 7 Load Balancing bildet daher das Fundament für den restlichen Artikel.

Bei den Bezeichnungen Application Load Balancer vs. Network Load Balancer, die von den großen Cloud-Anbietern genutzt werden, steht ALB für L7 und NLB für L4. Die Unterscheidung zwischen Network Load Balancer vs. Application Load Balancer läuft also auf genau dieselbe Achse der Nutzlast-Inspektion hinaus.

Performance: Wie viel schneller ist Layer 4?

L4 ist im Allgemeinen schneller als L7 – und der Grund dafür ist rein technischer Natur. Ein L4-Proxy leitet Datenpakete weiter, ohne sie zu parsen. Dadurch bleibt die CPU-Auslastung pro Verbindung minimal und der Paketdurchsatz skaliert nahezu auf maximaler Netzwerk-Geschwindigkeit. L4-Datenpfade, die auf eBPF basieren (wie Cilium und Katran), treiben dies weiter auf die Spitze, indem sie die Weiterleitung direkt im Linux-Kernel statt im User-Space abwickeln. Die Lücke ist in der Realität jedoch kleiner, als das Marketing es oft suggeriert. Ein leistungsstarker Load Balancer auf Layer 7 wie NGINX oder Envoy bewältigt zehntausende von HTTPS-Anfragen pro Sekunde auf ganz bescheidener Hardware. Bei den meisten Web-Workloads verschiebt sich der Engpass ohnehin zuerst auf das Backend. Nutze L4, wenn es dir auf die reine Anzahl der rohen Verbindungen pro Sekunde ankommt. Nutze L7, wenn anwendungsspezifische Features der Anfrage wichtig sind.

Wann du einen Layer 4 Load Balancer verwenden solltest

Wann du einen Load Balancer auf Layer 4 einsetzen solltest, hängt im Wesentlichen von vier Signalen ab. Greife zu einem L4-Proxy, wenn einer dieser Punkte zutrifft:

• Der Traffic läuft nicht über HTTP. Ein TCP Load Balancer ist die einzige Option für Datenbanken, SMTP, IMAP und die meisten Gaming-Backends. Ein UDP Load Balancer wird zwingend für DNS, QUIC und Echtzeit-Medien benötigt.
• Du benötigst den maximalen Durchsatz pro CPU-Kern und deine Workload ist eher verbindungsintensiv als anfragenintensiv.
• Du möchtest die TLS-Terminierung direkt auf den Backends durchführen – oft aus Compliance-Gründen oder für benutzerspezifische Zertifikate.
• Du wünschst dir eine minimale Proxy-Oberfläche, da jedes zusätzliche Feature auch eine potenzielle Quelle für Fehlkonfigurationen ist.

Ein typisches L4-Deployment ist ein öffentlicher Network Load Balancer, der einer internen L7-Ebene vorgeschaltet ist.

Wann du einen Layer 7 Load Balancer verwenden solltest

Die Signale für L7 drehen sich darum, was du mit der Anfrage tun willst, und nicht darum, wie viele Datenpakete du durchschieben kannst. Greife zu einem HTTP Load Balancer, wenn einer dieser Punkte zutrifft:

• Du betreibst eine Web-App oder eine API und benötigst pfadbasiertes oder hostbasiertes Routing. Ein Load Balancer für Microservices läuft fast immer auf Layer 7.
• Du terminierst TLS zentral, verwaltest Zertifikate an einem einzigen Ort oder betreibst eine WAF vor deinem HTTP-Traffic.
• Du benötigst einen WebSocket Load Balancer, an Cookies gebundene Sticky Sessions oder HTTP/2- und gRPC-Multiplexing.
• Du willst detaillierte Logs pro Anfrage für das Debugging oder das SLO-Tracking nutzen.

Für die meisten modernen Web-Stacks ist der L7-Proxy der absolute Standard.

Kannst du auch beides verwenden? Geschichtete Load-Balancing-Architekturen

Die meisten großen Deployments entscheiden sich gar nicht für das eine oder das andere. Sie schichten beide Varianten übereinander. Eine typische Load-Balancer-Architektur platziert einen L4-Proxy an der Peripherie (Edge) für die rohe Skalierung und schaltet dahinter einen L7-Proxy im Inneren für das Routing. Die L4-Ebene bewältigt das reine Verbindungsvolumen, die DDoS-Mitigation und den Protokoll-Passthrough. Die L7-Ebene liest dann die einzelnen Anfragen aus und leitet sie gezielt weiter. Bei einem Load Balancer in Microservices fungiert die L7-Ebene oft gleichzeitig als Ingress-Controller, während ihr ein L4-Proxy oder eine Anycast-IP vorgeschaltet ist. Das Ergebnis kombiniert den extremen L4-Durchsatz mit der intelligenten L7-Anfrageerkennung.

Layer 3 Load Balancing: Ein kurzer Hinweis

Manchmal stößt man auch auf Referenzen zu Layer 3 Load Balancing – ganz besonders beim Edge-Networking von Hyperscalern. Ein Layer 3 Load Balancer routet direkt auf IP-Ebene, oft via ECMP oder Anycast mit BGP, und sitzt an der äußersten Peripherie noch vor der L4-Ebene. Das ist zwar eine reale Kategorie, für dich als Nutzer aber selten eine direkte Kaufentscheidung. Die meisten Betreiber nutzen Layer 3 Load Balancing einfach als integrierte Eigenschaft des Cloud-Provider-Edges.

Beispiele für Layer 4 und Layer 7 Load Balancer

Gängige Load-Balancer-Produkte und Software-Optionen:

• HAProxy. Arbeitet auf beiden Schichten. Der TCP-Modus entspricht L4, der HTTP-Modus entspricht L7.
• NGINX. Standardmäßig auf Layer 7 ausgelegt über http-Blöcke. Fügt L4-Unterstützung über das stream Modul für TCP und UDP hinzu.
• Envoy. Ein primär auf L7 ausgelegter Proxy, der in Service-Meshes wie Istio oder als eigenständiges Application Gateway zum Einsatz kommt. Unterstützt ebenfalls L4.
• Traefik. Ein bei Container-Plattformen sehr beliebter L7-Proxy, der über native L4-TCP- und UDP-Router verfügt.
• Cilium und Katran. Auf eBPF basierende L4-Datenpfade, die für extrem hochskalierbares TCP- und UDP-Forwarding genutzt werden.
• AWS NLB und ALB. Der NLB arbeitet auf Layer 4, der ALB auf Layer 7.
• Google Cloud Load Balancing. Bietet einen Application Load Balancer für L7 und einen Network Load Balancer für L4, jeweils in Passthrough- und Proxy-Varianten.
• Azure. Teilt die beiden Schichten auf separate Produkte auf: Azure Load Balancer für L4 (TCP und UDP) und Azure Application Gateway für L7 (HTTP und HTTPS, inklusive WAF).

Diese Load Balancer Beispiele decken die allermeisten Produktions-Stacks ab. Die Wahl des passenden Software-Load-Balancers hängt letztendlich davon ab, mit welchen Tools dein Team operativ am besten vertraut ist.

Wie du zwischen Layer 4 und Layer 7 wählst

Nutze diese Übersicht als schnelle Entscheidungs-Checkliste. Gängige Load Balancer Methoden wie Round-Robin, Least-Connections und IP-Hash gibt es auf beiden Ebenen – die Entscheidung für die Schicht kommt also noch vor der Wahl des Algorithmus.

• Protokolle: Alles außerhalb von HTTP, HTTPS, gRPC oder WebSockets deutet ganz klar auf L4 hin.
• TLS: Eine zentrale Terminierung bedeutet Layer 7. Pass-Through bedeutet Layer 4.
• Routing-Regeln: Ein Routing basierend auf Pfaden, Hosts, Headern oder Cookies gibt es ausschließlich auf Layer 7.
• Durchsatz: Wenn ein Proxy mehr Durchsatz benötigt, als dein L7-System pro Kern bewältigen kann, schalte eine L4-Ebene davor.
• Observability: Detaillierte Logs pro Anfrage bedeuten Layer 7. Wenn dir die reine Anzahl der Verbindungen reicht, ist L4 vollkommen ausreichend.
• Langfristig: Eine L4-Ebene vor einer L7-Ebene ist die gängigste Architektur für große, skalierbare Umgebungen.

L4 / L7 Load Balancing auf Contabo VPS

Auf den Contabo VPS-Tarifen läuft jeder Standard-Software-Load-Balancer, sodass du beide Schichten ganz ohne ein gemanagtes Produkt selbst bereitstellen kannst. Ein typisches Setup ist HAProxy oder NGINX auf einem kleineren VPS, der zwei oder mehr Anwendungsservern auf größeren Tarifen vorgeschaltet ist. NGINX deckt L7 über seinen http Block und L4 über das stream Modul ab, sodass ein einziges Binary beide Schichten gleichzeitig bedienen kann. HAProxy funktioniert exakt genauso mode tcp mit für L4 und mode http für L7. Für eine schrittweise Einrichtung schau dir einfach den Load Balancer Setup-Guide auf dem Contabo-Blog an. Er behandelt die VPS-Dimensionierung, die Installation des Proxys und die passenden Konfigurationsblöcke für beide Schichten.

Fazit

Die Entscheidung zwischen einem Layer 4 vs. Layer 7 Load Balancer ist unterm Strich eine Frage dessen, was der Proxy von den Daten sehen muss. L4 ist die perfekte Wahl für den reinen Rohdurchsatz, Nicht-HTTP-Protokolle oder Pass-Through-TLS. L7 ist die richtige Antwort, wenn du pfadbasiertes Routing, eine zentrale TLS-Terminierung und volle Sichtbarkeit auf Anfrageebene brauchst. Die meisten produktiven Stacks nutzen am Ende sowieso eine Kombination aus beidem.

Layer 4 vs. Layer 7 Load Balancer FAQ

Ist Layer 7 besser als Layer 4?

Keines der Systeme ist pauschal besser, es hängt komplett von deinem Anwendungsfall ab. Layer 7 bietet deutlich mehr Funktionen, da er HTTP-Anfragen tiefgehend analysiert – damit gewinnt er bei Web-Apps und Microservices. Layer 4 ist schneller und völlig protokollunabhängig für die unterstützten Transportprotokolle. Er punktet also bei Nicht-HTTP-Traffic, rohem Durchsatz und Deployments auf Edge-Ebene. Die Wahl zwischen einem L7 vs. L4 Load Balancer hängt also nur davon ab, welche Protokolle du verteilst und welche Routing-Regeln du benötigst.

Ist NGINX ein Layer 4 oder ein Layer 7 Load Balancer?

Beides. Als Load Balancer läuft NGINX standardmäßig auf Layer 7 über seinen http Konfigurationsblock, in dem das Routing für HTTP, HTTPS, HTTP/2 und WebSockets geregelt wird. Zusätzlich unterstützt NGINX Layer 4 über das stream Modul, welches echtes TCP und UDP Load Balancing ermöglicht. Dasselbe NGINX-Binary deckt also beide Schichten ab – einer der Hauptgründe, warum es nach wie vor die Standardlösung für gemischte Workloads ist.

Beendet ein Layer 4 Load Balancer SSL?

In der Regel nicht. Eine SSL-Terminierung am Load Balancer ist eine reine Layer-7-Funktion, da der Proxy die Anfrage im Klartext auslesen muss, um darauf basierend seine Routing-Entscheidungen zu treffen. Ein Layer 4 Load Balancer leitet verschlüsselten Traffic typischerweise direkt an die Backends weiter, die die TLS-Terminierung dann selbst übernehmen. Einige L4-Proxys bieten zwar Pass-Through mit SNI-basiertem Routing an, aber das ist eher die Ausnahme und nicht die Regel.

Kann ein Layer 7 Load Balancer auch Nicht-HTTP-Traffic verarbeiten?

Ein Layer 7 Load Balancer ist speziell für Anwendungsprotokolle ausgelegt, die er parsen kann – also hauptsächlich HTTP, HTTPS, gRPC und WebSockets. Bei beliebigem TCP- oder UDP-Traffic weicht ein L7-Proxy entweder auf den L4-Modus aus wie NGINX stream oder HAProxy mode tcp oder übergibt den Traffic an eine separate L4-Ebene. Reine Nicht-HTTP-Workloads gehören also definitiv auf Layer 4, nicht auf Layer 7.

Was ist der Unterschied zwischen einem Application Load Balancer und einem Network Load Balancer?

Bei den meisten Bezeichnungen von Cloud-Anbietern ist ein Application Load Balancer auf Layer 7 angesiedelt und ein Network Load Balancer auf Layer 4. Der Unterschied zwischen einem Application Load Balancer und einem Network Load Balancer ist also exakt derselbe wie bei L7 vs. L4. Der ALB liest HTTP-Anfragen aus und routet den Traffic basierend auf URLs, Hosts und Headern. Der NLB leitet TCP- und UDP-Verbindungen rein basierend auf IP-Adressen und Ports weiter. ALB vs. NLB ist quasi einfach die Cloud-Variante von L4 vs. L7.