Load Balancing ist erst dann langweilig, wenn man den falschen Modus gewählt hat und plötzlich Sticky Sessions, TLS oder WebSockets anfangen, Möbel zu werfen. TCP und HTTP Load Balancing klingen nach zwei Wegen zum gleichen Ziel. Sind sie aber nicht. Der eine verteilt Verbindungen. Der andere versteht Requests. Das ist ein ziemlich großer Unterschied.
Layer 4: TCP Load Balancing mit Helm und Brechstange
TCP Load Balancing arbeitet auf Layer 4. Der Load Balancer sieht IPs, Ports und TCP-Verbindungen. Mehr nicht. Kein Pfad, kein Host-Header, keine Cookies, kein HTTP-Statuscode. Dafür ist er schnell, simpel und angenehm universell.
Typische Kandidaten:
- Datenbanken wie PostgreSQL oder MySQL
- Redis, MQTT, SMTP, IMAP
- HTTPS-Passthrough mit TLS bis zum Backend
- Protokolle, die eben nicht HTTP sprechen
Ein simples NGINX-stream-Beispiel:
# /etc/nginx/nginx.conf
stream {
upstream postgres_backends {
server 10.10.0.11:5432;
server 10.10.0.12:5432;
}
server {
listen 5432;
proxy_pass postgres_backends;
}
}Das Ding macht genau das, was draufsteht: Verbindung rein, Verbindung zu einem Backend raus. Kein Drama, keine Interpretation. Wenn dein Protokoll binär ist oder TLS unverändert beim Ziel ankommen soll, ist Layer 4 oft der saubere Weg.
Aber: Sobald du Entscheidungen auf Basis von HTTP brauchst, wird Layer 4 blind wie ein Switch im Nebel.
Layer 7: HTTP Load Balancing mit Lesebrille
HTTP Load Balancing arbeitet auf Layer 7. Der Load Balancer terminiert oder versteht HTTP und kann anhand von Inhalten entscheiden. Hostname, Pfad, Header, Cookies, Methoden, Statuscodes — alles im Werkzeugkasten.
Das brauchst du bei:
- Routing nach Host oder URL-Pfad
- Blue/Green-Deployments
- Canary-Releases
- Cookie-basierter Session Persistence
- Header-Manipulation
- zentraler TLS-Terminierung
- HTTP-Healthchecks wie /healthz
Beispiel mit NGINX:
# /etc/nginx/conf.d/app.conf
upstream app_backend {
server 10.10.0.21:8080;
server 10.10.0.22:8080;
}
server {
listen 443 ssl;
server_name app.example.local;
ssl_certificate /etc/nginx/certs/app.crt;
ssl_certificate_key /etc/nginx/certs/app.key;
location /api/ {
proxy_pass http://app_backend;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
}
}Jetzt kann der Load Balancer wirklich mitreden. Er weiß, dass /api/ woanders hin darf als /static/. Er kann defekte Backends anhand echter HTTP-Antworten rauswerfen. Er kann TLS beenden und Zertifikate zentral verwalten. Praktisch. Aber nicht kostenlos.
Layer 7 braucht mehr CPU, mehr Konfiguration und mehr Verantwortung. Wenn TLS terminiert wird, muss dein Backend sauber mit X-Forwarded-Proto und X-Forwarded-For umgehen. Sonst baut deine App fröhlich HTTP-Redirects auf HTTPS-Seiten. Klassiker. Tut jedes Mal weh.
Die Entscheidung: Was muss der Load Balancer wissen?
Unsere Faustregel aus dem Maschinenraum:
Wenn der Load Balancer den Inhalt nicht verstehen muss, nimm TCP. Wenn er HTTP-Entscheidungen treffen soll, nimm HTTP.
TCP ist ideal, wenn du möglichst wenig anfassen willst. Besonders bei Datenbanken oder Diensten, deren Protokoll der Load Balancer nicht interpretieren soll. Auch bei TLS-Passthrough ist TCP sinnvoll, weil Zertifikate und Verschlüsselung komplett beim Backend bleiben.
HTTP ist richtig, wenn du Applikationslogik am Eingang brauchst. Mehrere Domains auf einer IP? Pfad-basiertes Routing? Auth-Header weiterreichen? Wartungsseite bei kaputtem Backend? Dann willst du Layer 7.
Der kleine Haken mit Healthchecks
Bei TCP bedeutet „gesund“ oft nur: Port offen. Das ist besser als nichts, aber nicht viel besser. Eine App kann TCP annehmen und trotzdem intern brennen.
Bei HTTP kannst du gezielt prüfen:
curl -i https://app.example.local/healthzWenn da 200 OK kommt und deine App dabei Datenbank, Cache und Migrationsstatus prüft, bist du deutlich näher an der Wahrheit.
Kurzfassung für die Praxis
Nimm Layer 4 für rohe Verbindungen, Nicht-HTTP-Protokolle und TLS-Passthrough. Nimm Layer 7 für Webanwendungen, Routing-Logik, TLS-Terminierung und smarte Healthchecks.
Oder in Sysadmin-Sprache: Layer 4 ist der Türsteher mit Gästeliste nach Portnummer. Layer 7 liest zusätzlich den Ausweis, fragt nach dem Zielraum und merkt sich, wer beim letzten Besuch den Kaffeeautomaten kaputt gemacht hat.
