Eine Verbindung ist noch kein HTTP-Request

Warum moderne Edge-Plattformen deutlich früher beginnen, als viele Architekturdiagramme vermuten lassen.

Es gibt eine bemerkenswerte Eigenart moderner Plattformarchitekturen. Obwohl wir heute nahezu jede öffentliche Anwendung hinter einem Loadbalancer, einem API Gateway oder einer Web Application Firewall betreiben, sprechen wir erstaunlich selten darüber, was zwischen dem ersten TCP-Paket und dem ersten Byte einer HTTP-Anfrage tatsächlich geschieht. Der Grund dafür ist naheliegend. Für den Entwickler verschwindet diese Infrastruktur meist vollständig hinter einer URL. Der Browser baut eine Verbindung auf, der Reverse Proxy nimmt sie entgegen und wenige Millisekunden später verarbeitet die Anwendung bereits den Request. Aus Sicht der Plattform beginnt die eigentliche Arbeit jedoch deutlich früher. Vielleicht besteht genau darin eines der größten Missverständnisse moderner Infrastruktur. Wir behandeln einen HTTP-Request häufig so, als wäre er der Anfang einer Verbindung. Tatsächlich ist er einer ihrer letzten Schritte.

Betrachten wir den Aufbau einer HTTPS-Verbindung. Nicht aus Sicht eines Browsers. Sondern aus Sicht einer Edge-Plattform.

Browser
    │
    ▼
TCP Three-Way Handshake
    │
    ▼
TLS Handshake
    │
    ▼
HTTP Request
    │
    ▼
Layer 7 Verarbeitung
    │
    ▼
Backend Auswahl
    │
    ▼
Compute

Interessanterweise existiert HTTP während eines erheblichen Teils dieser Kommunikation überhaupt nicht. Bevor der Browser den ersten Header übertragen kann, muss zunächst eine TCP-Verbindung entstehen. Beide Kommunikationspartner handeln Sequenznummern aus, bestätigen gegenseitig ihre Erreichbarkeit und etablieren einen zuverlässigen Transportkanal. Erst danach beginnt TLS mit dem Austausch kryptographischer Parameter, der Aushandlung unterstützter Cipher Suites sowie der Validierung des Serverzertifikats. Erst wenn auch dieser Vorgang erfolgreich abgeschlossen wurde, erhält die Plattform erstmals Zugriff auf Anwendungsdaten. Die Reihenfolge erscheint selbstverständlich. Ihre Konsequenzen werden dagegen häufig unterschätzt.

Solange eine Verbindung ausschließlich aus TCP-Segmenten besteht, besitzt eine Plattform erstaunlich wenig Informationen. Sie kennt Quell- und Zieladresse. Sie kennt Quell- und Zielport. Sie kennt Sequenznummern. Vielleicht kennt sie bereits TCP-Optionen oder ECN-Markierungen. Mehr jedoch nicht. Sie weiß weder, welche URL später aufgerufen wird, noch welche Host-Domain angesprochen werden soll oder welcher Benutzer sich hinter der Verbindung verbirgt. Diese Informationen existieren schlicht noch nicht. Dennoch muss die Plattform bereits Entscheidungen treffen. Soll diese Verbindung überhaupt angenommen werden? Existiert ausreichend Kapazität? Handelt es sich möglicherweise um einen volumetrischen Angriff? Sind SYN-Cookies erforderlich? Muss Traffic bereits auf Layer 4 verteilt werden? Interessanterweise entstehen all diese Entscheidungen vollständig unabhängig vom eigentlichen Anwendungsprotokoll.

Erst mit Beginn des TLS-Handshakes verändert sich dieses Bild. Zum ersten Mal besitzt die Plattform Informationen, die über reine Transportparameter hinausgehen. Im ClientHello befinden sich beispielsweise Angaben über unterstützte Protokollversionen, Cipher Suites oder Erweiterungen wie Server Name Indication (SNI), durch die ein Client bereits während des Handshakes mitteilen kann, welchen Hostnamen er erreichen möchte. Damit entsteht erstmals Kontext. Nicht viel. Aber ausreichend, um weitere Entscheidungen treffen zu können. Soll dieses Zertifikat verwendet werden? Ist HTTP/2 möglich? Wird HTTP/3 angeboten? Soll die Verbindung aufgrund kryptographischer Richtlinien bereits hier beendet werden? Gerade SNI hat die Architektur moderner Plattformen nachhaltig verändert. Früher bedeutete eine öffentliche IP-Adresse häufig genau eine Anwendung. Heute teilen sich unter Umständen hunderte oder sogar tausende Anwendungen dieselbe Adresse. Nicht DNS entscheidet darüber, welche Anwendung gemeint ist. Nicht Routing. Sondern häufig erst die TLS-Aushandlung.

Erst nach erfolgreichem Abschluss des TLS-Handshakes entsteht schließlich das, was wir landläufig als HTTP-Request bezeichnen. Jetzt liegen erstmals Header vor. Cookies. Methoden. URLs. Query-Parameter. JWTs. Host-Header. Und damit beginnt eine vollkommen andere Klasse von Entscheidungen.

TCP

↓

TLS

↓

HTTP

↓

GET /api/v1/users

Host: api.example.de

Authorization: Bearer …

Erst jetzt besitzt eine Plattform genügend Informationen, um Layer-7-Routing sinnvoll durchführen zu können. Erst jetzt kann eine Web Application Firewall Regeln auf konkrete URLs anwenden. Erst jetzt werden Rate Limits pro Benutzer oder API-Key möglich. Erst jetzt lässt sich entscheiden, ob /api und /dashboard überhaupt dieselbe Anwendung erreichen sollen. Vielleicht erklärt genau das, weshalb Layer-4- und Layer-7-Loadbalancing trotz ähnlicher Bezeichnung zwei grundsätzlich unterschiedliche Probleme lösen.

Layer 4 betrachtet ausschließlich Transportinformationen.

Quell-IP
Ziel-IP
Quell-Port
Ziel-Port
TCP/UDP

Layer 7 betrachtet dagegen das eigentliche Anwendungsprotokoll.

HTTP-Methode
Host
URL
Header
Cookies
Body

Diese Unterscheidung wirkt auf den ersten Blick technisch. Architektonisch besitzt sie jedoch erhebliche Konsequenzen. Ein Layer-4-Loadbalancer kann Millionen Verbindungen pro Sekunde weiterleiten, ohne jemals zu wissen, welche Anwendung dahinter betrieben wird. Ein Layer-7-Proxy kennt dagegen die vollständige HTTP-Kommunikation, bezahlt diese Flexibilität jedoch mit zusätzlicher Verarbeitung, TLS-Terminierung und deutlich größerem Kontext. Welche Variante die bessere ist, lässt sich deshalb nicht allgemein beantworten. Sie beantworten unterschiedliche Fragen.

Vielleicht liegt genau darin eine der wichtigsten Architekturentscheidungen moderner Edge-Plattformen. Nicht jede Verbindung benötigt dieselbe Verarbeitung. Nicht jeder Dienst benötigt Layer 7. Nicht jede Anwendung profitiert von einer vollständigen HTTP-Analyse. TCP-Datenbanken. gRPC. MQTT. DNS. HTTP. Jedes dieser Protokolle besitzt andere Anforderungen. Eine Plattform sollte deshalb möglichst früh entscheiden können, welche Informationen tatsächlich benötigt werden und welche Verarbeitungsschritte entfallen können. Genau deshalb beginnt eine Edge-Plattform nicht mit HTTP. Sie beginnt mit einer Verbindung. Und sie erweitert ihren Wissensstand Schritt für Schritt, während dieselbe Verbindung immer mehr Kontext liefert.

Vielleicht ist genau dieses schrittweise Entstehen von Informationen einer der Gründe, weshalb sich moderne Plattformarchitektur kaum noch sinnvoll als Kette einzelner Produkte beschreiben lässt. TCP kennt keine HTTP-Header. TLS kennt keine Kubernetes-Services. Layer 4 kennt keine URLs. Layer 7 kennt keine BGP-Routen. Und dennoch baut jede dieser Schichten unmittelbar auf den Entscheidungen ihrer Vorgänger auf. Nicht als lose Aneinanderreihung technischer Komponenten. Sondern als kontinuierlicher Verarbeitungsprozess, bei dem jede Ebene genau die Informationen nutzt, die ihr zu diesem Zeitpunkt überhaupt zur Verfügung stehen. Vielleicht erklärt genau das auch, weshalb wir heute deutlich häufiger über Plattformen als über einzelne Produkte sprechen. Denn ein Request entsteht nicht in einem einzigen Moment. Er entsteht schrittweise. Mit jedem Paket. Mit jedem Handshake. Mit jeder Information, die das Netzwerk preisgibt. Und genau darin liegt die eigentliche Aufgabe moderner Edge-Plattformen: Nicht möglichst viele Funktionen bereitzustellen. Sondern zu jedem Zeitpunkt genau die Entscheidungen zu treffen, für die bereits ausreichend Informationen vorhanden sind.