Die OSI-Schichtunterscheidung, die weiterhin wichtig ist
Das Konzept des Load Balancing ist einfach: eingehende Anfragen über mehrere Dienst-Instanzen verteilen, damit kein einzelner Server überlastet wird und die Anwendung verfügbar bleibt. Interessant ist, wie diese Verteilungsentscheidung getroffen wird. Die folgenreichste Trennlinie liegt zwischen Layer 4 und Layer 7.
Layer 4 Load Balancing arbeitet auf der Transportschicht des OSI-Modells — TCP und UDP. Der Load Balancer sieht die Quell-IP, die Ziel-IP und die Ports einer Verbindung; mehr nicht. Er trifft seine Verteilungsentscheidung auf Basis dieser Header-Felder und reicht dann die Bytes durch, ohne die Payload zu inspizieren. Das Anwendungsprotokoll kann HTTP, MySQL, Kafka oder ein eigenes binäres Protokoll sein — der Load Balancer weiß es nicht und es ist ihm egal.
Layer 7 Load Balancing arbeitet auf der Anwendungsschicht — HTTP, HTTPS, gRPC, WebSocket. Der Load Balancer parst jede Anfrage, liest URL-Pfad, Header, Cookies und Methode und trifft Routing-Entscheidungen basierend auf diesem Inhalt. Er kann Anfragen auch im Durchlauf transformieren: Kompression, Header-Umschreibung, TLS-Terminierung, Caching.
Layer 7 ist mächtiger als Layer 4 und teurer als Layer 4. Die Wahl zwischen beiden hängt davon ab, ob das Anwendungsprotokoll HTTP-förmig ist und ob die zusätzlichen Fähigkeiten die Kosten pro Verbindung wert sind.
Wann Layer 4 die richtige Wahl ist
Szenarien, in denen L4 die richtige Antwort ist, teilen eine Eigenschaft: das Parsen von Anwendungsinhalten ist entweder unnötig oder passt nicht ins Budget.
Nicht-HTTP-Protokolle sind das klarste Beispiel der Kategorie. Für Datenbanken (MySQL, PostgreSQL), Message Queues (Kafka, RabbitMQ), E-Mail (SMTP) und benutzerdefinierte TCP-Dienste muss der Load Balancer keine Anwendungsinhalte verstehen — Port- und Verbindungsrate-Verteilung funktionieren gut.
Auch reine Performance-Anforderungen verweisen auf L4. L4's Overhead pro Verbindung ist der niedrigste, weil keine Anwendungs-Parsing stattfindet. Für hochvolumige TCP-Dienste, bei denen jede Mikrosekunde zählt — latenzempfindliche Handelsplattformen, Echtzeit-Gaming-Backends, ähnliche Workloads — ist L4 das richtige Werkzeug.
Ende-zu-Ende-Verschlüsselung ist ein weiterer L4-Fall. Wenn TLS an der Anwendung anstatt am Load Balancer terminieren muss — regulatorische Vorgabe, Multi-Tenant-Isolation, kundengesteuerte Schlüssel — leitet L4 TLS transparent durch. Der Load Balancer sieht den Klartext nie.
Wenn schließlich einfache Verteilungslogik ausreicht, läuft L4 mit weniger operativem Overhead. Genügen Round-Robin, Quell-IP-Hash oder Least-Connections und ist URL-basiertes Routing nicht nötig, ist L4 sowohl leichter als auch einfacher zu durchdenken.
Wann Layer 7 die richtige Wahl ist
Was L7 auszeichnet, ist seine Fähigkeit, Routing- und Transformationsentscheidungen auf Basis von Anwendungsinhalten zu treffen. Ohne diese Fähigkeit würden die meisten modernen Web-Anwendungen nicht funktionieren.
URL-basiertes Routing ist der häufigste Fall. Verschiedene Pfade an verschiedene Dienst-Cluster zu senden — /api/v1/users zu einem Cluster, /api/v1/orders zu einem anderen, /static/* zu einem CDN — ist mit L4 nicht möglich, weil L4 keine Pfade sieht.
Header- oder Cookie-basiertes Routing erfordert ebenfalls L7. A/B-Tests, Versions-Pinning (X-Service-Version: 2.5 routet zu einer bestimmten Bereitstellung), Session-Affinität über Anwendungs-Session-ID und kundenspezifisches Routing per Header — all das setzt das Lesen von Anwendungsinhalten voraus.
TLS-Terminierung ist ebenfalls eine L7-Aufgabe. SSL-Offload terminiert TLS am Load Balancer und entlastet die Dienste von Krypto-Arbeit; es ermöglicht zentrale Zertifikatsverwaltung; es ermöglicht WAF-Inspektion. Die WAF braucht Klartext, um Angriffe zu sehen; ohne L7 passiert das nicht.
Anwendungsbewusste Funktionen — Kompression, Caching, Anfrage-Umschreibung, inhaltsbasierte Health Checks (der Dienst gibt 200 auf /health zurück, nicht nur Verbindungen an) und das Herunterstufen von HTTP/2 auf HTTP/1.1 für Legacy-Dienste — erfordern ebenfalls L7.
Anwendungs-Level-Beobachtbarkeit folgt derselben Logik. Latenz pro Endpunkt, Fehlerrate nach URL, Slow-Query-Erkennung — diese verlangen, Anfragen zu sehen, nicht Verbindungen. L7 bringt diese Daten an die Oberfläche; L4 sieht nur die Verbindungsebene.
Der Kernpunkt lautet: Wenn Sie auf Basis von Anwendungsinhalten entscheiden, ist L7 zwingend. Wenn Sie nur auf Verbindungsebene entscheiden, genügt L4.
Direkter Vergleich
| Dimension | Layer 4 | Layer 7 |
|---|---|---|
| OSI-Schicht | Transport (TCP/UDP) | Anwendung (HTTP, HTTPS, gRPC, WebSocket) |
| Routing-Eingaben | Quell-IP, Ziel-IP, Ports | URL, Header, Cookies, Methode, Body |
| TLS-Handhabung | Pass-through | Terminieren oder Pass-through |
| Overhead pro Verbindung | Am niedrigsten | Höher (Parsing erforderlich) |
| Verteilungsalgorithmen | Round-Robin, Quell-IP-Hash, Least-Connections | Alle L4-Algorithmen plus inhaltsbasiertes Routing, Gewichtung nach URL |
| WAF-Integration | Nicht möglich (keine Inhaltssichtbarkeit) | Nativ |
| Beobachtbarkeit | Verbindungsebene | Anfrageebene |
| Typischer Anwendungsfall | Datenbank-Proxying, Gaming, RTMP, SMTP | Webanwendungen, APIs, Microservices |
Moderne Bereitstellungen verwenden beide
Die Entscheidung lautet selten "L4 oder L7" für eine gesamte Infrastruktur. Sie fällt pro Anwendung — manchmal pro Listener.
Ein typisches Unternehmensmuster kombiniert beide Modi. L7 am Rand für HTTPS-Traffic von Benutzern; L4 für internen Ost-West-Traffic, bei dem das Protokoll TCP-nativ ist und das Latenzbudget eng ist; L7 wieder dort, wo Ost-West-Traffic über RPC auf HTTP läuft, etwa gRPC.
Die architektonische Frage ist, ob eine einzige Load-Balancer-Bereitstellung beide Modi handhaben kann oder ob die Organisation getrennte L4- und L7-Produkte betreiben sollte. Der Ansatz mit getrennten Produkten war historisch verbreitet, weil L4 und L7 unterschiedliche Implementierungsanforderungen hatten — L4 wollte Kernel-Bypass-Netzwerk, L7 wollte reichhaltiges HTTP-Parsing. Moderne ADCs haben diese Lücke geschlossen; dasselbe Gerät handhabt beide Modi durch Konfiguration pro Listener.
Der operative Vorteil der Kombination ist derselbe wie bei jeder Konsolidierung: ein Produkt zum Bereitstellen, eine Beobachtbarkeitsfläche, ein Satz operativer Runbooks, ein Upgrade-Pfad. Für Organisationen, die zuvor L4- und L7-Produkte verschiedener Hersteller betrieben haben, ist die Konsolidierung auf einen einzigen ADC oft die größte verfügbare operative Vereinfachung.
Wie der TR7 Load Balancer beide Modi handhabt
TR7's Load Balancer (LB) trägt sowohl L4- als auch L7-Modi auf demselben Gerät durch Konfiguration pro Listener. Eine einzige Bereitstellung kann diese Listener nebeneinander hosten: einen L7-Listener auf 443, der HTTPS-Web-Traffic mit WAF und SSL-Beschleunigung handhabt; einen L4-Listener auf 5432, der PostgreSQL-Verbindungen mit Quell-IP-Affinität handhabt; einen weiteren L7-Listener auf 8080, der interne gRPC-Dienste mit mTLS handhabt. Alle gemeinsam konfiguriert, mit geteilter Beobachtbarkeit und einem einzigen Upgrade-Lebenszyklus.
Hardware-Beschleunigung gilt für beide Modi. L4-Verbindungen profitieren von Kernel-Bypass-Paketverarbeitung; L7-Verbindungen profitieren von ausgelagerter TLS-Terminierung und HTTP/2- / HTTP/3-Parsing. Dasselbe physische Gerät kann Tausende von L4-TCP-Diensten gleichzeitig mit Tausenden von L7-HTTPS-Sitzungen tragen; die Grenze ist der Hardware-Rahmen, keine Lizenz oder Feature-Sperre pro Modus.
Für Organisationen, die 2026 zwischen Herstellern wählen, ist die Frage "unterstützt dieser LB sowohl L4 als auch L7?" kein Unterscheidungsmerkmal mehr; die meisten tun es. Die Unterscheidungsmerkmale sind die operative Geschichte (ein Produkt oder zwei), die Beobachtbarkeitsgeschichte (vereinheitlicht oder geteilt) und die Modernisierungsgeschichte (HTTP/3, TLS 1.3, Unterstützung für Post-Quanten-Kryptografie). TR7 ist um diese drei Achsen positioniert; L4- und L7-Fähigkeit ist die Eingabe.
L4 + L7 auf einer einzigen Plattform
TR7 Load Balancer trägt L4- und L7-Modi auf demselben Gerät, mit Hardware-Beschleunigung für beide. Eine Beobachtbarkeitsfläche, ein Upgrade-Pfad, beide Modi pro Listener verfügbar.
TR7 Load Balancer entdecken