UDP und QUIC über Proxies

Ein Proxy kann einen Webtest bestehen und trotzdem den benötigten Anwendungsverkehr nicht transportieren. Ein Spiel kann sich beispielsweise über den Proxy anmelden, aber keine Spielaktualisierungen austauschen. Eine Website kann normal öffnen, während der Browser HTTP/2 statt HTTP/3 verwendet. Diese Vorgänge benötigen unterschiedliche Netzwerkfähigkeiten.

Den grundsätzlichen Protokollvergleich behandelt SOCKS- und HTTP-Proxies. Dieser Artikel erklärt den UDP-Weg durch einen Proxy, die QUIC-Anforderungen und die Prüfung von gewünschtem Transport und Ausgangs-IP-Adresse in Ihrer Anwendung.

Was UDP, QUIC und HTTP/3 leisten

TCP liefert einen geordneten Bytestrom. Gehen Daten verloren, organisiert es eine erneute Übertragung und hält spätere Bytes vor der Anwendung zurück, bis die Lücke gefüllt ist. UDP sendet einzelne Nachrichten, sogenannte Datagramme. UDP selbst garantiert weder Zustellung noch Reihenfolge oder Schutz vor Duplikaten. Die verwendende Software entscheidet über den Umgang damit.

So können Anwendungen unterschiedliches Verhalten wählen. Eine Sprachanwendung kann ein für die Wiedergabe zu spät eingetroffenes Audiopaket verwerfen. Ein Spiel kann eine aktuelle Positionsmeldung einer alten vorziehen. Ein DNS-Austausch kann aus kurzer Frage und Antwort bestehen. Der tatsächliche Transport hängt vom Programm ab. Diese Beispiele bedeuten nicht, dass jeder Anruf, jedes Spiel oder jede DNS-Anfrage UDP verwendet.

QUIC ist ein auf UDP aufgebautes Transportprotokoll. Es ergänzt Verbindungsaufbau, Wiederherstellung verlorener Daten, Überlastungssteuerung und zuverlässige Streams. Eine über einen zuverlässigen QUIC-Stream übertragene Datei kann vollständig und geordnet ankommen. Der Transport ihrer Pakete in UDP-Datagrammen entfernt die Zuverlässigkeit von QUIC nicht.

QUIC lässt außerdem mehrere Streams eine Verbindung teilen. Gehen Daten eines Streams verloren, können andere mit bereits eingetroffenen Daten fortfahren. Das kann Wartezeiten gegenüber einer einzigen geordneten TCP-Verbindung für alle Streams verringern. Das Ergebnis hängt weiterhin von Weg, Paketverlust, Server und Client ab. QUIC allein garantiert keine schnellere Anwendung.

HTTP/3 transportiert HTTP über QUIC. HTTP/1.1 und HTTP/2 verwenden gewöhnlich TCP. Alle drei können eine HTTPS-Website bedienen. https:// in der Adresse identifiziert deshalb weder die HTTP-Version noch bestätigt es UDP-Nutzung.

Verschlüsselung ist eine getrennte Eigenschaft. UDP verschlüsselt keine Daten. QUIC verwendet TLS 1.3 zum Schutz des Anwendungsverkehrs. Eine gewöhnliche UDP-Anwendung kann andere Sicherheitsverfahren oder unverschlüsselte Nutzdaten verwenden. Proxyweiterleitung ergänzt diesen Schutz nicht automatisch.

Wie SOCKS5 UDP transportiert

SOCKS5 definiert ein UDP-Relay: einen Dienst, der Datagramme des Clients annimmt, ihre Nutzdaten an das Ziel sendet und Antworten zurückgibt. Der Client vereinbart die Weiterleitung zunächst über TCP. Steuerverbindung und Datagrammweg bestehen anschließend nebeneinander.

1. Der Client verbindet sich per TCP mit dem SOCKS5-Server und führt das vereinbarte Authentifizierungsverfahren aus.
2. Er fordert UDP ASSOCIATE an. Akzeptiert der Proxy dies, liefert die Antwort Adresse und UDP-Port des Relays.
3. Der Client sendet Datagramme mit einem SOCKS-Header zur Zielangabe an das Relay. Dieses entfernt den Header vor der Weiterleitung der Nutzdaten. Bei Antworten ergänzt es einen SOCKS-Header, bevor es das Datagramm an den Client zurücksendet.
4. Während der Relay-Nutzung hält der Client die TCP-Steuerverbindung offen. Ihr Schließen beendet die darüber vereinbarte UDP-Weiterleitung. Die Verknüpfung von Steuerverbindung und UDP-Weiterleitung heißt UDP-Zuordnung beziehungsweise UDP Association.

Das Relay kann eine andere Adresse oder einen anderen Port als der TCP-Endpunkt der Proxyeinstellungen verwenden. Einfaches UDP an diesen bekannten Endpunkt führt den SOCKS5-Dialog nicht aus. Ein Client mit ausschließlich CONNECT kann SOCKS5 für TCP verwenden, hat aber nicht das hier nötige Verfahren. SOCKS4 definiert kein solches UDP-Relay.

Das erklärt einen häufigen Teilerfolg: Eine Firewall erlaubt TCP-Verbindung und Authentifizierung, blockiert aber Datagramme zum ausgehandelten Relay. Das Passwort funktioniert; die Anwendung erhält trotzdem keine UDP-Antworten. Beide Wegteile müssen verfügbar sein.

Kann ein HTTP-Proxy UDP weiterleiten?

Eine gewöhnliche HTTP-CONNECT-Anfrage fordert eine TCP-Verbindung zum Ziel und den Transport eines Bytestroms an. Sie richtet keine UDP-Weiterleitung ein. TLS zu einem HTTPS-Proxy schützt diese Verbindung, ohne die angeforderte Tunnelart zu verändern.

HTTP besitzt einen zusätzlichen UDP-Tunnelmechanismus namens CONNECT-UDP, der im Rahmen von MASQUE entwickelt wurde. Mit kompatiblem Client und Server fordert der Client einen Tunnel zu einem UDP-Ziel an. Der Proxy leitet Datagramme dorthin und Antworten zurück. Beide Seiten müssen dies ausdrücklich unterstützen.

Zwischen Client und Proxy können HTTP-Datagramme in QUIC-DATAGRAM-Frames laufen, wenn HTTP/3 und die erforderlichen Erweiterungen unterstützt werden. Möglich sind außerdem Kapseln: eingerahmte Nachrichten innerhalb eines zuverlässigen HTTP-Streams, auch bei HTTP/2 über TCP. Dann sendet der Proxy weiterhin UDP zum Ziel, obwohl der erste Wegabschnitt TCP verwendet.

Diese Wahl beeinflusst das Zeitverhalten. Verliert die TCP-Verbindung Daten, können spätere Bytes auf deren Wiederherstellung warten und damit die darin transportierten Datagramme verzögern. Ein Tunnel kann funktionieren, aber für eine bestimmte Echtzeitlast ungeeignet sein. Die bloße Eingabe einer http://-Proxyadresse aktiviert keinen dieser zusätzlichen UDP-Mechanismen.

Welche Verbindung verwendet QUIC?

Die Bezeichnung „QUIC-Proxy“ benötigt Kontext. Sie kann den Transport zum Proxy oder die Anwendungsverbindung zum Ziel meinen. Das sind getrennte Teile des Austauschs.

Bei gewöhnlicher UDP-Weiterleitung muss der Proxy die QUIC-Verbindung der Anwendung nicht beenden. Er leitet Pakete weiter, während Anwendung und Ziel Endpunkte des verschlüsselten Austauschs bleiben. Er kennt weiterhin das Weiterleitungsziel und kann Datenvolumen und Zeitpunkte beobachten.

Warum Unterstützung in der Anwendung wichtig ist

Ein Programm muss das Weiterleitungsverfahren des Dienstes implementieren. Ein SOCKS5-Kontrollkästchen belegt keine Unterstützung von UDP ASSOCIATE. Ebenso kann ein Programm HTTP/3 direkt unterstützen, aber für Proxyverbindungen ausschließlich TCP anbieten.

Ein konkretes Beispiel ist Chrome: Seine eingebaute SOCKS5-Unterstützung leitet TCP-basierte URL-Anfragen weiter, aber kein UDP über SOCKS5. Ein Seitenaufruf mit dieser Einstellung testet das UDP-Relay nicht. Diese Grenze betrifft diesen speziellen Clientmodus. Andere Clients oder externe Routing-Software können andere Fähigkeiten haben.

Prüfen Sie auch den Geltungsbereich der Einstellung. Anmeldung, Downloads, Sprache und Spielbetrieb können verschiedene Netzwerkkomponenten derselben Anwendung nutzen. Ein Webproxy erfasst möglicherweise nur einen Teil. Auch System-Proxyeinstellungen wirken nur, wenn das jeweilige Programm sie beachtet.

Ein Programm zur Umleitung fremden Anwendungsverkehrs kann UDP über einen Proxy senden, wenn es UDP und dessen Weiterleitungsverfahren unterstützt. Reine TCP-Umleitung reicht nicht. Verwendet es eine virtuelle Netzwerkschnittstelle, entscheiden die Routing-Regeln über den erfassten Verkehr. Testen Sie die gesamte Kombination aus Anwendung, Routing-Programm und Proxyendpunkt.

Ausweichtransport, Fehler und direkte Verbindung

Ist der benötigte Weg nicht verfügbar, hängt das Ergebnis von Fähigkeiten und Regeln der Anwendung ab. Drei Ergebnisse können ähnlich wirken, wenn nur gefragt wird, ob etwas geöffnet wurde:

Das Ausweichen auf eine TCP-basierte HTTP-Version heißt Fallback. Es kann gewöhnliches Browsen bei fehlendem QUIC erhalten. Der Client öffnet eine andere Verbindung; QUIC selbst wird nicht zu TCP. QUIC abzuschalten kann deshalb einer Webanwendung einen verfügbaren TCP-Weg ermöglichen, liefert aber kein UDP für eine Funktion, die es benötigt.

Direkter Zielzugang ist eine Routing-Entscheidung. Nicht unterstütztes UDP wird nicht generell direkt gesendet: Software kann abbrechen, einen anderen Transport versuchen oder einer Ausnahmeregel folgen. Muss sämtlicher Aufgabenverkehr durch den Proxy laufen, verwenden Sie einen bei Proxyweg-Ausfall stoppenden Modus und prüfen Sie ihn mit unerreichbarem Proxy.

Warum UDP nach dem Aufbau ausfallen kann

Portregeln und Rückweg

TCP-Port 443 und UDP-Port 443 gehören zu unterschiedlichen Transporten. Die Freigabe des einen öffnet den anderen nicht. Bei SOCKS5 muss der Client den zurückgegebenen UDP-Relay-Endpunkt erreichen. Das Relay muss außerdem zum UDP-Zielport senden dürfen. HTTP/3 kann andere Ports als 443 nutzen. Prüfen Sie deshalb den tatsächlichen Anwendungsendpunkt.

Antworten müssen durch Relay, Firewall und gegebenenfalls NAT zurückkommen. NAT übersetzt zwischen Netzwerken Adressen und häufig Ports. Ein gesendetes Datagramm allein belegt keinen funktionierenden Rückweg. Ein Netzwerkwechsel kann die öffentliche Client-IP-Adresse oder Portzuordnung ändern. SOCKS5-Relays müssen Datagramme von anderen als der für die UDP-Zuordnung erfassten Quell-IP-Adresse ablehnen. Eine Adressänderung kann daher eine neue Zuordnung verlangen.

Pausen und abgelaufener Zustand

Relays und NAT-Geräte speichern vorübergehende Zustände für UDP-Austausch. Diese können während einer Pause ablaufen. Ein Anruf oder eine Sitzung kann zunächst funktionieren und später den UDP-Weg verlieren, bis der Client ihn neu einrichtet. Dieselbe Ausgangs-IP-Adresse verhindert das nicht: UDP-Weiterleitungszustand und IP-Zuweisung des Dienstes sind getrennte Dinge.

Datagrammgröße und MTU

MTU ist die größte IP-Paketgröße, die eine Netzverbindung ohne Fragmentierung transportiert. Die nutzbare Größe eines Wegs wird durch dessen kleinste Grenze bestimmt, die Pfad-MTU. IP-, UDP- und zusätzliche Tunnelheader beanspruchen Platz. Kleine Testnachrichten können passieren, während größere Datagramme verworfen werden. Die Anwendung muss daher den gesamten Weg samt Zusatzheadern berücksichtigen.

Ein QUIC-Weg muss mindestens 1.200 Bytes UDP-Nutzdaten tragen, ohne IP- und UDP-Header. Der Client füllt Datagramme mit QUIC-Initial-Paketen auf mindestens diese Nutzdatengröße auf. Proxyheader im Client-Proxy-Abschnitt benötigen zusätzlichen Platz. Dies empfiehlt keine Schnittstellen-MTU von 1.200. Es erklärt, warum kleine DNS-Fragen und Antworten funktionieren können, während der größere QUIC-Handshake nicht durchkommt.

Verzögerung, Verlust und Last

Bei einem Anruf oder Spiel kann rechtzeitige Zustellung ebenso wichtig sein wie die Zustellung selbst. Schwankende Verzögerung, Paketverlust und Paketratenlimits können ein ansonsten funktionierendes UDP-Relay beeinträchtigen. Bandbreite allein beschreibt diese Bedingungen nicht. Ein Proxy ergänzt einen Wegabschnitt und kann die Leistung je nach Netzwerken und Last verbessern oder verschlechtern.

UDP und HTTP/3 über einen Proxy prüfen

Testen Sie die vorgesehene Anwendung oder einen Client mit demselben Weiterleitungsverfahren. Ein aussagekräftiger Test prüft Antwort, Transport und Ausgangsadresse desselben Austauschs.

1. Wählen Sie ein Ziel, das auf den benötigten Verkehr antwortet: den tatsächlichen Anwendungsserver oder einen kontrollierten UDP-Antwortdienst. Wählen Sie für HTTP/3 ein bekanntermaßen geeignetes Ziel. Schweigen eines beliebigen UDP-Ports zeigt nicht die Fehlerstelle.
2. Bestätigen Sie die Annahme von Relay oder Tunnel. Prüfen Sie bei SOCKS5 das Ergebnis von UDP ASSOCIATE und zurückgegebene Relay-Adresse und Port. Bei einem HTTP-UDP-Tunnel bestätigen Sie dessen Annahme. Authentifizierung allein deckt diesen Schritt nicht ab.
3. Führen Sie eine Anfrage mit Antwort aus. Ein kontrollierter Antwortdienst kann eine Anfragekennung zurückliefern und die beobachtete Quell-IP-Adresse protokollieren. Das prüft den Ausgang dieses UDP-Austauschs. Ein separater Web-IP-Test prüft nur seine eigene Anfrage.
4. Bestätigen Sie bei HTTP/3 das Protokoll des Zielaustauschs. Suchen Sie im Verbindungsprotokoll von Client oder Server nach HTTP/3 oder h3 zusammen mit einem Nachweis des Proxywegs. Ein reiner HTTP/3-Testmodus kann einen Fehler aufdecken, den automatischer Fallback verbergen würde.
5. Wiederholen Sie unter relevanten Bedingungen: realistischen Datagrammgrößen, anhaltendem Verkehr und einer Pause mit anschließender Aktivität. Ist direkter Verkehr untersagt, testen Sie auch den Proxyausfall. Speichern Sie Clientversion und Verbindungseinstellungen mit dem Ergebnis.

Eine Paketaufzeichnung kann den Weg verdeutlichen. Gewöhnliche SOCKS5-UDP-Weiterleitung sendet Datagramme zum ausgehandelten Relay. Ein HTTP-UDP-Tunnel kann stattdessen eine äußere TCP-Verbindung verwenden. Fehlendes UDP auf dem ersten Wegabschnitt beweist deshalb keinen Fehler.

Entferntes DNS und ping prüfen andere Dinge. Ein Proxy kann einen Hostnamen für eine TCP-Verbindung auflösen, ohne den UDP-Verkehr der Anwendung weiterzuleiten. Gewöhnliches ping verwendet ICMP. Keiner der Tests ersetzt eine beobachtete UDP-Anfrage mit Antwort auf dem vorgesehenen Proxyweg.

Wann sich UDP-Unterstützung lohnt

Beginnen Sie mit dem tatsächlichen Verkehrsbedarf. Website- und API-Aufgaben über HTTP/1.1 oder HTTP/2 können mit einem reinen TCP-Proxy vollständig abgedeckt sein. HTTP/3-Tests, UDP-Medien und andere UDP-Funktionen benötigen ein geeignetes Relay oder einen Tunnel sowie einen passenden Client.

Fragen Sie nach unterstütztem UDP-Weiterleitungsverfahren und Clientkonfiguration. Prüfen Sie anschließend erlaubte Ziele und Ports, Datagrammgrenzen, Inaktivitätsverhalten sowie relevante Daten- oder Paketratenlimits. Müssen TCP und UDP dieselbe Ausgangs-IP-Adresse oder denselben Standort verwenden, prüfen Sie dies in der tatsächlichen Anwendung. Ein gemeinsames Konto oder erfolgreicher Webtest belegt kein identisches Ausgangsverhalten.