MARVEL SNAP Proxy: Welcher Traffic laeuft durch den Tunnel und welcher nicht?

Kartenspiele nehmen auf der Netzwerkseite eine eigene Stellung ein. Sie streamen keine fortlaufenden Positions- und Zieldaten an den Server; Sie treffen waehrend einer Runde Ihre Entscheidung, senden sie und warten auf das Ergebnis. Der Austausch ist kurz, selten und klein. Das bedeutet eine gegenueber einem Shooter latenztolerantere Struktur, doch tolerant heisst nicht unempfindlich.

Runden haben eine feste Dauer. Haengt die Verbindung fuer einen Moment, verlieren Sie nicht ein paar Frames, sondern moeglicherweise eine ganze Runde. Deshalb zaehlt in diesem Spiel nicht die durchschnittliche Geschwindigkeit, sondern eine unterbrechungsfreie und vorhersehbare Verbindung.

Die folgenden Abschnitte behandeln drei verschiedene Fragen: welchen Teil des Spiel-Traffics eine Proxy-Regel tatsaechlich transportieren kann, was der Unterschied zwischen dem Store-Client und der eigenen Verbindung des Spiels bedeutet und warum die verbreitete Erwartung an das Regionsverhalten unerfuellt bleibt.

Das Netzwerkprofil eines rundenbasierten Kartenspiels

Beim Start authentifiziert sich der Client, fordert Ihre Sammlung und Ihre Decks vom Server an und zeichnet die Oberflaeche. Der Traffic bis hierhin besteht aus gewoehnlichen HTTPS-Anfragen. Beginnt das Match, aendert sich der Rhythmus: In jeder Runde geht eine kleine Nachricht hinaus, der Server bestimmt das Ergebnis und antwortet. Das Volumen ist gering, die Frequenz mittel.

Entscheidend ist, wer das Ergebnis bestimmt. Der Client berechnet die Wirkung einer Karte nicht selbst und meldet sie dem Server; die Entscheidung liegt beim Server. Netzwerkseitig bedeutet das zweierlei. Erstens: Bricht die Verbindung ab, hat der Client kein Ergebnis zum Anzeigen und der Bildschirm wartet. Zweitens: Latenz aendert das Spielergebnis nicht direkt, sie verkuerzt lediglich die Zeit, die Ihnen fuer Ihre Entscheidung bleibt.

Deshalb ist die Rundendauer so wichtig. Ein Haenger, waehrend der Timer laeuft, kann teurer sein als ein Stolpern in einem Actionspiel: Wenn Sie zurueckkehren, ist die Runde moeglicherweise laengst vorbei. Genau das ist die Eigenschaft, auf die es bei der Proxy-Entscheidung ankommt - nicht ein hoher Bestwert, sondern ein schmaler Jitter-Bereich und eine Verbindung, die nicht abreisst.

Ein dritter Traffic-Posten ist die Oberflaeche selbst. Kartengrafiken, Varianten und Sammlungsansichten sind grafiklastig und werden beim ersten Aufruf heruntergeladen. Dieser Posten ist volumenmaessig deutlich groesser als der Match-Traffic und faellt bei einem volumenbegrenzten Ausgang auf.

Was der Tunnel transportiert: TCP, UDP und der tatsaechliche Geltungsbereich der Regel

Ein HTTP-Proxy oeffnet fuer HTTPS-Ziele mit dem Verfahren CONNECT einen Tunnel, und durch diesen Tunnel fliesst ausschliesslich TCP. Das liegt in der Natur des Protokolls und laesst sich durch keine Einstellung aendern. Wie das Verfahren funktioniert, wird im Beitrag HTTP-CONNECT-Methode ausfuehrlich erklaert. Kein Kanal, ueber den die Anwendung per UDP kommuniziert, gelangt in diesen Tunnel; das schliesst HTTP/3-Traffic ueber UDP 443 ein.

SOCKS5 Auf der Seite von ist die Lage flexibler, aber nicht automatisch. Das Verfahren UDP ASSOCIATE des Protokolls kann UDP transportieren; damit das funktioniert, muss jedoch der Proxy-Server das Verfahren anbieten und der Client dafuer geschrieben sein. Die meisten Spiel-Clients sprechen kein SOCKS5, und Proxy-Einstellungen auf Betriebssystemebene kapseln keine beliebigen UDP-Stroeme. Details SOCKS5-UDP-Unterstuetzung steht im Beitrag.

Die praktische Konsequenz sollte man ehrlich benennen: Eine Proxy-Regel umfasst in den meisten Spielen den Login-, Konto-, Store-, Oberflaechen- und Download-Traffic; ob der Match-Kanal erfasst wird, haengt von der Umsetzung des Clients ab. Von aussen laesst sich nicht sicher sagen, welches Spiel welchen Kanal ueber welches Protokoll fuehrt; der richtige Ansatz ist nicht Vermuten, sondern das Verhalten nach der Einrichtung zu beobachten.

Die Beobachtung laeuft so: Wenden Sie die Regel an, pruefen Sie Ihre Ausgangsadresse ausserhalb des Spiels auf einer Kontrollseite und starten Sie dann das Spiel, um zu sehen, ob sich das Verhalten aendert. Hat sich die Ausgangsadresse geaendert, das Verhalten des Spiels aber nicht, liegt der Hauptkanal des Spiels vermutlich ausserhalb des Geltungsbereichs der Regel. Das ist kein Fehler, sondern eine Grenze des Protokolls.

Store-Client, Patch-Download und die eigene Verbindung des Spiels

Auf dem Desktop wird das Spiel in der Regel ueber einen Store-Client installiert und aktualisiert. Dieser Client ist eine eigene Anwendung: mit eigener Download-Engine, eigenem Verbindungspool und meist eigener Proxy-Einstellung. Starten Sie das Spiel, baut es seine eigenen Verbindungen auf. Beide laufen auf derselben Maschine, muessen sich aber nicht dieselbe Regel teilen.

Diese Trennung fuehrt in beide Richtungen zu ueberraschenden Ergebnissen. Sie koennten im Store-Client einen Proxy hinterlegen und glauben, auch der Traffic des Spiels werde umgeleitet; oder umgekehrt laufen bei einer systemweiten Einstellung auch die riesigen Downloads des Store-Clients durch den Tunnel und Ihr Volumen schmilzt unerwartet. Ein Beispiel dafuer, wie die Einstellungen auf Store-Seite funktionieren, finden Sie im Beitrag Proxy-Einstellungen des Store-Clients ; auf dem Desktop ist anwendungsbasiertes Routing besser geeignet, um den Geltungsbereich einzugrenzen, und die Seite Windows-Proxy-Einstellungen listet die grundlegenden Optionen auf.

Auf Mobilgeraeten ist die Trennung noch schaerfer. Updates aus dem App-Store liegen ausserhalb der eigenen Verbindung des Spiels; auch In-App-Kaeufe laufen ueber den Store-Prozess des Betriebssystems. Eine fuer das Spiel geschriebene Regel erfasst diese beiden Stroeme nicht. Das ist meist eine gute Nachricht: Patches gehen nicht von Ihrem volumenbegrenzten Ausgang ab.

Die praktische Empfehlung lautet: Trennen Sie Download und Spielsitzung bewusst. Laden Sie den Patch ueber eine Leitung ohne Volumenlimit und starten Sie das Spiel ueber den Proxy. So bleibt Ihre Volumenplanung vorhersehbar und Ihre Download-Geschwindigkeit wird nicht durch die zusaetzliche Zwischenstation begrenzt.

Wo sammelt sich das monatliche Volumen an?

In diesem Spiel entsteht das Volumen weniger durch die gespielten Matches als durch die betrachteten Grafiken. Am schwersten wiegen die Patches und Asset-Pakete an Release-Tagen; an zweiter Stelle stehen Sammlungs-, Store- und Oberflaechenansichten. Der Match-Traffic selbst ist klein: Die zwischen den Runden gesendeten Nachrichten sind kurz und selten.

Fuer das Volumen ist die Bedeutung dieser Verteilung klar. Bei einem volumenbegrenzten Ausgang liegt die gesamte Einsparung in den ersten beiden Posten, und beide sind vorhersehbare Ereignisse - der Kalender steht fest und den Zeitpunkt des Downloads bestimmen Sie. Den Match-Traffic zu reduzieren ist weder moeglich noch sinnvoll; er macht ohnehin nur einen kleinen Teil des Volumens aus. Wie Sie die Berechnung anstellen, Bandbreitenberechnung steht Schritt fuer Schritt im Beitrag.

Der vierte Posten ist Telemetrie- und Benachrichtigungs-Traffic. Er ist klein, aber kontinuierlich und laeuft weiter, solange die App im Hintergrund geoeffnet bleibt. Auf mehreren Geraeten angemeldet zu bleiben vervielfacht diesen Posten; jeder offene Client sendet seine eigenen Anfragen.

Stuetzen Sie Ihre Volumenplanung auf Messungen. Notieren Sie ueber einen Release-Zyklus hinweg den Verbrauch in Ihrem Panel ereignisbezogen; nach zwei Zyklen haben Sie eine weit verlaesslichere Schaetzung als jeder Durchschnitt, und Ihre Paketentscheidung beruht auf Daten statt auf Vermutungen.