Manche Netze sperren bestimmte UDP-Adressen oder -Ports oder drosseln UDP, und Geräte zur Paketinspektion filtern Protokolle heraus, die sie nicht erkennen. Spiele, die über UDP kommunizieren, kommen in solchen Netzen nicht durch oder verlieren oft die Verbindung.
Warum Verbindung aus einem Providernetz, das UDP drosselt, oder aus einem Netz mit Geräten zur Paketinspektion (Zensur) auf Landes- oder Providerebene → Folge Bestimmte UDP-Adressen oder -Ports gesperrt, UDP zur Stoßzeit gedrosselt, Ports oder Protokolle außerhalb einer Allowlist ausgefiltert oder nur die ersten Pakete durchgelassen und dann gesperrt → Auf dem Bildschirm Nur Spieler aus bestimmten Ländern oder bei bestimmten Providern: Kein Login / Endlos-Laden, Verbindungsabbruch kurz nach dem Verbinden, zur Stoßzeit Teleportieren durch Paketverlust
Client: steht die UDP-Verbindung nicht innerhalb weniger Sekunden, automatisch auf einen Fallback über TCP/TLS 443 umschalten, auch Fälle erkennen, in denen die Verbindung erst steht und kurz darauf abbricht, und dann über den Fallback neu versuchen, protokollieren, über welchen Weg die Verbindung zustande kam. Server: dasselbe Spielprotokoll auch über TCP 443 (TLS) annehmen, Timeouts anpassen, da der Fallback mehr Latenz haben kann.
Aufgaben Infrastrukturteam
Vor dem Start in einem neuen Land in den dortigen Providernetzen messen, ob UDP durchkommt und wie hoch der Verlust zur Stoßzeit ist, Relays oder Gateways für den Fallback über TCP 443 nahe vor Ort betreiben, Verbindungserfolgsrate für UDP und TCP pro Land und ASN überwachen, bei Providern mit nachgewiesener UDP-Drosselung Belege sammeln und eskalieren.
Aufgaben Extern
Beim betroffenen Provider oder der zuständigen Behörde nach den Kriterien der UDP-Beschränkung und nach Lockerungen fragen, Spieler bitten, zum Vergleich aus einem anderen Netz zu spielen.
Größenordnungen
Laut einer in einem IETF-Dokument zitierten Messung sperren 3–5 % der Netze UDP vollständig. Google stellte 2016 bei der Auswertung von QUIC (UDP-basiert) fest, dass 4,4 % der Clients QUIC nicht nutzen konnten, weil UDP oder QUIC gesperrt oder die Path-MTU zu klein war. Die meisten saßen hinter Firmen-Firewalls, eine providerweite Sperre wurde nicht beobachtet. 0,3 % befanden sich in Netzen, in denen der Verlust zur Stoßzeit stark stieg und UDP offenbar gedrosselt wurde. Durch Anfragen bei den Providern sank dieser Anteil von 1 % im Jahr 2015.
Im Graphen
Nur einzelne Ausreißer · UDP-Verbindungserfolgsrate (nach Land und ASN)
Wo nachsehen
Erfolgsrate von UDP-Verbindungen und vom Fallback über TCP 443 getrennt nach Land und ASN auswerten. Von einer Cloud-VM im betroffenen Providernetz oder vom PC des Spielers Verbindungstests auf den UDP-Spielport und auf TCP 443 durchführen und mit mtr -u -P (Spielport) und mtr -T -P 443 vergleichen, ab welchem Abschnitt keine Antworten mehr kommen
Spricht dafür
Nur in bestimmten Ländern oder ASNs bleibt die erste UDP-Antwort aus oder die Verbindung bricht nach einigen Sekunden ab, während TCP 443 vom selben Ort normal funktioniert. Bei Drosselung steigt der UDP-Verlust nur zur Stoßzeit deutlich, TCP ist weniger betroffen
Spricht dagegen
TCP scheitert ebenfalls: eher Routenstörung, IP-Sperre oder „DNS-Störung oder -Verzögerung“. In allen Ländern gleich: Konfiguration der eigenen Server oder Firewall. Verlust nur bei kurzzeitig hohem Sendevolumen, egal ob UDP oder TCP: „Policer verwirft Überschuss“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Laut einem Übersichtsdokument der IRTF sperren Geräte zur Paketinspektion UDP-Flows gezielt nach Adresse, Port und Protokoll, oder sie sperren alles außer ausdrücklich erlaubten Protokollen (Allowlist). Entscheidet ein Gerät nur anhand einzelner Felder im Paket, kann schon eine kleine Protokolländerung zur Sperre führen. In der Anfangszeit von QUIC ließ eine Firewall nach der Änderung von 1 Bit im Header die ersten Pakete durch und sperrte die folgenden. Dadurch griff die Logik nicht, mit der der Client auf TCP umschalten sollte. Beim Start in einem neuen Land kann sich das Problem durch Meldungen wie „Im Inland läuft alles, aber bei einigen Providern dort kommt keine Verbindung zustande“ zeigen. Ist nur das Netz eines bestimmten Ortes wie eines Cafés oder einer Firma betroffen, lesen Sie den Eintrag „Einschränkungen in öffentlichen WLANs und Firmennetzen“.
Quellen
RFC 9308: Applicability of the QUIC Transport ProtocolIETF Laut Messstudien sperren 3–5 % der Netze UDP vollständig, UDP-basierte Apps müssen daher Verbindungsfehler hinnehmen oder einen Fallback über TCP (TLS) vorsehen, Ports ohne Zuordnung zu einem registrierten Dienst können von Firewalls gesperrt werden
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)ACM 2016: 4,4 % der Clients konnten QUIC (UDP) nicht nutzen (UDP oder QUIC gesperrt oder Path-MTU zu klein, meist hinter Firmen-Firewalls, keine providerweite Sperre beobachtet), 0,3 % in Netzen mit vermutlicher UDP-Drosselung (mehr Verlust zur Stoßzeit, nach Anfragen bei Providern gesunken von 1 % im Jahr 2015), Fall einer Firewall, die nach Änderung von 1 Bit im Header nur die ersten Pakete durchließ, danach sperrte und so die TCP-Fallback-Logik aushebelte
RFC 9505: A Survey of Worldwide Censorship TechniquesIRTF Inspektionsgeräte im Netz können TCP- und UDP-Flows gezielt nach Adresse, Port und Protokoll sperren (bei QUIC wurde das Sperren von UDP-Endpunkten beobachtet), Allowlists, die alle nicht erlaubten Protokolle sperren, führen zu Overblocking, auch die Drosselung bestimmten Datenverkehrs kommt vor
mtr(8) manual page sourcemtr Mit -u werden UDP-Pakete, mit -T TCP-SYNs gesendet, -P legt den Zielport fest, so wird die Route mit demselben Protokoll und Port wie das Spiel gemessen