TCP-Verteilung mit L4-Loadbalancing für robuste Dienste

TL;DR

L4 Loadbalancing verteilt TCP-Verbindungen anhand von Transportinformationen wie IP-Adresse und Port. Im Gegensatz zu HTTP-Routing bewertet es keine URLs, Header oder Inhalte. Dadurch bleiben Protokoll und Payload unverändert, während Backend-Pools, Health Checks und Failover robuste Dienste für Datenbanken, Messaging, VPNs oder proprietäre TCP-Anwendungen ermöglichen.

Einleitung

Ein häufiger Architekturfehler besteht darin, jedes externe Service automatisch über HTTP-Loadbalancing abzubilden. Für verbindungsorientierte TCP-Dienste ist diese Annahme falsch: Der Loadbalancer kann die Anwendung nicht anhand von URL, Host-Header oder HTTP-Methode routen, weil diese Informationen entweder nicht existieren oder nicht ausgewertet werden. L4 Loadbalancing setzt deshalb an einer anderen Stelle an. Es verteilt Verbindungen anhand von Netzwerk- und Transportinformationen und hält die Anwendungsschicht weitgehend aus der Entscheidung heraus. Das reduziert die Protokollabhängigkeit, begrenzt aber zugleich die Steuerungsmöglichkeiten. Genau dieser Trade-off ist für die Wahl zwischen Layer 4 und Layer 7 entscheidend.

1. Wie L4 Loadbalancing TCP-Verbindungen verteilt

Bei der TCP-Verteilung betrachtet ein Layer-4-Loadbalancer typischerweise Quell- und Ziel-IP, TCP-Port sowie den Verbindungszustand. Ein Client verbindet sich mit einer öffentlichen Adresse und einem Port. Die Edge nimmt die Verbindung an, wählt anhand definierter Verteilungslogik einen Server aus einem Backend-Pool und leitet den TCP-Datenstrom an dieses Backend weiter.

Die Anwendung muss dabei nicht HTTP sprechen. Das Verfahren eignet sich ebenso für Protokolle, die auf TCP aufsetzen, aber eigene Nachrichtenformate verwenden. Der Loadbalancer muss deren Inhalt nicht verstehen, um eine Verbindung zu vermitteln. Das ist ein wesentlicher Unterschied zu protokollbewusstem Routing: Die Verteilung erfolgt auf Verbindungsebene, nicht anhand fachlicher Anwendungsmerkmale.

In einer verteilten Edge-Architektur kann eine Anycast-Adresse als öffentlicher Einstiegspunkt dienen. Die Verbindung wird an einen verfügbaren Edge-Standort geführt, während die Zuordnung zum Backend innerhalb des definierten Pools erfolgt. Die ayedo Edge Cloud unterstützt Anycast-basiertes Layer-4- und Layer-7-Loadbalancing und bildet damit auch für TCP-Dienste einen öffentlichen, verteilten Eingang.

2. Backend-Pools, Zustände und Verbindungsweiterleitung

Backend-Pools kapseln die Ziele, an die eingehende TCP-Verbindungen verteilt werden. Sie können mehrere Instanzen, Knoten oder Endpunkte eines Dienstes enthalten. Health Checks prüfen, ob diese Ziele grundsätzlich erreichbar und dienstbereit sind. Fällt ein Backend aus, kann es aus der Verteilung genommen werden. Neue Verbindungen werden dann an verbleibende Ziele weitergeleitet.

Wichtig ist die Unterscheidung zwischen Verbindung und Anfrage. Bei HTTP kann ein Proxy einzelne Requests bewerten und gegebenenfalls unterschiedlich weiterleiten. Bei TCP wird dagegen eine bestehende Verbindung einem Ziel zugeordnet. Diese Zuordnung bleibt in der Regel bestehen, solange die Verbindung aktiv ist. Ein Backend-Ausfall während einer laufenden TCP-Sitzung lässt sich daher nicht einfach durch eine neue Verbindung im Hintergrund kompensieren. Failover wirkt primär auf neue Verbindungsaufbauten.

Je nach Weiterleitungsmodell sieht das Backend als Quelladresse die Edge oder den ursprünglichen Client. Wird die Client-Identität technisch benötigt, kann Proxy Protocol zusätzliche Verbindungsinformationen übertragen, sofern das Backend dieses Format unterstützt. Backend Cloaking sorgt zugleich dafür, dass interne Zielsysteme nicht direkt öffentlich adressiert werden müssen.

3. Welche Eigenschaften gegenüber HTTP-Routing erhalten bleiben

L4 Loadbalancing verändert den TCP-Datenstrom nicht fachlich. Es interpretiert weder HTTP-Header noch URLs und benötigt kein bestimmtes Anwendungsprotokoll. Dadurch bleiben Eigenschaften erhalten, die bei einer HTTP-Terminierung oder einem HTTP-Proxy anders behandelt werden können: proprietäre Nachrichtenformate, binäre Payloads, langlebige Sessions und TCP-basierte Protokollzustände.

Diese Protokollneutralität ist besonders relevant, wenn ein Dienst keine HTTP-Semantik besitzt oder wenn eine zusätzliche Verarbeitungsschicht unerwünscht ist. Gleichzeitig kann L4 nicht nach Kriterien wie Hostname, Pfad, Cookie oder API-Version unterscheiden. Zwei Verbindungen zum selben Port sehen aus Sicht der Verteilung grundsätzlich gleich aus, auch wenn sie unterschiedliche fachliche Funktionen verwenden.

Damit verschiebt sich die Verantwortung für differenziertes Routing in die Architektur des Dienstes. Separate Ports, eigene virtuelle Adressen oder getrennte Backend-Pools können diese Begrenzung teilweise ausgleichen. Das ist weniger flexibel als HTTP-Routing, kann aber transparenter und stabiler sein, wenn die Anwendung bewusst als langlebiger TCP-Dienst betrieben wird.

4. Einsatzszenarien und betriebliche Grenzen

Typische Einsatzszenarien sind Datenbankzugänge, Message Broker, Mail- und Verzeichnisdienste, VPN-Endpunkte, Game-Server sowie proprietäre TCP-Anwendungen. Auch TLS-geschützte Dienste können auf Layer 4 verteilt werden, wenn die Edge den verschlüsselten Datenstrom nicht anhand des Anwendungsinhalts routen soll. Die Entscheidung für oder gegen TLS Termination an der Edge hängt dabei von Sicherheitsmodell, Zertifikatsverwaltung und benötigter Protokollsicht ab.

Für den Betrieb sind vor allem Verbindungsdauer, Session-Bindung und Backend-Kapazität relevant. Ein Pool kann viele neue Verbindungen gleichmäßig verteilen und trotzdem einzelne Backends stark belasten, wenn dort langlebige Sessions bestehen bleiben. Health Checks müssen außerdem den tatsächlichen Dienstzustand sinnvoll abbilden; ein offener TCP-Port beweist nicht automatisch, dass die Anwendung funktionsfähig ist.

Eine Edge-Plattform wie die ayedo Edge Cloud ordnet diese Aufgaben vor der Compute-Infrastruktur ein: öffentlicher Einstieg, TCP-Verteilung, Schutz und Weiterleitung liegen an der Edge, während der eigentliche Dienst im gewählten Backend ausgeführt wird. Das gilt auch für Kubernetes-Cluster außerhalb von ayedo Managed Kubernetes.

Praxis- und Betriebsszenario

Ein Unternehmen betreibt einen proprietären TCP-Dienst in zwei Backend-Pools. Beide Pools gehören zur gleichen Anwendung, benötigen aber getrennte Wartungszyklen. Über einen gemeinsamen öffentlichen Einstieg wird der Traffic auf definierte Ports verteilt; jeder Port verweist auf den passenden Pool. Health Checks entfernen nicht erreichbare Ziele aus der Auswahl.

Im Vergleich zu HTTP-Routing gibt es keine Möglichkeit, innerhalb einer bestehenden Verbindung nach Nachrichtentyp zu unterscheiden. Für geplante Wartung werden deshalb neue Verbindungen auf einen anderen Pool gelenkt, während bestehende Sessions kontrolliert auslaufen. Diese Betriebsstrategie berücksichtigt die zentrale Eigenschaft von TCP: Eine einmal etablierte Verbindung bleibt an ihr Ziel gebunden. Für lange Sessions muss Failover daher auf Anwendungsebene oder über einen erneuten Verbindungsaufbau erfolgen.

FAQ

Wann ist L4 Loadbalancing die bessere Wahl als L7-Routing?

Wenn der Dienst kein HTTP spricht, die Payload unverändert bleiben soll oder langlebige TCP-Verbindungen verwendet werden. L7 bietet mehr Steuerungsmöglichkeiten, setzt aber ein auswertbares Anwendungsprotokoll voraus.

Kann L4 Loadbalancing einzelne Nachrichten innerhalb einer TCP-Verbindung verteilen?

Nein. Die Zuordnung erfolgt für die TCP-Verbindung. Einzelne Nachrichten oder Requests innerhalb dieser Verbindung werden nicht unabhängig auf verschiedene Backends verteilt.

Was passiert bei einem Backend-Ausfall?

Health Checks können ein fehlerhaftes Backend für neue Verbindungen aus dem Pool nehmen. Bereits bestehende TCP-Sitzungen brechen jedoch je nach Fehlerbild ab und benötigen meist einen erneuten Verbindungsaufbau.

Fazit

L4 Loadbalancing ist keine vereinfachte Variante von HTTP-Routing, sondern eine andere Architekturentscheidung. Es schützt die Protokollneutralität und eignet sich für TCP-Dienste, bei denen Inhalt, Session-Zustand oder proprietäre Kommunikation nicht an der Edge interpretiert werden sollen. Dafür entfallen anwendungsbezogene Routingoptionen. Die ayedo Edge Cloud kann solche Verbindungen über Anycast, Backend-Pools, Health Checks und Failover als zentralen öffentlichen Eingang vor unterschiedlichen Compute-Umgebungen einordnen.