Spiel-Latenz senken: Standort, Route und Code

Die Spiel-Latenz bestimmt den größten Teil der Verzögerung, die ein Spieler auf dem Bildschirm spürt, und sie hat selten nur eine Ursache — es sind mehrere Verzögerungsschichten, die sich übereinander stapeln. Ein praktischer Ansatz ist, die Arbeit in drei Bereiche aufzuteilen: einen Standort physisch nah an den Spielern wählen, die Netzwerkroute, die ein Paket nimmt, verbessern und die Tick-Schleife sowie den Paketfluss im eigenen Code des Servers abstimmen. Dieser Artikel geht alle drei mit echten, anwendbaren Schritten durch.

Woher kommt Latenz?

Die Verzögerung, die ein Spieler sieht, ist eigentlich die Summe mehrerer Teile:

• Ausbreitungsverzögerung: die Strecke, die das Signal über Glasfaser zurücklegt. Licht bewegt sich in Glas mit etwa 200.000 km/s, also bedeuten schon 3.000 km rund ~15 ms Grundverzögerung für eine Richtung. Das lässt sich nicht per Code beseitigen; man verkleinert es nur durch Verkürzen der Distanz.
• Warteschlangen- und Verarbeitungsverzögerung: die Zeit, die ein Paket in Routern auf dem Weg, in der Netzwerkkarte des Servers und in der Spielschleife wartet.
• Serialisierungsverzögerung: die Zeit, das Paket auf die Leitung zu schreiben, spürbar bei großen Paketen mit geringer Bandbreite.
• Tick-Verzögerung: da der Server den Zustand in festen Intervallen aktualisiert, kann eine eingehende Eingabe bis zum nächsten Tick warten.

Das Ziel ist, in jeder Schicht, die du kontrollierst, ein paar Millisekunden zu gewinnen, denn sie summieren sich.

1. Den richtigen Standort wählen

Der größte und günstigste Gewinn kommt meist davon, den Server näher an die Spielerbasis zu bringen. Sind die meisten Spieler in der Türkei und in Europa, spart ein Server in einer zentralen Region wie Frankfurt, Amsterdam oder Istanbul Dutzende Millisekunden gegenüber einem Rechenzentrum in den USA. Eine einzige gute Entscheidung kann mehr ausmachen als alle späteren Optimierungen zusammen.

Miss einen Standort wirklich, bevor du dich festlegst. Um die Grund-Umlaufzeit aus der Zielregion zu sehen:

ping -c 20 server-ip
mtr -rwzc 50 server-ip

Achte in der mtr-Ausgabe bei jedem Hop auf Paketverlust und Latenzspitzen; so unterscheidest du, ob das Problem die Distanz oder ein schlechter Zwischen-Carrier ist. Erstreckt sich deine Spielerbasis über mehrere Kontinente, ist die richtige Antwort regionale Server, die jeden Spieler zum nächstgelegenen leiten, statt eines einzigen riesigen Servers.

2. Die Netzwerkroute verbessern

Selbst wenn die geografische Distanz zwischen zwei Punkten kurz ist, folgt der Internetverkehr manchmal einer langen, schlechten Route. Mit mtr oder traceroute erkennst du unnötige Umwege oder einen Transit-Anbieter mit häufigem Paketverlust.

• Anbieter- und Peering-Qualität: wähle einen Hoster mit guten Peering-Abkommen, der nah an den ISPs deiner Spieler anbindet. Selbst im selben Rechenzentrum nehmen verschiedene Anbieter unterschiedliche Routen.
• Nutze UDP: für Echtzeit-Spielverkehr schaden TCPs Garantien für erneute Übertragung und geordnete Zustellung meist — auf ein verlorenes, veraltetes Positionspaket zu warten verzögert das frische. Die meisten Spiele bauen ihre eigene Zuverlässigkeitsschicht auf UDP auf.
• MTU und Fragmentierung: halte Pakete unter der Pfad-MTU (meist 1500 Byte, mit Tunneln niedriger), damit Fragmentierung und die dadurch entstehende Verzögerung gar nicht erst auftreten.

3. Betriebssystem- und Socket-Einstellungen

Auf der Linux-Seite verkürzen einige Einstellungen, wie lange der Server ein Paket hält. Am wichtigsten ist das Deaktivieren von Nagles Algorithmus, der kleine Pakete bündelt und so interaktivem Verkehr eine sichtbare Verzögerung hinzufügt:

int flag = 1;
setsockopt(fd, IPPROTO_TCP, TCP_NODELAY, &flag, sizeof(flag));

Halte bei UDP-Sockets die Sende-/Empfangspuffer groß genug, um Bursts standzuhalten, und betreibe den Socket im nicht-blockierenden Modus mit epoll. Unter Last ist ein überlaufender Puffer, der Pakete verwirft, eine häufige Ursache für ausschlagenden Ping. Stimme Kernel-Parameter wie net.core.rmem_max auf die tatsächliche Last ab, nicht blind.

4. Tick Rate und die Spielschleife

Der Server aktualisiert die Welt mit einer festen Frequenz (Tick Rate). Eine 20-Hz-Schleife macht alle 50 ms einen Schritt; 60 Hz alle ~16,7 ms. Eine höhere Tick Rate verkürzt, wie lange eine Eingabe auf die Verarbeitung wartet, erhöht aber die CPU-Kosten. In der Praxis bevorzugen schnelle Spiele 30–60 Hz.

Wichtig ist, dass die Schleife fest und vorhersehbar bleibt. Ein sauberer fester Zeitschritt sieht so aus:

const double dt = 1.0 / 30.0; // 30 Hz
double accumulator = 0.0;
double last = now();
while (running) {
    double current = now();
    accumulator += current - last;
    last = current;
    while (accumulator >= dt) {
        update(dt);     // die Simulation voranbringen
        accumulator -= dt;
    }
    flush_outgoing();   // Zustand sofort senden
}

Der entscheidende Punkt hier ist, den Zustand direkt nach update zu senden, statt ihn zu puffern; sonst gibst du den Tick-Gewinn in einer künstlichen Warteschlange wieder her. Verlagere außerdem schwere Arbeit innerhalb eines Ticks (Datenbankschreibvorgänge, Datei-I/O, Logging) auf einen separaten Thread von der Hauptschleife, damit eine einzige langsame Abfrage nicht alle Spieler einfriert.

5. Bandbreite und Jitter steuern

Genauso wichtig wie der reine Ping ist Jitter — die Schwankung der Verzögerung. Stabile 60 ms fühlen sich besser an als ein Ping, der ständig zwischen 20 und 120 springt. Um Jitter zu reduzieren:

• Verkleinere Zustandsupdates mit Deltas (nur senden, was sich geändert hat); weniger Daten bedeuten weniger Serialisierungsverzögerung.
• Halte die Senderate pro Spieler stabil; plötzliche Verkehrsspitzen blähen Warteschlangen auf.
• Nutze einen kleinen Interpolationspuffer auf der Client-Seite, um Netzwerkschwankungen zu glätten.

Häufige Fragen

Senkt eine höhere Tick Rate den Ping?

Nicht den Netzwerk-Ping direkt; die Netzwerkverzögerung hängt von Distanz und Route ab. Aber weil sie verkürzt, wie lange eine Eingabe auf die Verarbeitung wartet, reduziert sie die gesamte Verzögerung, die der Spieler spürt. Stabil und niedrig zählt mehr als hoch.

Soll ich UDP oder TCP verwenden?

UDP für Echtzeit-Positions-/Eingabeverkehr. TCPs geordnete Zustellung schadet, weil das Warten auf ein altes Paket das neue verzögert. Wo Zuverlässigkeit nötig ist (etwa wichtige Ereignisse), baue deine eigene leichte Bestätigungsschicht auf UDP auf.

Meine Spieler sind auf verschiedenen Kontinenten — was tun?

Mit einem Server kannst du nicht alle zufriedenstellen. Betreibe regionale Server und leite jeden Spieler zu dem mit dem niedrigsten gemessenen Ping; physische Distanz lässt sich nicht mit Code schlagen.

Ist der Ping deines Servers zu hoch? Ich kann dir helfen, Verzögerung bei Standort, Netzwerkroute und Spielschleife aufzuspüren und in eine messbare Verbesserung zu verwandeln. Kontaktiere mich und schauen wir uns dein Setup gemeinsam an.