iRacing und Proxy: Messung, Verlustdiagnose und Transportgrenzen

iRacing ist ebenso sehr Dienst wie Spiel: Mitgliedschaft, Content-Bibliothek, geplante Sessions und Ergebnisprotokolle laufen unter einem Dach. Diese Struktur spiegelt sich auch netzseitig wider; die Aufgaben, die Sie über den Browser erledigen, und der Flow, den der Simulator während des Rennens erzeugt, haben völlig unterschiedliche Anforderungen.

Ein Proxy-Exit berührt nicht alle diese Schichten in gleicher Weise. Requests auf der Web-Seite gehen problemlos in den Tunnel; der Content-Download kann hineingehen, bleibt aber meist besser außen vor; der Session-Flow bleibt bei den meisten Setups ohnehin außerhalb des Tunnels. Die folgenden Abschnitte behandeln diese drei Verhaltensweisen getrennt und zeigen, was Sie bei jeder davon messen sollten.

Durch den gesamten Text zieht sich ein Prinzip: Worüber nicht gemessen wurde, wird nicht diskutiert. Der Satz „Die Verbindung fühlt sich schlecht an“ ist keine Diagnose; ohne festzuhalten, zu welchem Ziel, zu welcher Uhrzeit und über welchen Exit Sie gemessen haben, können Sie Vorher und Nachher nicht vergleichen.

In welche Schichten teilt sich der Service-Traffic auf?

Ganz oben stehen die Aufgaben, die Sie über den Browser erledigen: Mitgliedschaftsverwaltung, Content-Kauf, Session-Kalender und Ergebnisseiten. All das sind verschlüsselte HTTP-Flows, sie sind latenztolerant und lassen sich problemlos über einen Proxy transportieren. Der Gegenwert eines Proxys auf dieser Schicht ist nicht Geschwindigkeit, sondern die Frage, von wo aus Ihre Exit-Adresse erscheint.

Die zweite Schicht ist das Client-Update und der Content-Download. Neue Fahrzeug- und Streckendateien sowie Versionsupdates kommen von hier und machen den größten Teil der übertragenen Daten aus. Wenn Sie einen Exit mit Volumenkontingent nutzen, ist es fast immer besser, diese Schicht außerhalb des Tunnels zu lassen; sowohl im Hinblick auf das Budget als auch auf die Download-Zeit.

Die dritte Schicht ist Session-Matchmaking und -Beitritt: kurze Requests wie die Zuweisung eines Servers, die Aufnahme in die Session, Registrierung und Ergebnisbenachrichtigung. Die vierte Schicht ist der Statusflow während des Rennens; Fahrzeugposition und Eingabeinformationen werden in kontinuierlichen, kleinen und zeitkritischen Paketen übertragen. Die fünfte Schicht sind Sprachkommunikation und Nebenwerkzeuge – sie sind nicht Teil des Spiels, teilen sich aber dieselbe Leitung.

Diese Unterscheidung im Kopf zu behalten, verkürzt die Diagnosezeit. Bestimmen Sie bei einem Problem zuerst, auf welcher Schicht Sie sich befinden: Öffnet sich die Webseite nicht, hakt der Download, können Sie der Session nicht beitreten, oder brechen Sie innerhalb der Session ab? Diese vier verweisen auf vier verschiedene Ursachen.

Was macht die zusätzliche Zwischenstation mit der Latenz, und wo entsteht die Ausnahme?

Ein über einen Proxy gesendeter Request nimmt einen zweibeinigen Weg: die Distanz zwischen Ihnen und dem Proxy, anschließend die Distanz zwischen Proxy und Ziel. Die Gesamtzeit entspricht der Summe dieser beiden Abschnitte, zuzüglich der aktuellen Auslastung des Proxy-Servers. Da keine der drei Komponenten null ist, fällt das Ergebnis bei den meisten Setups höher aus als bei einer Direktverbindung. Das ist nicht als Mangel zu lesen, sondern als natürlicher Preis der gewählten Methode; woraus sich die Latenz zusammensetzt, proxy latency wird im Beitrag ausführlich dargestellt.

Die Ausnahme gibt es tatsächlich, sie ist aber an eine enge Bedingung geknüpft: Wenn Ihre Standardroute unnötig lang zum Ziel führt und das Backbone des Proxy-Anbieters einen direkteren Weg nutzt, kann der zweibeinige Weg kürzer sein als der einbeinige Umweg. Das ist keine Regel, lässt sich ohne Messung nicht annehmen und kann sich auf derselben Leitung im Lauf der Zeit ändern. Eine ausführliche Erörterung des Themas Proxy und Ping im Spiel .

Achten Sie beim Aufbau der Messung auf drei Dinge. Erstens: Führen Sie den Vergleich zum selben Ziel durch; eine Messung zu zwei verschiedenen Zielen sagt nichts aus. Zweitens: Erheben Sie die Serie nicht mit einem einzelnen Schuss, sondern über die Zeit verteilt; ein Einzelergebnis ist die Momentaufnahme dieser Sekunde. Drittens: Betrachten Sie neben dem Mittelwert auch die Verteilung: Das schlechteste Perzentil sagt mehr aus als der Mittelwert. Zur Methode So testen Sie die Proxy-Geschwindigkeit und Ping-Test kann das Tool gemeinsam eingesetzt werden.

Paketverlust richtig lesen: Welches Tool sagt was?

Paketverlust ist ein tückischeres Problem als Latenz, weil er in Durchschnittswerten nicht sichtbar wird. In einem Flow, der Dutzende kleiner Updates pro Sekunde überträgt, erzeugen schon wenige Promille Verlust sichtbare Sprünge, während dieselbe Leitung eine Webseite makellos öffnet. Deshalb hilft der Satz „Mein Internet ist gut, der Speedtest fällt hoch aus“ bei der Verlustdiagnose nicht weiter: Ein Speedtest misst Kapazität, nicht Kontinuität.

Verlust an Zwischenstationen wird besonders häufig missverstanden. Router auf der Route behandeln an sie selbst gerichtete Kontrollnachrichten mit niedriger Priorität und begrenzen sie bei Bedarf; deshalb kann die Ende-zu-Ende-Messung blitzsauber ausfallen, während an einer mittleren Station hoher Verlust erscheint. Schauen Sie bei der Bewertung nur auf das Ergebnis der letzten Station, also des eigentlichen Ziels. Die farbigen Zeilen dazwischen sind keine Diagnose, sondern Rauschen.

Erheben Sie zwei Serien mit und ohne Proxy nebeneinander und vergleichen Sie sie im selben Zeitfenster. Liegt der Unterschied nicht im Verlust selbst, sondern nur in der Latenz, ist Ihr Problem nicht der Transport, sondern die Distanz. Tritt der Verlust nur bei aktiviertem Tunnel auf, hinterfragen Sie die Kapazität oder die Obergrenze gleichzeitiger Verbindungen des Exits; wie sich diese Obergrenze verhält, Limit gleichzeitiger Verbindungen wird im Beitrag erklaert.

Wie weit trägt die UDP-Weiterleitung von SOCKS5?

SOCKS5 Das Protokoll ist ein Vermittler, der auf der Transportschicht steht und die Inhalte nicht interpretiert. Für die UDP-Seite gibt es eine definierte Methode: Der Client sendet über die Steuerverbindung eine Weiterleitungsanfrage, der Server gibt eine Weiterleitungsadresse zurück, auf der er auf seiner Seite lauscht, und der Client sendet UDP-Daten danach mit einem kleinen Header umhüllt an diese Adresse. Die Methode ist auf dem Papier sauber; die Details des Ablaufs SOCKS5-UDP-Unterstuetzung wird im Beitrag Schritt fuer Schritt erklaert.

Die praktische Grenze kommt aus drei Richtungen. Die erste ist der Anbieter: Viele Proxy-Dienste halten die UDP-Weiterleitung wegen Ressourcenverbrauch und Missbrauch deaktiviert und erlauben nur TCP-Verbindungen. Die zweite ist der Client: Dass eine Anwendung eine Adresse in das SOCKS5-Feld schreiben kann, bedeutet nicht, dass sie auch ihr UDP an den Vermittler übergibt; die meisten Clients öffnen ihren eigenen Socket direkt. Die dritte ist das Netzwerk: Firewalls dazwischen können das UDP zur Weiterleitungsadresse blockieren.

Ein Punkt sei ebenfalls vermerkt: Die Namensauflösung verändert dieses Bild. Ob die Adresse auf Ihrer Seite oder auf Seite des Vermittlers aufgelöst wird, kann beeinflussen, zu welchem Server Sie geleitet werden; der Unterschied zwischen beiden Verhaltensweisen Wo wird DNS bei SOCKS5 aufgeloest wird im Beitrag behandelt. Ein auf der falschen Seite aufgelöster Name führt zur unpassenden Kombination aus einem nah bei Ihnen gewählten Endpunkt und einem aus der Ferne austretenden Tunnel.

Im Ergebnis ist die UDP-Weiterleitung eine Möglichkeit, kein Standard. Prüfen Sie nicht durch Annahme, sondern durch Beobachtung, ob Ihr Setup sie tatsächlich nutzt: Ändert sich das Verhalten der Session bei aktiviertem Tunnel nicht, läuft dieser Flow höchstwahrscheinlich ohnehin außerhalb des Tunnels.