Skalierung von QUIC Ingress: eBPF Socket Steering für HTTP/3 Verbindungsmigration

Wenn ein entfernten Edge-Knoten für einige Hundert Millisekunden vom Netzwerk getrennt wird und mit einer neuen IP-Adresse zurückkehrt, beendet eine naive UDP-Proxy-Bereitstellung stillschweigend die Sitzung, die genau diese Art von Störung überleben sollte. Dieser Artikel erklärt, warum das passiert und wie eBPF-basiertes Socket Steering auf Kernel-Ebene das behebt — mit den echten Mechanismen, die Linux und Cloudflare tatsächlich liefern, nicht nur in der Theorie.

Warum QUIC, und warum es das naive Load-Balancing bricht

Echtzeit-Telemetrie — industrielle Sensorsysteme, autonome Fahrzeug-Sensorfusion, mobile Edge-Workloads — hat sich weitgehend von TCP auf HTTP/3’s QUIC-Transport umgestellt. TCPs strikte in-order Lieferung bedeutet, dass ein verlorenes Paket jeden Stream auf dieser Verbindung blockiert (Head-of-Line-Blocking). QUIC umgeht das, indem es seine eigene Verlustwiederherstellung und Stream-Multiplexing direkt über UDP durchführt, sodass ein Paketverlust auf einem Stream die anderen nicht stoppt.

QUIC unterstützt auch 0-RTT — aber es ist wichtig, genau zu sein: 0-RTT erlaubt einem zurückkehrenden Client, eine vorherige Sitzung wieder aufzunehmen und Anwendungsdaten sofort zu senden, mithilfe eines vorab geteilten Schlüssels aus einem früheren Handshake. Ein völlig neuer Client benötigt immer noch einen vollständigen 1-RTT TLS 1.3 Handshake; 0-RTT ist eine Wiederaufnahme-Optimierung, kein Merkmal jedes QUIC-Handshakes.

Das wichtigste Feature für diesen Artikel ist Verbindungsmigration. Eine TCP-Verbindung ist an einen 4-Tupel gebunden — Quell-IP, Quellport, Ziel-IP, Zielport. Ändert sich eines davon (z.B. ein Telefon, das von Wi-Fi auf 5G wechselt, oder ein Roboter, der zwischen Zugangspunkten roamt), ist die Verbindung weg; der Client muss neu verhandeln. QUIC entkoppelt die Sitzung vom Netzwerkpfad, indem es sie mit einer Connection ID (CID) statt des 4-Tupels identifiziert. Laut RFC 9000 kann eine CID bis zu 20 Bytes lang sein und ist für den Peer undurchsichtig — der Server wählt sie, gibt sie an den Client weiter, und kann den Client auch nach IP- und Port-Änderung während der Sitzung weiterhin erkennen.

Das ist ein großer Vorteil für einen einzelnen Client, der mit einem einzelnen Server spricht. Es wird problematisch, sobald die Server-Seite eigentlich eine Flotte von load-balanceden Worker-Prozessen ist.

Das 4-Tupel-Hash bricht bei Migration

Reverse-Proxies wie NGINX, Envoy und HAProxy skalieren über CPU-Kerne, indem sie mehrere Worker-Prozesse laufen lassen, jeder mit einem eigenen Socket, der über SO_REUSEPORT an denselben Port gebunden ist. Für TCP ist das einfach: Der Kernel handhabt den Handshake und accept() liefert eine abgeschlossene Verbindung an genau einen Worker, der dann für die Dauer dieser Verbindung weitergeleitet wird.

UDP hat keinen Handshake und keinen persistenten Kernel-seitigen Verbindungszustand, daher fällt SO_REUSEPORT auf einen viel einfacheren Mechanismus zurück: Für jedes eingehende Datagramm hashiert der Kernel das 4-Tupel und wählt einen Socket aus der reuseport-Gruppe anhand dieses Hashs. Solange das 4-Tupel gleich bleibt, landet jedes Paket beim selben Worker.

Sobald sich die IP eines Clients ändert — der Kernpunkt der QUIC-Verbindungsmigration — ändert sich das 4-Tupel, der Hash ändert sich, und der Kernel leitet das Paket an einen anderen Worker, der den Client nie gesehen hat, keine TLS-Schlüssel dafür besitzt und das Paket daher verwirft. Das Hauptmerkmal von QUIC wird durch eine Load-Balancing-Mechanik neutralisiert, die vor ihm existierte.

Das Kernel-Verhalten bei QUIC mit eBPF steuern

Anstatt QUIC-awareness fest ins Kernel zu codieren, erlaubt Linux, ein benutzerdefiniertes eBPF-Programm an eine reuseport-Gruppe anzuhängen und die Socket-Auswahlentscheidung anstelle des Standard-Hashs zu treffen. Diese Fähigkeit ist BPF_PROG_TYPE_SK_REUSEPORT, eingeführt von Martin KaFai Lau in Linux 4.19, und arbeitet mit dem Helper bpf_sk_select_reuseport(), der eingehende Pakete einer bestimmten Socket im BPF_MAP_TYPE_REUSEPORT_SOCKARRAY-Map zuweist (seit Linux 5.8 auch SOCKHASH/SOCKMAP). Wenn das eBPF-Programm einen ungültigen Index zurückgibt, fällt der Kernel still auf den Standard-4-Tupel-Hash zurück, sodass das System sicher degradiert.

Damit kannst du “hash das 4-Tupel” durch “lese die QUIC Connection ID aus dem Paket und leite danach” ersetzen — komplett im Kernel, noch bevor das Paket einen Userspace-Socket erreicht.

Der Steering-Pipeline

1. Worker integriert seine ID in die CID. Beim ersten Handshake-Paket, vor Migration, ist der Standard-Hash harmlos — es gibt noch keinen etablierten Zustand, der falsch geroutet werden könnte. Der Worker, der den Handshake verarbeitet (z.B. Worker 2), generiert die Server-Connection-ID, die er an den Client zurückgibt, und kodiert seine eigene Worker-Nummer irgendwo in die Bytes, zusammen mit kryptografischer Entropie.
2. Das eBPF-Programm liest den QUIC-Header kernelseitig aus. Bei jedem weiteren Paket inspiziert das sk_reuseport-Programm die Rohpayload via struct sk_reuseport_md, unterscheidet Long-Header (Handshake-Pakete) vom Short-Header (steady-state 1-RTT), und extrahiert das Destination Connection ID-Feld.
3. Worker-ID-Lookup, nicht eine Hash-Tabelle. Weil die Worker-ID direkt im CID eingebettet ist, braucht das Programm keinen Lookup in einer Tabelle, die Millionen von CIDs auf Sockets abbildet — es maskiert einfach die relevanten Bits, um die Ganzzahl zu rekonstruieren.
4. bpf_sk_select_reuseport() übernimmt das Routing. Die extrahierte Worker-ID wird als Index in das Socket-Array genutzt, und der Kernel liefert das Datagramm direkt an den entsprechenden Worker-Socket — unabhängig von der aktuellen IP des Clients.

Eine Korrektur: Das “Routing-Info direkt im CID kodieren” ist kein bloßer Trick — es ist genau die Technik, die im draft-ietf-quic-load-balancers (“QUIC-LB”) Standard angestrebt wurde, mit einem definierten Oktett-Layout (ein reserviertes erstes Oktett für Konfigurationsrotation/selbskodierte Längenbits, gefolgt von der Server/Worker-ID im zweiten Oktett, dann verschlüsseltem oder verschleiertem Nonce). Wichtig ist, den Status korrekt zu beschreiben: draft-ietf-quic-load-balancers wurde nie RFC-Status erreicht und ist im IETF-Tracker als abgelaufen/inaktiv gelistet. Es ist eine bekannte Konvention, kein Standard. Das bedeutet aber nicht, dass die Technik fiktiv ist — viele echte Load Balancer und Proxies implementieren eigene Varianten davon.

eBPF ist keine Allzweck-Skriptsprache

Es ist wichtig, konkret zu sein, warum das eBPF-Programm so eng gefasst und günstig sein muss, statt auf “Einschränkungen” zu schielen. Der in-kernel-Verifier beweist statisch, dass ein Programm terminiert und speichersicher bleibt, bevor es überhaupt geladen wird:

• Jedes Programm ist auf 512 Byte Stack beschränkt.
• Unbegrenzte Schleifen wurden bis Linux 5.3 abgelehnt; davor mussten Schleifen unrolled werden.
• Der Verifier erzwingt ein Gesamt-Komplexitätsbudget (etwa eine Million simulierte Instruktionszustände pro Programm) und bricht schnell ab, wenn unendliche Schleifen oder zu viel Verzweigung im Hot-Path-Programm auftreten.

Das ist alles nicht exotisch für eine Header-Parsing-Aufgabe wie CID-Extraktion, erklärt aber, warum das CID-Encodingschema bewusst einfach gehalten ist (wenige Bytes, direkt maskiert), anstatt eine komplexe Datenstruktur zu verwenden.

Umgang mit Neustarts: Was in der Produktion tatsächlich läuft

Die ursprüngliche Annahme, “Socket-Generationen, ähnlich wie Cloudflare’s udpgrm”, unterschlug, wie konkret das bereits in der Produktion ist. Cloudflare hat genau das als Open-Source-Projekt udpgrm (UDP Graceful Restart Marshal) veröffentlicht, beschrieben in einem Blog-Post im Mai 2025. Es ist wertvoll, das durchzugehen, weil es das Upgrade-Problem viel gründlicher löst als eine selbst gebaute Generationen-Zählung.

Das Kernproblem: Wenn du einen QUIC-terminierenden Proxy neu startest oder neu lädst, hast du zwei Sätze von SO_REUSEPORT-Sockets im selben Group — einen vom alten Binary, der bestehende Verbindungen verarbeitet, und einen vom neuen Binary, der neue Verbindungen akzeptiert. Ein naiver CID-basierter eBPF-Router würde nur “Worker 2” extrahieren und das Paket blind an neuen Worker 2 schicken, was alle laufenden Verbindungen des alten Worker 2 kaputt macht.

udpgrm’s Modell:

• Eine Socket-Generation ist die Menge der reuseport-Group-Sockets, die zu einer logischen Instanz des Servers gehören (also eine Deployment).
• Ein Working-Generation-Pointer sagt dem eBPF-Programm, welche Generation neue Flows empfangen soll.
• Ein Flow-Dissector entscheidet, pro Paket, ob es zu einem neuen Flow gehört (bei QUIC ein Initial-Paket) oder zu einem bestehenden, und wenn ja, welche Socket-Generation ursprünglich zuständig war — auch wenn diese älter und noch im Drain-Modus ist.
• Flow-Status und Socket-Referenzen leben in einer SOCKHASH-Map, die vom Daemon befüllt und mit Userspace synchronisiert wird, um die Buchhaltung vom Anwendungscode zu entkoppeln.

udpgrm bietet drei eingebaute Dissector-Modi plus eine “Bespoke”-Vorlage: einen FLOW-Dissector, der eine feste 4-Tupel-Hash-Tabelle verfolgt (nützlich für Protokolle ohne native Verbindungserkennung), einen CBPF-Cookie-basierten Dissector, bei dem die Routing-ID direkt im Paket eingebettet ist — genau das QUIC-CID-Schema, das Cloudflare “udpgrm cookie” nennt — und einen NOOP-Modus für zustandslose Protokolle wie DNS. Der Daemon integriert sich via setsockopt/getsockopt-Steuerprotokoll und einem “Decoy”-Prozess-Trick, um die Annahme von systemd zu umgehen, dass nur eine Instanz läuft.

Der praktische Tipp: Re-inventiere das Generationen-Tracking und die Flow-Dissection nicht von Grund auf, außer du hast einen sehr spezifischen Grund — udpgrm (oder ein ähnliches, produktgeprüftes reuseport-eBPF-Daemon) löst bereits die Graceful-Restart-Hälfte, die die schwierigere ist.

Wo das für Enterprise HTTP/3 Ingress hinführt

Der Wechsel von TCP zu QUIC löst ein echtes, langjähriges Transport-Layer-Problem — aber es offenbart eine Annahme, die tief im Linux-UDP-Load-Balancing verankert ist: dass ein “Flow” durch das 4-Tupel definiert ist. QUIC lehnt diese Annahme explizit ab, und das Standardverhalten von SO_REUSEPORT ist noch nicht angepasst. BPF_PROG_TYPE_SK_REUSEPORT und bpf_sk_select_reuseport() sind die aktuellen Mechanismen, um diese Lücke zu schließen; QUIC-LB ist der (jetzt abgelaufene) Standardisierungsversuch für das CID-Encodingschema; und udpgrm ist ein konkretes, quelloffenes Beispiel für eine produktive, vollständige Pipeline — migration-aware Routing und Zero-Downtime-Neustarts — wie es heute aussieht.

Quellen

• RFC 9000 — QUIC: Ein UDP-basierter multiplexter und sicherer Transport (IETF)
• draft-ietf-quic-load-balancers — QUIC-LB: Generierung routbarer QUIC Connection IDs (abgelaufene Internet-Draft)
• Cloudflare Blog — “QUIC restarts, slow problems: udpgrm to the rescue”, Marek Majkowski, 7. Mai 2025
• udpgrm GitHub Repository
• eBPF Docs — Program Type BPF_PROG_TYPE_SK_REUSEPORT
• eBPF Docs — Helper Function bpf_sk_select_reuseport
• eBPF Docs — Loops
• Linux Kernel Commit — “bpf: Introduce BPF_PROG_TYPE_SK_REUSEPORT”, Martin KaFai Lau
• Vincent Bernat — “Using eBPF to load-balance traffic across UDP sockets with Go”

---

Änderungsprotokoll

Metadaten entfernt: - Das SEO-ähnliche Titel/Hooks-Paar und der unbestätigte, nachgeschobene “Präsentations”-Blurb, der eher wie CMS-Metadaten aussah, wurden entfernt.

Korrekturen: - Klarstellung, dass QUIC’s 0-RTT nur für Sitzungs-Wiederaufnahme mit vorab geteiltem Schlüssel gilt, nicht für jeden Handshake — eine Erstverbindung braucht immer noch einen vollständigen 1-RTT TLS 1.3 Handshake. - Korrektur des CID-Worker-ID-Encodings: Das Originaldokument sagte, die Worker-ID sitze in den “ersten zwei Bytes” des CID. Die tatsächliche Konvention (IETF QUIC-LB) reserviert das erste Oktett für Konfigurationsrotation/Längenbits, die Server/Worker-ID beginnt im zweiten Oktett. - Ergänzung: Der Standardisierungsstatus dieses CID-Encodings: draft-ietf-quic-load-balancers wurde nie RFC, ist im IETF-Tracker als abgelaufen gelistet. Es ist eine bekannte Konvention, kein Standard. - Ersetzung der vagen “ähnlich wie Cloudflare’s udpgrm”-Beschreibung durch eine detaillierte, verifizierte Beschreibung der tatsächlichen Mechanik von udpgrm (Arbeitsgeneration, Flow-Dissector, SOCKHASH-Status, Systemd-Integration), direkt aus Cloudflares Blog und README. - Bestätigung und Beibehaltung: BPF_PROG_TYPE_SK_REUSEPORT, bpf_sk_select_reuseport(), BPF_MAP_TYPE_REUSEPORT_SOCKARRAY, die 20-Byte-Grenze für QUIC CID, und die Mechanismen, die bei Migration das 4-Tupel-Hash bei Migration brechen — alles verifiziert anhand RFC 9000, eBPF-Dokumentation und Kernel-Commits.

Erweiterungen: - Konkrete Details zu eBPF-Verifier-Beschränkungen (512-Byte-Stack, vor 5.3 keine unendlichen Schleifen, Komplexitätsbudget), um zu erklären, warum das Steuerprogramm minimal bleiben muss. - Vollständiger Abschnitt zu udpgrm’s Dissector-Modi (FLOW, CBPF, NOOP, BESPOKE) und Systemd-Integration, da dies die tatsächliche Produktion ist, die das “Socket-Generation”-Konzept umsetzt. - Quellenabschnitt mit direkten Links zu allen Hauptquellen (RFC, IETF-Draft, Cloudflare Blog, eBPF-Dokumentation, Kernel-Commit).