L4 oder L7: Die passende Ebene fürs Loadbalancing

TL;DR

L4 L7 Loadbalancing ist keine Frage einer pauschal besseren Technologie. TCP Loadbalancing verteilt Verbindungen, ohne den Inhalt höherer Protokolle zu kennen. HTTP Loadbalancing versteht Requests und kann deshalb gezielt routen, schützen und terminieren. Entscheidend sind Protokoll, Sichtbarkeit des Traffics und die benötigten Routing-Funktionen.

Einleitung

Die falsche Loadbalancing-Ebene führt häufig zu unnötiger Komplexität: Ein TCP-Service wird mit HTTP-Regeln behandelt, oder eine API erhält nur eine blinde Verteilung auf Backends. Layer 4 und Layer 7 lösen unterschiedliche Probleme. L4 arbeitet auf Verbindungsebene und eignet sich für TCP-basierte Dienste, bei denen der Inhalt nicht ausgewertet werden soll. L7 verarbeitet HTTP- oder HTTPS-Kommunikation und kann Requests anhand von Host, Pfad oder weiteren Merkmalen unterscheiden. Die Architekturentscheidung sollte daher nicht vom Wunsch nach „mehr“ Funktionalität bestimmt werden, sondern von dem, was am öffentlichen Eingang technisch sichtbar und betrieblich erforderlich ist.

1. Layer 4: Verbindungen verteilen, Protokolle offenhalten

Layer-4-Loadbalancing arbeitet typischerweise mit TCP-Verbindungen. Die Verteilung erfolgt anhand von Informationen wie Zieladresse, Port und Verbindungszustand. Der Loadbalancer muss nicht wissen, ob über die Verbindung ein HTTP-Request, ein Datenbankprotokoll oder ein anderes TCP-basiertes Protokoll übertragen wird. Das macht L4 besonders geeignet für Dienste, deren Protokoll nicht HTTP ist oder deren Nutzdaten unverändert bis zum Backend gelangen sollen.

Ein zentraler Vorteil ist die geringe Protokollabhängigkeit. TLS kann beispielsweise bis zum Backend durchgereicht werden, sodass die Entschlüsselung dort stattfindet. Der Preis dafür ist die begrenzte Sichtbarkeit: Pfade, HTTP-Header und Methoden stehen für Routing-Entscheidungen nicht zur Verfügung. Auch HTTP-spezifische Schutz- und Routingregeln lassen sich auf dieser Ebene nicht anwenden. In der ayedo Edge Cloud steht Anycast-basiertes Layer-4-Loadbalancing für solche Verbindungsmodelle zur Verfügung. Proxy Protocol kann dabei zusätzliche Informationen zur Verbindung an das Backend übermitteln.

2. Layer 7: HTTP-Requests gezielt verarbeiten

Layer 7 setzt bei HTTP oder HTTPS an. Nach einer TLS-Termination kann die Edge den Request-Inhalt auswerten und beispielsweise nach Hostname, URL-Pfad oder anderen HTTP-Merkmalen routen. Damit lassen sich mehrere Anwendungen, APIs oder Versionen hinter einem gemeinsamen öffentlichen Eingang betreiben, ohne für jeden Dienst eine eigene IP-Adresse oder einen eigenen Port zu benötigen.

Die höhere Sichtbarkeit erweitert zugleich den Verantwortungsbereich. Die Edge wird zum Bestandteil der Request-Verarbeitung: TLS endet vor dem Backend, HTTP-Regeln bestimmen die Weiterleitung, und eine Web Application Firewall kann HTTP-/HTTPS-Services prüfen. Änderungen an Routingregeln wirken damit unmittelbar auf den Anwendungseingang und müssen wie produktionsnahe Konfiguration behandelt werden. L7 ist außerdem nicht für beliebige TCP-Protokolle geeignet. In der ayedo Edge Cloud verbindet sich Layer-7-Loadbalancing mit Funktionen wie Backend Health Checks, Failover, Backend Cloaking und zentraler Traffic-Verteilung. Das ist insbesondere für HTTP-basierte Anwendungen und APIs relevant, unabhängig davon, bei welchem Provider das Backend betrieben wird.

3. Sichtbarkeit bestimmt Routing und Security

Die Wahl zwischen TCP Loadbalancing und HTTP Loadbalancing ist vor allem eine Entscheidung über Sichtbarkeit. Wer TLS am Backend terminieren und den verschlüsselten Datenstrom unverändert weiterleiten muss, benötigt häufig L4. Wer dagegen Requests auf unterschiedliche Backends verteilen, HTTP-Kommunikation an der Edge schützen oder öffentlich sichtbare Backend-Adressen verbergen möchte, profitiert von L7.

Diese Entscheidung hat auch betriebliche Folgen. Bei L4 bleibt die Anwendungskomplexität stärker im Backend: TLS, HTTP-Routing und teilweise Schutzmechanismen müssen dort organisiert werden. Bei L7 werden zentrale Funktionen an die Edge verlagert. Das vereinfacht eine einheitliche Eingangsschicht, erhöht aber die Anforderungen an Regelmanagement, Tests und Verantwortlichkeiten. Eine Edge-Plattform wie ayedo kann beide Ebenen in einer verteilten Multi-PoP-Architektur und nach dem Aktiv-Aktiv-Prinzip bereitstellen. Dadurch wird die Auswahl nicht an eine einzelne Backend-Topologie gebunden. Die Edge bleibt für Eingang, Schutz und Verteilung zuständig; die Compute-Infrastruktur führt die Workloads aus.

4. L4 und L7 kombinieren statt dogmatisch entscheiden

In realen Plattformen ist eine Kombination oft sinnvoller als eine globale Festlegung. Ein öffentliches API-Gateway kann HTTP-Verbindungen auf L7 terminieren und anhand des Request-Pfads auf verschiedene Kubernetes-Services verteilen. Ein separater TCP-Service, etwa für ein nicht HTTP-basiertes Protokoll, wird parallel auf L4 betrieben. Beide Dienste können denselben öffentlichen Edge-Einstieg nutzen, benötigen aber unterschiedliche Verarbeitungslogik.

Auch innerhalb einer Anwendung kann die Grenze bewusst gesetzt werden. L4 eignet sich, wenn Ende-zu-Ende-TLS bis zum Backend oder ein unverändertes Protokoll gefordert ist. L7 ist angemessen, wenn Routing, WAF, TLS-Termination oder Backend Cloaking zentral umgesetzt werden sollen. Kubernetes-native Integration macht diese Modelle auch mit eigenen oder bei anderen Providern betriebenen Clustern nutzbar. Relevant ist dabei nicht, ob Kubernetes selbst von ayedo betrieben wird, sondern wo der öffentliche Traffic eingeordnet, geprüft und anschließend zum jeweiligen Backend verteilt werden soll.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt eine HTTP-API in einem Kubernetes-Cluster und einen TCP-basierten Streamingdienst in einer separaten Compute-Umgebung. Für die API wird L7 verwendet: TLS endet an der Edge, Requests werden anhand von Host und Pfad verteilt, und die HTTP-Schnittstelle wird durch die WAF geschützt. Der Streamingdienst nutzt L4, weil sein Protokoll nicht HTTP ist und die Verbindung bis zum Backend erhalten bleiben muss.

Beide Varianten profitieren von Anycast und Health Checks, unterscheiden sich aber in der Betriebsverantwortung. Beim API-Routing müssen HTTP-Regeln und Zertifikatsprozesse kontrolliert werden. Beim TCP-Dienst liegen Protokollverständnis und TLS-Verarbeitung weiterhin beim Backend. Eine gemeinsame Edge-Schicht reduziert dabei nicht die Unterschiede zwischen den Diensten, sondern macht sie explizit und zentral steuerbar.

FAQ

Ist L7 grundsätzlich besser als L4?

Nein. L7 bietet mehr HTTP-Sichtbarkeit, ist aber protokollabhängig. Für TCP-Dienste oder durchgereichtes TLS ist L4 die passendere Ebene.

Kann ein Dienst beide Ebenen verwenden?

Ja, sofern unterschiedliche Endpunkte oder Listener vorgesehen sind. HTTP- und TCP-Dienste können über dieselbe Edge-Plattform mit jeweils passender Verarbeitung betrieben werden.

Wann sollte TLS an der Edge enden?

Wenn zentrale HTTP-Inspektion, WAF-Regeln oder Request-basiertes Routing erforderlich sind. Bei Ende-zu-Ende-TLS bis zum Backend ist TLS-Passthrough über L4 naheliegender.

Fazit

L4 L7 Loadbalancing sollte anhand des Protokolls, der gewünschten Sichtbarkeit und der benötigten Betriebsfunktionen entschieden werden. L4 hält Verbindungen und Nutzdaten weitgehend transparent, während L7 HTTP-Kommunikation gezielt verarbeiten, schützen und verteilen kann. Die ayedo Edge Cloud unterstützt beide Ebenen als Bestandteil einer öffentlichen, providerunabhängig nutzbaren Edge-Plattform. Entscheidend ist daher nicht die pauschale Präferenz für L4 oder L7, sondern die saubere Zuordnung zur jeweiligen Anwendung und ihrem Backend.