Multiplexed Multi-Tenant Tunnels: Mehr als 50 lokale Dienste über eine einzige QUIC-Verbindung mit HTTP/3 Extended CONNECT betreiben

Das Freigeben einiger lokaler Dienste im Internet ist einfach. Dutzende zuverlässig zu exponieren, ist schwieriger. Eine typische Entwicklermaschine oder Edge-Gateway kann gleichzeitig REST-APIs, gRPC-Endpunkte, WebSocket-Server und Admin-UIs laufen lassen. Jeder Dienst auf einen eigenen Port, eine eigene TCP-Verbindung oder Tunnel-Prozess zu legen, wird schnell teuer.

Dieser Artikel zeigt, wie moderne Tunnel das Problem lösen. Sie multiplexen viele Dienste über eine ausgehende Verbindung, und diese Verbindung ist zunehmend QUIC auf einem einzigen UDP-Port (meist 443). Außerdem erklärt er, was HTTP/3 Extended CONNECT macht und nicht macht, da die Details für das Tunnel-Design entscheidend sind.

---

Das Flaschenhals-Problem: Ein Port oder eine Verbindung pro Dienst

Drei Probleme treten auf, wenn ein Tunnel mit der Anzahl der exponierten Dienste skaliert.

1. Overhead pro Verbindung

Wenn jeder Dienst eine eigene TCP + TLS-Verbindung erhält, entstehen Kosten für:

• Handshake-Kosten. Jeder Verbindungsaufbau wiederholt TCP- und TLS-Handshakes.
• Kernel-Status und Dateideskriptoren. Jede Verbindung hält einen Socket, Puffer und einen TCP-Status. Besonders bei kleinen Gateways und Laptops relevant.
• NAT- und Firewall-Status. Jede zusätzliche Verbindung erhöht die Einträge in der Status-Tabelle und NAT-Mappings, die schließlich ablaufen.

2. Port-Sprawl

Klassisches SSH-Forwarding (-L/-R) benötigt für jeden weitergeleiteten Dienst einen eigenen Listening-Port. Das bedeutet mehr Firewall-Regeln, Port-Management und ungewöhnlichen Traffic, den restriktive Netzwerke oft blockieren.

3. TCP Head-of-Line (HoL) Blocking

Multiplexing vieler logischer Streams über eine TCP-Verbindung, wie HTTP/2 es tut, löst das Verbindungsproblem. Es entsteht jedoch ein neues. TCP liefert einen einzigen geordneten Byte-Stream, bei Paketverlust wartet die gesamte Verbindung auf die Retransmission. Eine große Dateiübertragung kann so eine latenzempfindliche API-Anfrage verzögern, die den gleichen Tunnel nutzt.

Was bestehende Tunnel bereits tun

Die meisten ausgereiften Tunnel-Produkte multiplexen bereits viele Dienste über eine Verbindung statt für jeden Dienst eine zu öffnen:

• ngrok nutzt ein Stream-Multiplexing-Protokoll namens muxado, das in den Open-Source-Rust- und Go-SDKs als das Protokoll beschrieben wird, das ngrok-Tunnel antreibt.
• Cloudflare Tunnel (cloudflared) öffnet vier ausgehende Verbindungen zu mindestens zwei Cloudflare-Rechenzentren auf Port 7844. Der Standardmodus --protocol auto bevorzugt QUIC über UDP und fällt auf HTTP/2 zurück, wenn UDP-Verbindungen nicht aufgebaut werden können. Das legacy h2mux-Protokoll wird nicht mehr unterstützt. Der QUIC-Transport basiert auf der quic-go-Bibliothek.

Die Idee dieses Artikels, eine Verbindung, die viele Dienste trägt, ist also etablierte Praxis. Die offene Frage ist, auf welcher Multiplexing-Schicht man aufbauen soll und wie.

---

Warum QUIC das Bild verändert

QUIC (RFC 9000) läuft über UDP und integriert TLS 1.3 (RFC 9001). Es hat native Streams, und Verlustwiederherstellung wird pro Stream verfolgt. Wenn ein Paket Daten für einen Stream verliert, wartet nur dieser Stream auf die Retransmission. Andere Streams auf derselben Verbindung liefern weiterhin Daten an die Anwendung.

Zwei Hinweise halten die übliche Aussage „Null Head-of-Line Blocking“ ehrlich:

• Reihenfolge innerhalb eines Streams bleibt gewahrt. Jeder Stream ist ein eigener geordneter Byte-Stream, daher verzögert ein Paketverlust nur diesen Stream.
• HTTP/3 Header-Kompression kann wieder einige Blockierungen einführen. QPACK (RFC 9204) wurde entwickelt, um HoL-Blocking im Vergleich zu HPACK zu reduzieren. Verweise auf die dynamische Tabelle können einen Stream blockieren, wenn der Decoder das Update noch nicht erhalten hat. Implementierungen begrenzen dies mit der SETTINGS_QPACK_BLOCKED_STREAMS-Einstellung.

Für Tunnel bringt QUIC weitere Vorteile:

Eigenschaft	Warum es für einen Tunnel wichtig ist
Eine UDP-Socket, eine Verbindung	Ein einzelner 4-Tupel für NATs und eine Firewall-Regel (UDP 443).
Verlustwiederherstellung pro Stream	Ein gestoppter Bulk-Transfer friert andere Dienste nicht ein.
1-RTT Handshake, optional 0-RTT Wiederaufnahme	Schnellere Wiederverbindungen. Vorsicht bei 0-RTT, da frühe Daten wiederholt werden können.
Verbindungs-IDs und Migration	Eine Verbindung kann bei Netzwerkwechsel des Clients überleben, z.B. Wi-Fi zu Mobilfunk, nach Pfad-Validierung (RFC 9000).
Eingebaute DPLPMTUD	Paketgrößen können wachsen, wenn der Pfad es zulässt.

Verbindungs-IDs und Migration

QUIC-Verbindungen werden durch Connection IDs identifiziert, nicht nur durch die IP/Port-4-Tupel. Eine Connection ID ist variabel lang, bis zu 20 Bytes laut RFC 9000. Sie ist kein fester 64-Bit-Wert.

Wenn sich der Netzwerkpfad des Agents ändert, kann der Client den neuen Pfad prüfen und migrieren. Die Endpunkte führen zuerst eine Pfad-Validierung durch, sodass Migration nicht sofort oder unbedingbar erfolgt. Anwendungen und Middleboxes können ebenfalls eingreifen.

---

HTTP/3 Extended CONNECT: Was es ist

Ein reines HTTP CONNECT öffnet einen TCP-Tunnel durch einen Proxy. Extended CONNECT wurde für HTTP/2 in RFC 8441 definiert und fügt einen :protocol Pseudo-Header hinzu, sodass ein einzelner CONNECT-Stream etwas anderes als rohes TCP tragen kann. RFC 9220 bringt es zu HTTP/3, indem es die Einstellung SETTINGS_ENABLE_CONNECT_PROTOCOL mit dem Wert 0x08 registriert, derselben Wert wie in HTTP/2. Trotz des Titels („Bootstrapping WebSockets with HTTP/3“) ist der Mechanismus allgemein. Weitere Spezifikationen bauen darauf auf:

• WebSockets über HTTP/3 (:protocol = websocket), der ursprüngliche Anwendungsfall.
• CONNECT-UDP (RFC 9298, „Proxying UDP in HTTP“), das UDP-Datagramme tunnelt.
• CONNECT-IP (RFC 9484, „Proxying IP in HTTP“), das IP-Pakete tunnelt.
• WebTransport über HTTP/3, derzeit ein IETF-Entwurf (draft-ietf-webtrans-http3, Revision 16 im Juli 2026), das jede Sitzung mit einer Extended CONNECT-Anfrage startet.

Eine Extended CONNECT-Anfrage trägt diese Pseudo-Header:

Pseudo-Header	Beispiel	Hinweise
:method	CONNECT
:protocol	websocket, connect-udp, webtransport oder ein privater Token wie tunnel-v1	Gibt das auf dem Stream gesprochene Protokoll an. tunnel-v1 ist ein Beispiel für eine private Gestaltung, kein registrierter Wert.
:scheme	https	Für Extended CONNECT erforderlich.
:authority	service-50.tunnels.example.com	Zielhost, den ein Tunnel für Routing nutzen kann.
:path	/	Für Extended CONNECT erforderlich.

Beide Seiten signalisieren Unterstützung durch das Senden der Einstellung im HTTP/3 SETTINGS-Frame. Ein Client darf eine Extended CONNECT-Anfrage nur senden, nachdem die Server-Einstellung eingetroffen ist. quic-go prüft dies vor dem Senden.

---

Das Richtungsproblem: Wer öffnet den Stream?

Der wichtigste Designpunkt, und einer, der leicht falsch gemacht wird, ist wer Streams öffnen darf.

In HTTP/3 sind Request-Streams client-initiierte bidirektionale QUIC-Streams. Die erste Anfrage läuft auf Stream 0, dann 4, 8, 12 usw. RFC 9114 sagt, HTTP/3 nutzt keine server-initiierte bidirektionale Streams, und ein Server, der eine erhält, muss sie als Verbindungsfehler H3_STREAM_CREATION_ERROR behandeln, sofern keine Erweiterung ausgehandelt wurde.

Ein Tunnel macht das schwierig. Der Agent wählt aus (hinter NAT), also ist der Agent der QUIC- und HTTP/3 Client. Der Edge ist der Server. Aber öffentliche Anfragen kommen am Edge an, und der Edge muss sie zum Agent weiterleiten. Im plain HTTP/3 kann der Edge keinen Request-Stream zum Agent öffnen.

Designs, die das umgehen:

1. Roh-QUIC-Streams mit einem eigenen Anwendungsprotokoll. QUIC erlaubt es beiden Endpunkten, bidirektionale Streams zu öffnen. Der Edge öffnet einen pro öffentlicher Anfrage und spricht sein eigenes Framing darauf. Das ist eine allgemeine QUIC-Fähigkeit, nicht Extended CONNECT. Es passt am besten zu Tunneln, und cloudflared baut seinen QUIC-Transport auf quic-go.
2. Ein Pool vorgeöffneter Extended CONNECT-Streams. Der Agent öffnet mehrere idle Extended CONNECT-Streams, z.B. mit :protocol = tunnel-v1. Der Edge reserviert sie. Bei einer öffentlichen Anfrage für einen Dienst beansprucht der Edge einen reservierten Stream, schreibt eine kleine Präambel mit Zielservice und relayed die Bytes. Der Agent liest die Präambel, verbindet sich zum lokalen Dienst, kopiert bidirektional und erneuert den Pool. Das bleibt innerhalb von HTTP/3, erfordert aber Pool-Management.
3. WebTransport über HTTP/3. Der Agent öffnet eine Extended CONNECT-Anfrage mit :protocol = webtransport. Innerhalb dieser Sitzung kann jeder Endpunkt Streams öffnen, da der Draft dies auf HTTP/3’s ungenutzten server-initiierte Streams aufbaut. Der Draft ist noch ein Entwurf, Änderungen sind zu erwarten. WebTransport über HTTP/3 unterstützt kein 0-RTT.
4. Reverse HTTP/3-Entwürfe. Einzelne Entwürfe beschreiben HTTP/3 mit umgekehrten Rollen, und „HTTP/3 über WebTransport“, sodass ein Server Anfragen an einen Client senden kann. Diese sind Entwürfe und noch nicht breit eingesetzt.

Für einen Tunnel sind Option 1 oder 2 heute die pragmatische Wahl. Option 3 ist attraktiv, wenn Sie standardbrowserkompatible Verkabelung wollen und den Draft-Status akzeptieren.

Ablauf mit einem Stream-Pool (Option 2)

   Öffentliches Client                Edge (QUIC/H3-Server)               Agent (QUIC/H3-Client)
        |                               |                                   |
        |                               |== QUIC-Handshake, UDP 443 =======|
        |                               |== SETTINGS (ENABLE_CONNECT) =====|
        |                               |== CONNECT :protocol=tunnel-v1 ===|  Stream 0 (geparkt)
        |                               |== CONNECT :protocol=tunnel-v1 ===|  Stream 4 (geparkt)
        |  GET https://api.example.com  |                                   |
        |------------------------------|                                   |
        |                               |-- Anspruch auf Stream 0, sende „api“ ----|
        |                               |                                   |-- dial 127.0.0.1:8080
        |---------- Antwort ----------|-------- Bytes auf Stream 0 -------|
        |                               |== Agent öffnet Ersatz-Stream =====|  Stream 8

Jede öffentliche Anfrage entspricht einem QUIC-Stream. Fünfzig Dienste oder fünfzig gleichzeitige Anfragen teilen sich eine UDP-Socket und eine QUIC-Verbindung.

---

Was „50+“ in der Praxis bedeutet

Fünfzig ist kein Protokoll-Limit. Es ist eine praktische Zahl, die unter einem üblichen Standard liegt. In quic-go ist quic.Config.MaxIncomingStreams standardmäßig auf 100 gleichzeitige bidirektionale Streams gesetzt, die der Peer öffnen darf. Wenn Sie mehr gleichzeitige Anfragen erwarten, erhöhen Sie das gezielt auf der Seite, die die Streams empfängt.

Die Dokumentation von quic-go listet diese Flusskontroll-Standards:

Einstellung	Standard
InitialStreamReceiveWindow	512 KB
MaxStreamReceiveWindow	6 MB
InitialConnectionReceiveWindow	512 KB
MaxConnectionReceiveWindow	15 MB
MaxIncomingStreams	100

QUIC wendet Flusskontrolle auf zwei Ebenen an: pro Stream und pro Verbindung. Das Stream-Limit verhindert, dass ein Dienst den gesamten Puffer verbraucht. Das Verbindungs-Limit begrenzt die Gesamtsumme. Das Verbindungsfenster sollte für die erwartete aktive Anzahl an Streams dimensioniert sein, nicht für die maximale Summe aller Streams. Ist es zu klein, konkurrieren Streams um Verbindungs-Kredit, und die Durchsatzrate sinkt.

Feinabstimmung des Hosts

QUIC-Implementierungen laufen im User-Space über UDP, daher sind die Kernel-UDP-Socket-Puffer relevant. quic-go versucht, seine Socket-Puffer zu vergrößern, kann aber nur bis zu den Kernel-Limits rmem_max und wmem_max gehen, die auf Linux standardmäßig klein sind. Die Empfehlung lautet:

sysctl -w net.core.rmem_max=7500000
sysctl -w net.core.wmem_max=7500000

Damit steigen die Limits auf etwa 7,5 MB. Persistieren Sie diese in /etc/sysctl.d/, damit sie nach einem Reboot erhalten bleiben. Cloudflare’s eigene Tools verweisen Nutzer bei kleinen Puffern auf die gleiche quic-go-Pufferempfehlung.

Staukontrolle

Verlassen Sie sich nicht auf eine einfache Einstellung wie BBR. Der Linux-tcp_congestion_control-Sysctl betrifft nur TCP, während die Staukontrolle von QUIC in der QUIC-Bibliothek liegt. quic-go nutzt CUBIC. Die Entwickler haben gesagt, sie planen nicht, BBR zu implementieren, obwohl die Unterstützung von BBRv3 als offenes Issue verfolgt wird. Wenn BBR für Sie wichtig ist, prüfen Sie, welche Staukontroll-Algorithmen Ihr gewählter QUIC-Stack unterstützt.

Durchsatz versus TCP

QUIC ist nicht immer schneller. User-Space-Paketverarbeitung kostet CPU, und Mainstream-Kernels haben einige UDP-Offloads, die TCP nutzt, nicht. Bei schnellen, verlustarmen Kabelverbindungen ist HTTP/3 manchmal nicht schneller als HTTP/2 und verbraucht mehr CPU. QUIC ist vor allem bei verlustreichen, hohen Latenz- oder Mobilpfaden vorteilhaft. Messen Sie auf Ihrem eigenen Netzwerk.

---

Technischer Vergleich

Dimension	SSH-Forwarding	HTTP/2 über TCP	HTTP/3 über QUIC
Transport	TCP	TCP	UDP (QUIC)
Multiplexing	Kanäle in einer TCP-Verbindung oder separate Verbindungen	Streams in einer TCP-Verbindung	Native QUIC-Streams
Verlustwirkung	Alle Kanäle auf dieser TCP-Verbindung	Alle Streams auf dieser TCP-Verbindung	Der betroffene Stream (plus Header-Kompression)
Handshake	TCP + SSH-Schlüsselaustausch und Authentifizierung	TCP + TLS	Kombinierter Transport- und TLS 1.3-Handshake, 0-RTT bei Wiederaufnahme
Netzwerkwechsel	Verbindung bricht ab	Verbindung bricht ab	Client-gesteuerte Migration mit Pfad-Validierung
Server-initiierte Streams	Ja (über Kanäle)	Nein (Push ist veraltet, Extended CONNECT ist client-initiierte)	Möglich in rohem QUIC. Nicht in einfachem HTTP/3. Möglich via WebTransport.
Firewall-Reichweite	TCP	TCP	Benötigt UDP, was manche Netzwerke blockieren

---

Der Haken: UDP ist nicht immer verfügbar

Ein QUIC-Tunnel ist nur nützlich, wenn UDP durchkommt. Schätzungen variieren, und ältere Messungen sind veraltet. Google fand in frühen Deployment-Studien, dass etwa 3–5% der Netzwerke QUIC blockieren, und Firmennetze sind bekannt dafür. Manche Unternehmensfirewalls blockieren oder drosseln UDP/443 absichtlich, damit Inspektionstools den Traffic auf TCP sehen.

Deshalb braucht es eine TCP-Fallback-Lösung. cloudflared nutzt im auto-Modus diese Strategie: Es bevorzugt QUIC und fällt auf HTTP/2 zurück, wenn UDP-Verbindungen nicht aufgebaut werden können. Ihr Agent sollte das ebenfalls tun und anzeigen, welcher Transport aktiv ist, damit Operatoren die Unterschiede nachvollziehen können.

Denken Sie auch daran, dass ein UDP-Flow durch NAT-Timeouts verloren gehen kann. Senden Sie Keepalives (QUIC PING Frames oder Anwendungs-Heartbeat), damit inaktive Tunnel nicht stillschweigend sterben.

---

Sicherheit und Multi-Tenant-Isolation

Multiplexing vieler Dienste über eine Verbindung bedeutet, dass eine kompromittierte oder falsch konfigurierte Stream nicht auf Ressourcen eines anderen Tenants zugreifen darf.

1. Authentifizieren Sie die Verbindung, nicht nur die Streams. Nutzen Sie mutual TLS oder Bearer-Token beim ersten Verbindungsaufbau. Halten Sie die Registrierung und Authentifizierung außerhalb von 0-RTT, da frühe Daten wiederholt werden können.
2. Binden Sie den Agent an die Hostnamen, die er besitzt. Der Edge sollte nur tenant-a.example.com an die Verbindung weiterleiten, die sich als Tenant A authentifiziert hat. Vertrauen Sie niemals einem vom Agent gelieferten Hostnamen für Routing, ohne ihn gegen die Berechtigungen des Tenants zu prüfen.
3. Verwenden Sie eine Allowlist im Agent. Der Agent sollte Dienstnamen auf lokale Adressen mappen und alles andere ablehnen. Insbesondere darf eine Anfrage keine beliebige Zieladresse wählen. Das verhindert Server-seitige Request-Forgery, z.B. gegen die Cloud-Metadaten-Endpoint 169.254.169.254.
4. Begrenzen Sie die Parallelität pro Tenant. QUIC’s MAX_STREAMS-Mechanismus begrenzt, wie viele Streams ein Peer öffnen darf. Fügen Sie pro-Tenant-Ratenbegrenzungen und Byte-Quoten am Edge hinzu, damit eine Flut auf einen Hostname die anderen nicht ausbremst.
5. Isolieren Sie Fehler. Ein Reset auf einem Stream sollte die Verbindung nicht zerstören. Reservieren Sie eine Verbindung auf Protocol-Verletzungen.

---

Akzeptanzkontext

HTTP/3 ist kein Nischenprodukt mehr. W3Techs berichtete im März 2026, dass etwa 38,6% der Websites HTTP/3 verwenden, und im Juli 2026 etwa 39,7%. Diese Zahlen sind „Websites, die Unterstützung anzeigen“. Request-Level-Messungen sind niedriger, und Cloudflare Radar-Daten, zusammengefasst durch eine Drittanalyse, zeigen HTTP/3 bei etwa 21% der globalen Anfragen im Q1 2026. Für Tunnel ist die wichtigste Erkenntnis, dass Browser, CDNs und große QUIC-Bibliotheken (quic-go, Google’s QUICHE und andere) ausgereift genug sind.

---

Fazit

Das Betreiben von 50+ lokalen Diensten über eine Verbindung ist ein gelöstes Problem. Reife Tunnel multiplexen bereits viele Dienste über wenige Verbindungen, und QUIC ergänzt pro-Stream-Verlustwiederherstellung, einen einzigen UDP-Port und Client-seitige Migration. Die wichtigsten Punkte sind:

• HTTP/3 Request-Streams sind client-initiierte. Ein Reverse-Tunnel braucht rohe QUIC-Streams, einen Pool vorgeöffneter Extended CONNECT-Streams oder WebTransport, nicht einen Edge, der einfach Request-Streams zum Agent öffnet.
• Extended CONNECT (RFC 8441, RFC 9220) ist ein allgemeiner Mechanismus. Es trägt WebSockets, UDP (RFC 9298), IP (RFC 9484) und WebTransport. Wählen oder definieren Sie das :protocol-Token bewusst.
• Planen Sie UDP-Blockaden ein. Bieten Sie eine TCP-Fallback-Lösung an.
• Tunen und messen Sie. Erhöhen Sie UDP-Puffer, dimensionieren Sie Flusskontrollfenster für erwartete Parallelität und benchmarken Sie vor der Annahme, dass QUIC HTTP/2 schlägt.

---

Quellen

• RFC 9220: Bootstrapping WebSockets with HTTP/3
• RFC 9298: Proxying UDP in HTTP
• RFC 9484: Proxying IP in HTTP
• RFC 9204: QPACK
• RFC 9000: QUIC transport
• HTTP/3 stream rules (RFC 9114 §6.1), diskutiert im IETF HTTP WG
• draft-ietf-webtrans-http3-16: WebTransport über HTTP/3
• Forward und Reverse HTTP/3 über WebTransport (Entwurf)
• Cloudflare Tunnel-Konfiguration
• Cloudflare Tunnel Laufparameter
• cloudflared Changelog (h2mux-Entfernung)
• OPNsense: cloudflared und QUIC UDP-Puffer
• muxado (das Multiplexing-Protokoll hinter ngrok)
• quic-go: UDP-Puffergrößen
• quic-go: BBR-Diskussion
• quic-go: http3-Paketdokumentation
• IETF: Anwendbarkeit des QUIC-Transportprotokolls (UDP-Blockade und Fallback)
• W3Techs: HTTP/3 Nutzung
• HTTP-Protokoll-Adoption, Q1 2026