Helldivers 2 Proxy: Entscheiden Sie nicht ohne Messung

Die Netzwerkseite von Helldivers 2 teilt sich in zwei Bereiche. Auf der einen Seite stehen die persistenten Komponenten: Login, Fortschrittsspeicherung, Matchmaking und Kampagnenstatus. Diese werden in zentralen Diensten gehalten und laufen ueber TCP. Auf der anderen Seite steht der Stream waehrend der Mission; er ist echtzeitfaehig, latenzempfindlich und laeuft ueberwiegend ueber UDP.

Die gesamte Proxy-Entscheidung ruht auf dieser Unterscheidung. Ein Vermittler kann die erste Gruppe erreichen, die zweite in den meisten Setups nicht. Das von Anfang an zu wissen, erspart die Stunden, die in den Satz "Ich habe eine Regel geschrieben, aber nichts hat sich geaendert" fliessen.

Nachfolgend finden Sie zuerst die Verteilung des Traffics, dann die Grenze des UDP-Wegs von SOCKS5, anschliessend, wie eine Messung von Paketverlust und Latenz aufgesetzt wird, und zuletzt den tatsaechlichen Einsatzbereich eines Proxys in diesem Spiel.

Auf welche Endpoints verteilt sich der Client?

Waehrend einer Sitzung spricht der Client mit sechs voneinander unabhaengigen Zielen: der Login- und Warteschlangenebene, dem Dienst, in dem der Fortschritt gespeichert wird, dem Matchmaking, dem Echtzeit-Stream waehrend der Mission, dem Shop-Client und der Patch-Verteilung. Da alle hinter demselben Bildschirm liegen, wirken sie wie eine einzige Verbindung.

Das Protokoll dieser Ziele ist nicht dasselbe. Die ersten drei und die letzten beiden laufen ueber TCP; der Missions-Stream ist dagegen echtzeitfaehig. Dieser Unterschied ist die einzige Variable, die die Wirkung einer Proxy-Regel bestimmt.

In Stosszeiten wird die Login- und Warteschlangenebene zu einem eigenen Thema. Das Warten in der Schlange haengt von der Kapazitaet ab und hat nichts mit Ihrem Netzwerkweg zu tun; aus einem anderen Land herauszugehen, verkuerzt die Warteschlange nicht. Diese Unterscheidung zu treffen, bewahrt Sie davor, ein unloesbares Problem mit einem Proxy loesen zu wollen.

Die Unabhaengigkeit der Ziele hat noch eine Folge: Eines kann nicht erreichbar sein, waehrend die anderen einwandfrei funktionieren. Wenn der Shop-Client sich oeffnet, der Spiel-Login aber nicht durchlaeuft, liegt das Problem nicht in Ihrem Netz, sondern auf dieser Ebene. Ebenso zeigt ein haengendes Matchmaking bei laufendem Download nicht den Zustand Ihrer Regel, sondern den des Dienstes. Ein Symptom zu lesen, ohne zu trennen, zu welchem Ziel es gehoert, ist der schnellste Weg, Stunden an der falschen Stelle zu verbringen.

Fuehren Sie vor Beginn der Diagnose eine einfache Liste: welcher Bildschirm sich oeffnet, welcher haengt, ob der Fehler zur selben Zeit auch bei anderen auftritt. Diese drei Antworten bestimmen in den meisten Faellen allein, ob das Problem auf der Netzwerk- oder auf der Dienstseite liegt.

Wo stockt der UDP-Weg von SOCKS5?

Ein HTTP-Proxy oeffnet fuer HTTPS-Ziele einen Tunnel, und dieser Tunnel transportiert TCP. Die Details der Methode werden in CONNECT-Methode dem Beitrag erklaert. Da der Stream waehrend der Mission UDP nutzt, gelangt er gar nicht erst in diesen Tunnel; wie breit Sie die Regel auch formulieren, das Ergebnis aendert sich nicht.

Auf SOCKS5-Seite gibt es UDP ASSOCIATE einen Weg namens. Sein Ablauf ist in SOCKS5-UDP-Unterstuetzung dem Beitrag Schritt fuer Schritt beschrieben. In der Praxis sind drei Bedingungen zugleich noetig: Der Server muss diesen Befehl unterstuetzen, das dazwischenliegende Netz muss den assoziierten Fluss zulassen und der Client muss so geschrieben sein, dass er diesen Weg nutzt. Die dritte Bedingung ist bei Spiel-Clients praktisch nie erfuellt.

Die realistische Erwartung lautet deshalb: Der Proxy deckt in diesem Spiel den Login-, Shop-, Patch- und Matchmaking-Traffic ab. Den Missions-Stream ueber einen Exit zu leiten, ist ohne Client-Unterstuetzung nicht moeglich, und erzwungene Versuche enden meist damit, dass sich das Spiel gar nicht mehr verbindet. Fuer einen Protokollvergleich SOCKS5 Proxy Seite ansehen.

Ein Missverstaendnis sollte hier ebenfalls ausgeraeumt werden: Ein Tunnel, der das gesamte Geraet umschliesst, ist nicht dasselbe wie ein auf Anwendungsebene definierter Proxy. Ersterer baut eine eigene Transportschicht auf und kann alles einschliesslich UDP transportieren; Letzterer nimmt nur die Verbindungen an, die an ihn geleitet werden. Das auf dieser Seite beschriebene Werkzeug ist das zweite, und daher ruehren auch seine Grenzen.

Wenn im Client kein SOCKS5-Feld vorhanden ist, greifen manche Nutzer zu Hilfsprogrammen, die den Traffic erzwungen umleiten. Leitet eine solche Schicht den Traffic an einen Exit, der den UDP-Stream nicht transportieren kann, ist das Ergebnis kein Geschwindigkeitsverlust, sondern eine Verbindung, die gar nicht erst zustande kommt. Da das Symptom als "das Spiel kann sich nicht mit dem Server verbinden" erscheint, wird die Ursache meist spaet erkannt.

Wo genau wirkt der Proxy tatsaechlich?

Die Reichweite ist eng, aber nuetzlich. Wenn in Unternehmens- oder Campusnetzen der Shop-Client nicht nach aussen kommt, kann ein Exit die Installations- und Update-Seite wieder funktionsfaehig machen. Eine Regel zu schreiben, ohne zu verstehen, auf welcher Ebene die Einschraenkung liegt, ist Zeitverschwendung; die Diagnosereihenfolge ist in Zugangssperren in Unternehmensnetzen dem Beitrag aufgelistet.

Der zweite legitime Anwendungsfall sind Netzwerkrichtlinien, die eine feste Exit-Adresse verlangen. Wenn in einem Unternehmen der gesamte ausgehende Traffic ueber eine bekannte Adresse laufen soll, kann der Download- und Shop-Traffic an diese Adresse gebunden werden. Das ist keine Performance-, sondern eine Verwaltungsentscheidung.

Der dritte sind Verifizierungsaufgaben: sehen, wie die Shop-Seite, Kampagnenankuendigungen oder Support-Inhalte von einem anderen Standort aus aussehen. Keine dieser Aufgaben betrifft die Spielsitzung und alle laufen ueber den Browser.

Diesen drei Szenarien ist gemeinsam, dass der Proxy nicht als Performance-, sondern als Zugriffs- und Sichtbarkeitswerkzeug eingesetzt wird. In keinem geht es darum, das Spiel zu beschleunigen; es geht darum, entweder einen geschlossenen Weg zu oeffnen oder zu bestimmen, woher die Gegenseite Ihre Verbindung kommen sieht. Setups, die die Erwartung in diesem Rahmen halten, arbeiten vorhersehbar.

• Ermitteln Sie in einem eingeschraenkten Netz zuerst, welche Ebene blockiert wird.
• Wenn die Unternehmensrichtlinie eine feste Adresse verlangt, verengen Sie die Reichweite auf die wirklich noetigen Prozesse.
• Fuehren Sie Verifizierungsaufgaben nicht im Spiel-Client, sondern im Browser durch.

Wo sollte man Paketverlust messen und wie liest man ihn?

Der haeufigste Fehler bei der Diagnose von Verbindungsproblemen besteht darin, verschiedene Groessen auf eine einzige Zahl zu reduzieren. Latenz beschreibt die Laenge des Wegs, Jitter, wie stark diese Laenge schwankt, und Paketverlust den Anteil der Pakete, die nie ankommen. Alle drei haben unterschiedliche Ursachen und erfordern unterschiedliche Loesungen.

Beginnen Sie die Messung bei Ihrer eigenen Leitung. Zeigt ein Test zum Router Verlust, liegt das Problem im Haus und kein Exit repariert das. Fuer eine Messung zu einem Ziel ausserhalb liefert Ping-Test-Werkzeug einen Ausgangspunkt; um die Methode in eine Reihenfolge zu bringen, koennen die Schritte in So testen Sie die Proxy-Geschwindigkeit dem Beitrag befolgt werden.

Bei Messungen entlang des Wegs ist ein Hinweis noetig: Da Zwischenstationen mit niedriger Prioritaet antworten koennen, ist ein an mittleren Punkten sichtbarer Verlust nicht immer ein realer Verlust. Aussagekraeftig ist der Anteil der Pakete, die das Endziel erreichen. Ziehen Sie keine Schluesse, ohne die Messung mehrfach und zu verschiedenen Zeiten zu wiederholen.

Die WLAN-Verbindung ist ein Thema fuer sich. Nachbarnetze auf derselben Frequenz, Entfernung und Waende zeigen sich in der Messung als Verlust und Schwankung; das ist nicht das Problem Ihrer Leitung, sondern Ihres Raums. Bei Verdacht auf Verlust fuehren Sie den ersten Versuch mit Kabel durch. Verschwindet der Verlust mit Kabel, bringt es nichts, sich mit der Exit-Wahl zu beschaeftigen.

Benennen Sie schliesslich das Symptom richtig. Ploetzliche, kurze Einfrierer kommen meist von Schwankung, dauerhaft verzoegerte Reaktionen von der Distanz und zeitweise abreissende Bewegungen von Verlust. Dieselbe Beschwerde auf das eine Wort "laggt" zu reduzieren, macht unklar, welche Messung Sie vornehmen sollen, und erschwert die Diagnose von vornherein.

Der Anteil der zusaetzlichen Station am Latenzbudget

Die Gesamtlatenz setzt sich aus mehreren Teilen zusammen: der Distanz von Ihnen zum Exit-Knoten, der Distanz vom Exit zum Ziel, der aktuellen Last des Exit-Knotens, den Kosten von Verschluesselung und Handshake sowie den Zwischenstationen auf dem Weg. Kommt ein Proxy hinzu, steigt die Zahl dieser Posten, sie sinkt nicht.

Der von Nutzern am haeufigsten unterschaetzte Posten ist die Warteschlange am Exit-Knoten. Je mehr Nutzer sich denselben Exit teilen, desto laenger die Antwortzeit, und dieser Effekt schwankt im Tagesverlauf. Anhand eines morgens gemessenen Werts eine Entscheidung fuer den Abend zu treffen, ist der haeufigste Messfehler. Die Aufschluesselung der Latenz in ihre Bestandteile was ist Proxy-Latenz behandelt der Beitrag ausführlich.

Verschluesselungs- und Handshake-Kosten sind ein kleiner, aber nicht zu ignorierender Posten. Eine fuer jede neue Verbindung erneut aufgebaute Session vergroessert die Summe bei kurzlebigen Anfragen deutlich. Bei Clients, die eine offene Verbindung halten, sinkt dieser Posten; bei Werkzeugen, die viele kleine Anfragen erzeugen, wird der Unterschied dagegen messbar.

Das praktische Fazit ist eindeutig: In diesem Spiel wird ein Proxy nicht eingesetzt, um die spielinterne Reaktionszeit zu verbessern. Da der Missions-Stream ohnehin nicht in den Tunnel gelangt, ist die Wirkung indirekt; beim Traffic, der hineingelangt, steigt die Zeit, weil der Weg laenger wird.