# Game-Lag-Whitepaper (Game Lag White Paper)

> Whitepaper, das 228 Ursachen für Lag in Onlinespielen (Ruckeln, Teleportieren, Rubberbanding, Zeitraffer, Input-Lag, Freeze, Verbindungsabbruch usw.) vom eigenen Bildschirm bis zur Serverdatenbank erklärt, gegliedert in 13 Schichten und 3 Themen (Synchronisationsdesign; Probleme, die nur einige betreffen; TCP-Retransmissions). Der Schwerpunkt liegt auf MMO-Beispielen, das meiste gilt aber genreübergreifend für Onlinespiele allgemein. Zu jeder Ursache: die drei Schritte Warum → Folge → Auf dem Bildschirm, zugehörige Symptome, Größenordnungen, Zuständigkeit (Entwicklungsteam, Infrastrukturteam, Extern) mit Aufgaben pro Team, Graphmuster und Prüfmethode sowie belastbare Quellen (RFCs, offizielle Dokumentation zu Kernel, OS, Cloud, Engines und Datenbanken, wissenschaftliche Arbeiten).

Ursachen werden über ihre ID referenziert (z. B. mem-gc), und jede Ursache hat eine eigene Seite (z. B. https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-gc.html). Die Zahlen sind typische Werte aus dem üblichen Live-Betrieb, Standardwerte und Versionen sind in den Quellen der jeweiligen Ursachenseite belegt. Zum Zitieren bitte die Adresse der Ursachenseite verwenden. MIT-Lizenz. Das Original ist auf Koreanisch, diese Fassung ist eine Übersetzung: https://jungrok5.github.io/mmo-lag-anatomy/

## Dokumente

- [Gesamter Inhalt (Markdown)](https://jungrok5.github.io/mmo-lag-anatomy/de/llms-full.txt): Alle Ursachen, Symptome, Zuständigkeiten, Begriffe und Quellen in einer Datei
- [Textfassung](https://jungrok5.github.io/mmo-lag-anatomy/de/text.html): HTML-Seite mit demselben Inhalt, ohne JavaScript auf einer Seite lesbar
- [Game-Lag-Whitepaper](https://jungrok5.github.io/mmo-lag-anatomy/de/): Interaktive Fassung mit Grafiken und Experimenten zum Selbst-Ausprobieren

## Ursachen nach Symptom

- [Ruckeln](https://jungrok5.github.io/mmo-lag-anatomy/de/s/stutter.html): 60 Ursachen. Bewegungen laufen nicht flüssig: Sie stocken immer wieder kurz und gehen dann weiter.
- [Teleportieren](https://jungrok5.github.io/mmo-lag-anatomy/de/s/teleport.html): 47 Ursachen. Ein Charakter springt ohne sichtbare Bewegung auf einen Schlag an eine weit entfernte Position.
- [Rubberbanding](https://jungrok5.github.io/mmo-lag-anatomy/de/s/rubber.html): 14 Ursachen. Der eigene Charakter läuft vorwärts und wird an eine Stelle zurückgezogen, die er gerade passiert hat.
- [Zeitraffer](https://jungrok5.github.io/mmo-lag-anatomy/de/s/burst.html): 36 Ursachen. Das stehengebliebene Bild läuft wieder an, und aufgestaute Bewegungen, Treffer und Schaden rauschen im Schnelldurchlauf vorbei.
- [Zeitlupe](https://jungrok5.github.io/mmo-lag-anatomy/de/s/slowmo.html): 24 Ursachen. Alles bewegt sich langsamer. Skill-Casts und Monsterbewegungen wirken in die Länge gezogen. Je nach Serverdesign bleibt das Tempo auch gleich, und das Problem zeigt sich als Ruckeln oder Teleportieren.
- [Input-Lag](https://jungrok5.github.io/mmo-lag-anatomy/de/s/delay.html): 76 Ursachen. Zwischen Tastendruck und Ergebnis vergeht spürbar Zeit. Das Bild selbst kann dabei flüssig sein.
- [Freeze](https://jungrok5.github.io/mmo-lag-anatomy/de/s/freeze.html): 67 Ursachen. Alles im Bild bleibt kurz stehen (0,5 s bis einige Sekunden) und läuft dann weiter.
- [Verschluckte Aktion / Rollback](https://jungrok5.github.io/mmo-lag-anatomy/de/s/dropped.html): 36 Ursachen. Eine eindeutig ausgeführte Aktion gilt plötzlich als nie passiert, oder ihr Ergebnis wird deutlich später rückgängig gemacht.
- [Verbindungsabbruch](https://jungrok5.github.io/mmo-lag-anatomy/de/s/disconnect.html): 51 Ursachen. Mitten im Spiel bricht die Verbindung ab, und man landet im Login-Bildschirm oder im Reconnect-Fenster.
- [Kein Login / Endlos-Laden](https://jungrok5.github.io/mmo-lag-anatomy/de/s/noconnect.html): 45 Ursachen. Man kommt nicht ins Spiel oder bleibt im Lade- oder Eintrittsbildschirm hängen.
- [Unsichtbar / Geisterobjekte](https://jungrok5.github.io/mmo-lag-anatomy/de/s/invisible.html): 20 Ursachen. NPCs, Monster oder Spieler, die da sein müssten, fehlen nur auf dem eigenen Bildschirm, oder längst verschwundene Objekte bleiben nur dort stehen.

## L1 Spielprozess auf dem Client

- [Frametime-Spikes](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-hitch.html): Die Berechnung eines einzelnen Frames dauert ein Vielfaches länger als sonst, und das Bild bleibt kurz stehen.
- [Garbage Collection auf dem Client](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-gc.html): Während nicht mehr benötigter Speicher (Garbage) freigegeben wird, steht das ganze Spiel still. Typisch ist Ruckeln in regelmäßigen Abständen.
- [Synchrones Laden und Shader-Kompilierung im Main-Thread](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-sync-load.html): Bevor ein neues Gebiet, ein neues Monster oder ein neuer Effekt zum ersten Mal gezeichnet wird, liest das Spiel Dateien und erzeugt Shader. Währenddessen steht es still.
- [Langsamer Datenträger bremst Asset-Streaming](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-asset-stream.html): Auf langsamen Datenträgern wie HDDs kommt das Einlesen von Texturen und Modellen in einer Open World der Bewegung nicht hinterher. Objekte erscheinen spät, oder das Spiel ruckelt, während es auf Lesevorgänge wartet.
- [Renderlast durch große Spielermengen](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-crowd.html): Sind wie bei Belagerungen oder Weltbossen Hunderte Spieler auf einem Bildschirm, ist schon das Zeichnen selbst nicht mehr zu bewältigen.
- [Engpass bei der Paketverarbeitung im Main-Thread](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-net-mainthread.html): Verarbeitet der Client empfangene Pakete pro Frame nur bis zu einer festen Menge, schieben sich angestaute Pakete immer weiter in die nächsten Frames.
- [Fehlender oder zu kurzer Interpolationspuffer](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-no-buffer.html): Zeichnet der Client Serverpakete sofort nach dem Empfang, wird der Jitter (Schwankung der Ankunftsabstände) direkt auf dem Bildschirm sichtbar.
- [Übermäßige Extrapolation (Dead Reckoning)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-extrap.html): Solange keine Pakete kommen, zeigt der Client das Objekt mit der letzten Geschwindigkeit weiter in Bewegung. Merkt er den Fehler, setzt er es zurück.
- [Abweichende clientseitige Vorhersage](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-predict.html): Der eigene Client zeigt die Bewegung schon vorab. Berechnet der Server sie anders, wird der eigene Charakter zurückgezogen.
- [Aufholspirale bei festem Zeitschritt](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-fixed-step.html): Nach einem einzelnen Stillstand rechnet das Spiel die aufgelaufenen Schritte im Block nach und gerät genau dadurch erneut in Rückstand.
- [Fehler bei der Uhrensynchronisation](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-clock.html): Liegt die vom Client geschätzte Serverzeit daneben, stimmen Interpolationszeitpunkt und Cooldown-Prüfung nicht mehr.
- [Präzisionsverlust bei float-Zeitwerten](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-float-time.html): Hält das Spiel die Spielzeit in einem ungenauen Gleitkommaformat (float), sinkt die Zeitauflösung (kleinster unterscheidbarer Zeitabstand), je länger es läuft. Bewegungen und Effekte zittern.
- [V-Sync und Render-Warteschlange](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-vsync.html): Die GPU legt fertige Frames in eine Warteschlange und gibt sie im Takt des Monitors aus. Solange sie dort warten, kommt die Eingabe verzögert an.
- [Speicherleck im Client](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-leak.html): Je länger das Spiel läuft, desto mehr Speicher belegt es. Es wird zunehmend langsamer und am Ende zwangsweise beendet.
- [Client-Absturz](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-crash.html): Ein nicht abgefangener Fehler beendet das Spiel. Für den Spieler sieht das wie ein Verbindungsabbruch aus, der Server läuft aber normal.
- [Prüfungen des Sicherheitsmoduls (Anti-Cheat)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/cg-anticheat.html): Ein Sicherheitsmodul, das zum Schutz vor Cheats mit dem Spiel läuft, prüft in regelmäßigen Abständen. Ist die Prüfung aufwendig oder kommt der Heartbeat (regelmäßiges Lebenszeichen) zum Sicherheitsserver zu spät, ruckelt das Spiel, oder es kommt zum Verbindungsabbruch.

## L2 Client-OS und Gerät

- [CPU-Belegung durch Hintergrundprozesse](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-background.html): Belegen Virenscans, Windows Update, Streaming-Software oder Videos im Browser die Kerne, bekommt der Game-Thread keine CPU-Zeit und muss warten.
- [Energiesparmodus und Thermal Throttling](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-power.html): Akkubetrieb am Notebook, der Energiesparmodus des Smartphones oder Hitze im Gerät senken die Taktraten von CPU und GPU. Typisch für Hitze: Anfangs läuft alles, nach einer Weile wird es langsamer.
- [Timer-Auflösung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-timer.html): Der Standard-Timer von Windows arbeitet in Schritten von 15,6 ms. Ein „nur 1 ms warten“ dauert deshalb tatsächlich bis zum nächsten Timer-Takt, im ungünstigsten Fall 15,6 ms.
- [Wechsel der mobilen App in den Hintergrund](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-mobile-bg.html): Wird die App kurz minimiert, um eine Benachrichtigung zu lesen, pausiert das OS sie nach einigen Sekunden (Suspend). In dieser Zeit trennt der Server die Verbindung des Spielers.
- [Wechsel WLAN ↔ LTE/5G](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-netswitch.html): Verlässt man das Haus, bricht das WLAN ab, und das Gerät wechselt zu LTE oder 5G. Dabei ändert sich die eigene IP-Adresse, und die bestehende Verbindung wird ungültig.
- [Paketprüfung durch Sicherheitssoftware](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-security.html): Prüfen Virenscanner oder Firewall jedes Paket, steigt die Latenz. Im Extremfall halten sie das Spiel fälschlich für einen Angriff und blockieren es.
- [Überlauf des Empfangspuffers](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-rcvbuf.html): Ist das Spiel zu beschäftigt und holt Pakete zu spät aus dem Socket (der vom OS bereitgestellten Netzwerkschnittstelle zum Senden und Empfangen), läuft der Puffer des OS über.
- [Zu wenig Arbeitsspeicher und Swap auf dem Client](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-swap.html): Laufen Dutzende Browser-Tabs neben dem Spiel, lagert das OS einen Teil des Spielspeichers auf den Datenträger aus.
- [Zu wenig Grafikspeicher (VRAM)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-vram.html): Brauchen die Grafikoptionen mehr Speicher, als die Grafikkarte hat, lagert das OS Texturen in den Arbeitsspeicher des PCs aus und holt sie wieder zurück. Das Bild ruckelt.
- [WLAN-Hintergrundscan](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-wifi-scan.html): Während das OS regelmäßig die Kanäle wechselt, um nach WLANs in der Umgebung zu suchen, setzt die Übertragung kurz aus.
- [NIC-Energiesparmodus und Treiberprobleme](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-driver.html): Gehen Netzwerkkarte oder WLAN-Chip zwischen zwei Paketen in einen Energiesparzustand, braucht das Aufwachen Zeit.
- [Bandbreitenbelegung durch andere Apps auf demselben Gerät](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-other-apps.html): Laufen Cloud-Synchronisation, große Downloads oder Spiel-Patches auf demselben PC, warten die Spielpakete in der Warteschlange.
- [Drosselung bei minimiertem oder inaktivem Fenster](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-unfocused.html): Wechselt man in ein anderes Fenster oder minimiert das Spiel, lassen Spiel und Windows es zum Stromsparen langsamer laufen. Bei der Rückkehr kommen die aufgestauten Pakete auf einmal, oder die Verbindung ist schon abgebrochen.
- [Störung durch Overlay-Programme](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-overlay.html): Messenger, Launcher, Aufnahmeprogramme und FPS-Anzeigen klinken sich in das Rendering des Spiels ein (Hooking), um ihre eigene UI über das Spielbild zu zeichnen. Das kostet in jedem Frame zusätzliche Arbeit und kollidiert gelegentlich mit dem Spiel, sodass es stockt oder zwangsweise beendet wird.
- [Latenz von Display, Eingabegeräten und Frame Generation](https://jungrok5.github.io/mmo-lag-anatomy/de/c/co-display-input.html): Ist der Ping normal, die Steuerung aber schwerfällig, fügen womöglich die Bildverarbeitung des Fernsehers, ein kabelloser Controller oder Frame Generation Verzögerung zwischen Eingabe und Bild ein.

## L3 Heimnetz

- [WLAN-Funkstörungen und schwaches Signal](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-wifi.html): Bei schwachem Signal oder Störungen muss auf der Funkstrecke mehrfach erneut gesendet werden, und die Pakete kommen unregelmäßig an.
- [Überlasteter WLAN-Kanal](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-channel.html): Wo wie in großen Wohnanlagen Dutzende Router funken, teilen sie sich denselben Kanal und müssen auf Sendegelegenheiten warten.
- [Bufferbloat (Warteschlange im Router)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-bufferbloat.html): Lädt jemand im Haushalt ein Video hoch oder eine große Datei herunter, stauen sich im Router Pakete für mehrere hundert ms, und die Spielpakete warten dahinter.
- [Ablauf des NAT-Mappings](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-nat.html): Router löschen Idle-Verbindungen, über die eine Weile keine Pakete gelaufen sind, aus der NAT-Tabelle. Das ist eine häufige Ursache dafür, dass die Verbindung genau dann abbricht, wenn man sich nach einer Pause wieder bewegt.
- [Leistungsschwacher oder überhitzter Router](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-router.html): Hängen an einem billigen Router Dutzende Geräte mit Tausenden Verbindungen, kommt der Router selbst nicht mehr mit.
- [Handover zwischen Funkzellen (unterwegs)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-handover.html): Unterwegs in Bus oder U-Bahn setzt die Verbindung aus, während die Funkzelle wechselt.
- [Verzögerung beim RRC-Zustandswechsel (Energiesparen im Mobilfunk)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-rrc.html): Ohne Datenverkehr schaltet das Smartphone die Funkverbindung nach einer Weile in einen Energiesparzustand und muss sie beim nächsten Paket erst wieder hochfahren. Das kostet Zeit.
- [Schwaches Mobilfunksignal und Funklöcher](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-weak-cell.html): In Aufzügen, im Untergeschoss oder tief im Gebäudeinneren nehmen Retransmissions zu, die Geschwindigkeit sinkt, und schließlich bricht die Verbindung ab.
- [Häufiger Wechsel 5G↔LTE (Rand der 5G-Abdeckung)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-5g-flip.html): In Gebäuden mit schwachem 5G-Signal oder am Rand der 5G-Abdeckung wechselt das Smartphone häufig zwischen 5G und LTE. Bei jedem Wechsel schlägt der Ping aus, oder die Verbindung setzt kurz aus.
- [Einschränkungen in öffentlichen WLANs und Firmennetzen](https://jungrok5.github.io/mmo-lag-anatomy/de/c/hn-captive.html): Die Login-Seite im Café-WLAN oder die Firewall der Firma blockiert die Spielverbindung.

## L4 Internetleitung

- [Signallaufzeit (physische Entfernung)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-distance.html): Selbst Licht legt in Glasfaser nur etwa 200.000 km pro Sekunde zurück. Ein weit entfernter Server bleibt langsam, so gut er auch ist.
- [Satelliteninternet (LEO und geostationär)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-satellite.html): Beim Satelliteninternet muss das Funksignal durch den Weltraum hin und zurück. Bei geostationären Satelliten dauert allein der Round Trip über 0,5 s. LEO-Satelliten wie Starlink sind normalerweise schnell, doch im Moment der Routen-Neuzuweisung schwankt die Latenz, und die Verbindung kann kurz abreißen.
- [Umweg-Routing](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-routing.html): Wegen der Verbindungsverträge zwischen Providern laufen Daten selbst zu nahen Servern über weit entfernte Umwege.
- [Überlast am Peering-Punkt zur Stoßzeit](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-peak.html): Abends zwischen etwa 21 und 23 Uhr schnellt der Video-Traffic in die Höhe, und die Übergänge zwischen Providern (Peering) sind dann leicht überlastet.
- [Störung an Unterseekabel oder Auslandsleitung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-cable.html): Reißt ein Unterseekabel, läuft der Traffic bis zur Reparatur wochenlang (im schlimmsten Fall monatelang) über weite Umweg-Routen, und die verbleibenden Leitungen sind überlastet.
- [BGP-Routenwechsel und Konvergenz](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-bgp.html): Ändern sich Routing-Informationen im Internet, gehen Pakete verloren, bis die Routen wieder konvergiert sind. Das dauert einige bis einige Dutzend Sekunden (selten einige Minuten).
- [Einzelner defekter ECMP-Pfad](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-ecmp.html): Provider und Rechenzentren halten mehrere Pfade zum selben Ziel vor und legen für jede Verbindung einen davon fest. Fällt nur ein Pfad aus, laggt es dauerhaft nur für die Spieler, die diesem Pfad zugewiesen sind.
- [Drosselung und Traffic-Management durch den Provider](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-shaping.html): Ist das Datenvolumen aufgebraucht oder verwaltet der Tarif bestimmten Datenverkehr gezielt, werden Pakete verzögert oder verworfen.
- [UDP-Beschränkung und Paketinspektion auf Landes- oder Providerebene](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-udp-block.html): 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.
- [Schlechte Leitungsqualität](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-line.html): Wackelkontakte an Anschlüssen, alte Leitungen oder ein defektes Modem verursachen dauerhaften Paketverlust und wiederkehrende Leitungsabbrüche.
- [DNS-Störung oder -Verzögerung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-dns.html): Ist das DNS, das Servernamen in Adressen übersetzt, langsam oder fällt aus, werden Login- und Patch-Server nicht gefunden.
- [Vollauslastung gemeinsamer Leitungen durch DDoS](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-ddos-path.html): Ein massiver Angriff auf den Spielebetreiber oder auf ein anderes Ziel im selben Netz lastet gemeinsam genutzte Leitungen voll aus.
- [Geteilte Provider-IP (CGNAT)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-cgnat.html): In Mobilfunknetzen und bei manchen Providern teilen sich viele Kunden eine IP-Adresse, und die Mappings von Idle-Verbindungen werden schon nach kurzer Zeit gelöscht.
- [Umweg über VPN oder Ping-Booster](https://jungrok5.github.io/mmo-lag-anatomy/de/c/isp-vpn.html): Mit aktivem VPN oder Ping-Booster laufen die Pakete über die Relay-Server des Anbieters. Sind diese weit entfernt oder überlastet, wird die Verbindung sogar langsamer.

## L5 Netzwerkgeräte im Rechenzentrum

- [Volle Session-Tabelle der Firewall](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-firewall.html): Die Firewall verfolgt jede durchgelassene Verbindung in ihrer Session-Tabelle. Ist die Tabelle voll, kann sie keine neuen Verbindungen mehr annehmen.
- [Umweg über DDoS-Schutz und False Positives](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-ddos.html): Wird der Traffic zur Abwehr eines Angriffs über ein Scrubbing-Center umgeleitet, wird die Route länger, und legitime Spieler werden manchmal fälschlich als Angreifer blockiert.
- [Idle-Timeout des Load-Balancers](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-lb-idle.html): Load-Balancer löschen Idle-Verbindungen nach einer bestimmten Zeit. Das Spiel hält die Verbindung weiter für bestehend, bis es zum Verbindungsabbruch kommt.
- [Ablauf des Connection Trackings in Cloud-Security-Groups](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-cloud-conntrack.html): Auch die Firewall einer Cloud-Instanz (Security Group) verfolgt Verbindungen, und Tracking-Einträge von Idle-Verbindungen laufen nach einer festen Zeit ab. Deshalb können auch Spieler, die ohne Load-Balancer direkt mit dem Server verbunden sind, nach einer Ruhephase die Verbindung verlieren.
- [Verbindungs- und Portlimits des Cloud-NAT-Gateways](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-nat-gateway.html): Verbindungen von Servern in einem privaten Subnetz nach außen (Plattform-Authentifizierung, Zahlung, externe APIs) laufen über ein NAT-Gateway, das Adresse und Port umschreibt. Übersteigen die gleichzeitigen Verbindungen zum selben Ziel das Port-Limit des Gateways, schlagen neue Verbindungen fehl.
- [Load-Balancer-Schieflast und fehlerhafte Health-Checks](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-lb-imbalance.html): Verbindungen landen alle auf einem Server, oder Spieler werden weiter zu einem Server geschickt, der längst ausgefallen ist.
- [Microbursts am Switch](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-microburst.html): Senden mehrere Server im selben Moment Pakete an Tausende Spieler, läuft der kleine Puffer am Switch-Port, an dem dieser Traffic zusammenläuft, in weniger als 1 ms über.
- [Vollauslastung der Rechenzentrumsanbindung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-uplink.html): Nutzen Patch-Verteilung, Log-Übertragung oder Backups dieselbe Leitung wie das Spiel, läuft die Leitung voll.
- [Failover von Netzwerkgeräten](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-failover.html): Fällt ein Router oder eine Firewall aus und wird auf das Ersatzgerät umgeschaltet (Failover), haben alle Spieler einige Sekunden lang einen Freeze.
- [Defekte Kabel und Portfehler](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-bad-cable.html): Sind optische Module oder Kabel defekt, wird ein fester Anteil der Pakete auf diesem Pfad beschädigt.
- [MTU-Mismatch (nur große Pakete verschwinden)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dc-mtu.html): Ist die MTU (maximale Paketgröße pro Sendung) auf einem Abschnitt unterwegs kleiner und wird die Meldung „Paket zu groß“ blockiert, verschwinden ständig nur die großen Pakete.

## L6 Netzwerkkarte des Servers

- [NIC-Interrupts auf nur einem Kern](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-irq.html): Schickt die NIC die Interrupts für eintreffende Pakete nur an einen CPU-Kern, wird dieser Kern zum Engpass.
- [Zu kleiner Ringpuffer](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-ring.html): Ist der Ringpuffer klein, in dem die NIC Pakete kurz ablegt, läuft er bei kurzen Lastspitzen über, und Pakete werden verworfen.
- [Zu starkes Interrupt-Coalescing](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-coalesce.html): Sammelt die NIC Pakete, um die CPU zu entlasten, und meldet sie gebündelt, verzögern sie sich um die Sammelzeit.
- [Überschrittenes PPS-Limit in der Cloud](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-cloud-pps.html): Cloud-Server haben je nach Typ Limits für Pakete pro Sekunde und Bandbreite. Was darüber hinausgeht, wird stillschweigend verworfen.
- [Vollauslastung der NIC-Bandbreite](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-saturate.html): Wird eine 1-Gbps- oder 10-Gbps-Karte bis an ihre Grenze ausgelastet, wächst die Sende-Queue, und am Ende werden Pakete verworfen.
- [Virtualisierungs-Overhead und Noisy Neighbor](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-noisy.html): Nutzen andere VMs auf demselben physischen Server viel Netzwerk oder CPU, verzögert sich die Verarbeitung auf dem eigenen Server unregelmäßig.
- [Wartung des Cloud-Hosts und Live-Migration](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-host-maintenance.html): Wartet der Cloud-Anbieter einen physischen Server (Host), verschiebt er die VMs auf einen anderen Host (Live-Migration) oder hält sie kurz an. Währenddessen steht der ganze Server still, und dauert der Stillstand lange, brechen Verbindungen ab.
- [Probleme mit NIC-Treiber oder -Firmware](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-reset.html): Hängt sich die Karte durch einen Treiberfehler oder eine fehlerhafte Funktion auf und startet neu, ist währenddessen jedes Senden und Empfangen unterbrochen.
- [Verzögerung durch GRO/LRO-Zusammenfassung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/nic-offload.html): Diese Funktion fasst mehrere Pakete zu einem zusammen, um die CPU zu entlasten. Je nach Einstellung wartet ein kleines Spielpaket dabei kurz auf das nächste Paket, mit dem es zusammengefasst werden kann.

## L7 Server-OS (Kernel)

- [Überlauf der Verbindungswarteschlange (Backlog)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-backlog.html): Melden sich direkt nach einer Wartung Zehntausende gleichzeitig an, läuft die Verbindungswarteschlange (Backlog) des Kernels über, und Verbindungsversuche werden verworfen.
- [Dateideskriptor-Limit](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-fd.html): Jede Verbindung braucht einen Dateideskriptor (fd, die Nummer, die das OS einer geöffneten Datei oder einem Socket zuweist). Wie viele fd ein Prozess öffnen darf, ist begrenzt.
- [Zu kleine Socket-Puffer im Kernel](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-sockbuf.html): Sind Sende- und Empfangspuffer zu klein, werden bei Burst-Traffic per UDP empfangene Pakete verworfen, und das Senden per TCP blockiert, weil im Puffer kein Platz mehr ist.
- [Zu viele Threads und Kontextwechsel](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-context.html): Laufen weit mehr Threads als Kerne, verbraucht das OS CPU-Zeit allein damit, sie abwechselnd auszuführen.
- [CPU-Steal (virtuelle Maschine)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-steal.html): Während der physische Server (Hypervisor) die CPU-Zeit einer virtuellen Maschine kurz an eine andere VM vergibt (CPU-Steal), steht der Spielserver still.
- [CPU-Throttling im Container (CFS-Quota)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-cpu-quota.html): Hat ein Container ein CPU-Limit und verbraucht er sein Kontingent innerhalb der festen Periode (meist 100 ms), wird er für den Rest der Periode zwangsweise angehalten (Throttling).
- [Latenzspitzen durch Energieverwaltung des Servers (C-States und Frequenzskalierung)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-cstate.html): Ungenutzte CPU-Kerne gehen zum Stromsparen in tiefe Energiesparzustände (C-States) und senken ihren Takt. Kommt ein Paket oder ein Timer, brauchen sie Zeit zum Aufwachen und Hochtakten, und die Verarbeitung kleiner Pakete verzögert sich.
- [OOM-Killer](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-oom.html): Geht der Arbeitsspeicher aus, wählt Linux den Prozess mit dem größten Speicherverbrauch und beendet ihn zwangsweise. Meist trifft es den Spielserver.
- [Stillstand durch Speicherrückgewinnung (Reclaim) und Compaction](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-reclaim.html): Während das OS den Speicher kompaktiert, um große Seiten (Huge Pages) zu erzeugen, oder freien Speicher zurückgewinnt, steht der Prozess still.
- [Sprung der Systemuhr (NTP-Step)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-timejump.html): Wird die Serveruhr auf einen Schlag um einige Sekunden vor- oder zurückgestellt, lösen Timer, die von der Systemuhr abhängen, gesammelt aus oder bleiben stehen.
- [Zeitgesteuerte Jobs](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-cron.html): Log-Komprimierung, Backups und Sicherheitsscans, die jeden Tag zur selben Zeit laufen, belegen CPU und Datenträger.
- [Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-os-update.html): Der Spielcode ist unverändert, doch nach einem Update von Server-OS, Kernel, Treibern oder Firmware wird es langsamer. Updates können Standardwerte, den Scheduler, die Schutzmaßnahmen gegen CPU-Sicherheitslücken (Mitigations) und das Verhalten von Treibern ändern.
- [Volle conntrack-Tabelle auf dem Server](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-conntrack.html): Die Linux-Firewall erfasst jede Verbindung in der Tabelle für Connection Tracking (conntrack). Erreicht diese Tabelle ihr Limit, werden neue Pakete verworfen.
- [Erschöpfte ephemere Ports bei Verbindungen zwischen Servern](https://jungrok5.github.io/mmo-lag-anatomy/de/c/so-ports.html): Baut der Spielserver Verbindungen zur DB oder zu anderen Servern häufig nur kurz auf und wieder ab, belegen beendete Verbindungen ihren Port noch eine Weile, und neue Verbindungen lassen sich nicht mehr öffnen.

## L8 Sockets und Protokolle

- [TCP-Head-of-Line-Blocking](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-hol.html): Um die Reihenfolge einzuhalten, gibt TCP später eingetroffene Pakete erst an das Spiel weiter, wenn ein verlorenes Paket erneut angekommen ist.
- [TCP-RTO und exponentielles Backoff](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-rto.html): Mit jeder weiteren gescheiterten Retransmission verdoppelt sich die Wartezeit, und aus einer kurzen Leitungsunterbrechung wird ein langer Stillstand.
- [Nagle-Algorithmus + Delayed ACK](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-nagle.html): Der Nagle-Algorithmus sammelt kleine Pakete, Delayed ACK schickt die Bestätigung verzögert. Zusammen verzögern beide jede in Teilen geschriebene Nachricht um 40–200 ms.
- [Blockierendes Senden durch langsame Clients](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-block-send.html): Ist der Sendepuffer eines einzelnen Spielers mit langsamer Leitung voll und sendet der Server blockierend (der Aufruf kehrt erst zurück, wenn im Puffer wieder Platz ist), wartet der Server-Thread auf diesen einen Spieler.
- [Strategie für langsame Clients (Slow Consumer)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-slow-client.html): Bei einem Client, für den sich immer mehr zu sendende Daten anstauen, verwirft der Server veraltete Updates oder trennt die Verbindung.
- [Keepalive-Standardwert von 2 Stunden](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-keepalive.html): Verschwindet die Gegenseite ohne Abschlusssignal, bemerkt TCP das erst sehr spät. Keepalive (eine TCP-Funktion, die prüft, ob eine Idle-Verbindung noch lebt) ist standardmäßig aus und beginnt selbst eingeschaltet erst nach 2 Stunden Leerlauf mit der Prüfung.
- [IP-Fragmentierung von UDP-Paketen](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-fragment.html): UDP-Pakete, die größer als die MTU (die maximale Größe, die auf einmal gesendet werden kann) sind, werden auf IP-Ebene fragmentiert. Geht nur ein Fragment verloren, wird das ganze Paket verworfen.
- [Retransmission-Einstellungen bei zuverlässigem UDP](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-reliable-udp.html): Sind die selbst gebauten Retransmission-Regeln auf UDP zu vorsichtig, erholt sich die Übertragung erst spät. Sind sie zu aggressiv, verstopfen sie die Leitung zusätzlich.
- [Slow Start nach Leerlauf](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-slowstart.html): Nach einer Weile Leerlauf verkleinert TCP das Congestion Window (die Menge, die auf einmal gesendet werden darf) wieder. Werden dann plötzlich große Datenmengen gesendet, gehen sie in mehreren Etappen hinaus.
- [Einbruch der Senderate durch Congestion Control](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-congestion.html): TCP wertet Paketverlust als Zeichen von Überlast und senkt die Senderate um 30–50 %. Auf Paketverlust im WLAN reagiert es genauso.
- [Verlust der letzten Daten durch harten Abbruch per RST](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-linger.html): Trennt der Server eine Verbindung überstürzt, gehen der zuletzt gesendete Hinweis oder die Bestätigung des Speicherns verloren.
- [Blockierende I/O-Architektur](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-blocking-io.html): Kann ein Thread nichts anderes tun, während er auf einen Socket wartet, wird mit steigender Spielerzahl alles langsamer.
- [Schieflast bei der SO_REUSEPORT-Verteilung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-reuseport.html): Teilen sich mehrere Prozesse denselben Port, legt der Kernel für jede Verbindung per Adress-Hash fest, welcher Prozess zuständig ist, und ändert das danach nicht mehr. Steht dieser Prozess still, warten nur die ihm zugeordneten Spieler.
- [WSAECONNRESET-Fehler bei UDP-Sockets unter Windows](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sk-udp-connreset.html): Sendet ein Windows-Server UDP an einen Client, der schon weg ist, kommt eine ICMP-Meldung „Port nicht erreichbar“ zurück. Durch diese Meldung endet der nächste Empfangsaufruf mit einem Fehler. Behandelt der Servercode diesen Fehler als Defekt des Sockets selbst, sind alle betroffen, die diesen Socket nutzen.

## L9 Spielprozess auf dem Server

- [Überschrittenes Tick-Budget](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-tick-overrun.html): Passt die Arbeit eines Ticks nicht mehr ins Budget, dehnt sich das Tick-Intervall des Servers. Das ganze Gebiet läuft dann langsamer oder ruckelt.
- [Explodierende Sichtbereichsberechnung (AOI, N²)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-aoi.html): Wird für alle Spieler paarweise geprüft, wer wen sehen kann, wächst der Rechenaufwand bei 10-mal so vielen Spielern auf das 100-Fache.
- [Explodierende Broadcast-Last](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-broadcast.html): Wird jede Bewegung eines Spielers an alle geschickt, die ihn sehen, wächst die Zahl der zu sendenden Updates mit dem Quadrat der versammelten Spieler.
- [Überlastetes Gebiet auf einem einzelnen Thread (Hotspot)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-hotzone.html): Ist jedes Gebiet einem einzelnen Thread zugeordnet und drängen sich viele Spieler an einem Ort, läuft nur dieser eine Kern auf 100 %.
- [Lock-Contention](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-lock.html): Warten mehrere Threads auf denselben Lock, um auf dieselben Daten zuzugreifen, läuft trotz zusätzlicher Threads immer nur einer zur Zeit.
- [Deadlock](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-deadlock.html): Wartet jeder von zwei Threads auf den Lock, den der andere hält, stehen beide für immer still.
- [Synchrone Aufrufe im Game-Thread](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-sync-call.html): Wartet der Server mitten im Tick auf eine DB-Antwort oder einen Schreibvorgang, steht das gesamte Spielgeschehen für genau diese Zeit still.
- [Rückstau in der Message-Queue](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-queue.html): Kommen Anfragen schneller herein, als sie verarbeitet werden, stauen sie sich in der Warteschlange. Spätere Anfragen werden dann erst nach einigen Sekunden verarbeitet oder verworfen.
- [Gleichzeitig auslösende Timer](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-timer-burst.html): Fallen alle Monster-Respawns, alle Buff-Abläufe und die Belohnungen zur vollen Stunde in denselben Tick, ist dieser eine Tick Dutzende Male so aufwendig wie sonst.
- [Pathfinding-Flut](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-pathfinding.html): Verfolgen Hunderte Monster gleichzeitig Spieler und berechnen dabei ihre Wege, kostet das viel CPU-Zeit.
- [Kosten für Serialisierung und Kompression](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-serialize.html): Auch das Umwandeln der Sendedaten in Bytes und ihre Kompression kosten CPU-Zeit. Bei vielen Spielern schießen diese Kosten in die Höhe.
- [Serverabsturz](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-crash.html): Stürzt der Serverprozess durch einen unbehandelten Fehler ab, bricht für alle auf diesem Server gleichzeitig die Verbindung ab.
- [Erschöpfter Thread-Pool](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-threadpool.html): Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit.
- [Endlosschleife und außer Kontrolle geratene Logik](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-infinite-loop.html): Endet ein Tick wegen eines Bugs nicht, bleibt der Server stehen, und der Watchdog startet ihn zwangsweise neu.
- [Auf ein Ziel konzentrierter Kampf (Weltboss)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-hot-entity.html): Greifen Hunderte Spieler gleichzeitig einen einzigen Boss an, ballt sich die Berechnung auf diesen einen Boss, und jeder Treffer wird an alle gesendet, die ihn sehen.
- [Spawn-Flut beim Betreten belebter Gebiete](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-spawn-burst.html): Reist man per Teleport in eine volle Stadt, muss der Server Aussehen, Ausrüstung und Zustand von Hunderten neu sichtbarer Spieler auf einmal senden.
- [Anhäufung von Objekten (nicht aufgeräumte Items und Beschwörungen)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-entity-buildup.html): Werden Items am Boden, Beschwörungen und abgelaufene Timer, die längst verschwunden sein sollten, nicht aufgeräumt, wächst die Arbeit pro Tick, je länger der Server läuft.
- [Patch verändert das Traffic-Muster](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sp-patch-traffic.html): Vergrößern neue Inhalte, Effekte oder synchronisierte Felder die Pakete oder erhöhen ihre Frequenz, stößt ein bisher stabiler Server nach dem Patch an Grenzen bei MTU, Bandbreite oder Paketzahl.

## L10 Arbeitsspeicher

- [Stop-the-World-GC-Pause auf dem Server](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-gc.html): Während ein Java- oder C#-Server alle Threads anhält, um Garbage einzusammeln (Stop-the-World), steht der gesamte Server still.
- [GC-Pause der Skript-Engine](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-script-gc.html): Laufen Quests, KI und Skills in einer Skriptsprache wie Lua, steht selbst auf einem C++-Server die Zone still, solange die GC der Skript-Engine läuft.
- [Allokationsflut](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-alloc.html): Entstehen während eines Events massenhaft temporäre Objekte, läuft die GC viel häufiger als sonst.
- [Speicherleck](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-leak.html): Nicht freigegebener Speicher sammelt sich nach und nach an und führt Tage später zu GC-Stürmen, Swapping oder zum erzwungenen Beenden des Prozesses.
- [GC-Thrashing (zu wenig Heap-Reserve)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-gc-thrash.html): Nähern sich die lebenden Daten der Heap-Grenze, findet jede GC kaum noch etwas zum Freigeben, und die GC läuft ununterbrochen immer wieder.
- [Swap](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-swap.html): Wird der Arbeitsspeicher knapp und lagert das OS einen Teil auf den Datenträger aus, wartet jeder Zugriff auf diesen Speicher auf einen über 1.000-mal langsameren Datenträger.
- [Cache-Miss](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-cache-miss.html): Liegen Daten verstreut im Speicher, muss die CPU jedes Mal bis zum langsamen RAM gehen und warten.
- [Speicherfragmentierung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-fragment.html): Zerfällt freier Speicher durch ständiges Allozieren und Freigeben in kleine Stücke, belegt der Prozess viel mehr Speicher, als er tatsächlich nutzt.
- [Entfernter NUMA-Speicher](https://jungrok5.github.io/mmo-lag-anatomy/de/c/mem-numa.html): Nutzt ein Prozess auf einem Server mit zwei CPUs Speicher, der an der anderen CPU hängt, werden die Zugriffe langsamer.

## L11 Datenträger

- [Synchrones Schreiben von Logs](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-sync-log.html): Wartet der Game-Thread bei jeder Logzeile, bis der Datenträger fertig ist, bleibt bei ausgelastetem Datenträger auch das Spielgeschehen stehen.
- [fsync-Flut](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-fsync.html): Eine Anfrage, Daten „sicher“ auf den Datenträger zu schreiben, dauert je nach Datenträger 0,1 ms bis einige Dutzend ms. Häufen sich solche Anfragen, wird die Warteschlange lang.
- [Aufgebrauchte Burst-Credits beim Cloud-Datenträger](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-burst.html): Manche Cloud-Datenträger und kleine Servergrößen haben Burst-Credits, mit denen sie kurzzeitig schneller als ihre Basisleistung arbeiten. Dauert eine Lastphase lange und sind die Credits aufgebraucht, sinkt die Geschwindigkeit schlagartig.
- [IOPS-Limit und volle Warteschlange](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-iops.html): Kommen mehr Anfragen, als der Datenträger pro Sekunde bewältigt, wird die Warteschlange lang und die Latenz explodiert.
- [Datenträger voll](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-full.html): Füllen angesammelte Logs und Dumps den Datenträger, schlagen Schreibvorgänge fehl. Ohne Vorkehrungen stürzt der Server ab.
- [Backup-, Komprimierungs- und Scan-Jobs](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-backup.html): Belegen nächtliche Backups, Log-Komprimierung oder Sicherheitsscans den Datenträger, stauen sich die Lese- und Schreibzugriffe des Spielservers.
- [Lazy Loading auf dem Server](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-lazy-load.html): Liest der Server Dungeon- oder Kartendaten erst bei der ersten Anfrage vom Datenträger, stehen alle still, bis dieser Tick fertig ist.
- [Schreiben von Core-Dumps](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-coredump.html): Stürzt der Server ab, schreibt er mehrere GB Arbeitsspeicher auf den Datenträger. Das kann den Neustart um einige Minuten verzögern.
- [Seek-Latenz von HDDs](https://jungrok5.github.io/mmo-lag-anatomy/de/c/dk-hdd.html): Bei einer HDD muss sich der Schreib-/Lesekopf über die Magnetscheibe bewegen (Seek). Verstreute Daten zu lesen oder zu schreiben dauert deshalb pro Zugriff fast 10 ms.

## L12 Datenbank

- [Query ohne Index](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-no-index.html): Ohne Index muss die DB die ganze Tabelle lesen, um die passenden Zeilen zu finden (Full Table Scan).
- [Hot-Row-Lock-Contention](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-hot-row.html): Wollen alle dieselbe Zeile ändern (Gildenlager, begehrtes Item im Auktionshaus, serverweiter Zähler), bekommt immer nur einer den Lock.
- [DB-Deadlock](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-deadlock.html): Warten zwei Transaktionen (DB-Operationen, die als ein Paket verarbeitet werden) jeweils auf eine Zeile, die die andere gesperrt hat, bricht die DB eine davon zwangsweise ab.
- [Erschöpfter Connection-Pool](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-pool.html): Die Zahl der Verbindungen zur DB ist fest. Belegen langsame Queries die Verbindungen, müssen alle anderen Anfragen warten.
- [Replikationsverzögerung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-replica-lag.html): Geschrieben wird in die Primär-DB, gelesen aus dem Replikat. Hinkt das Replikat hinterher, ist gerade Geschriebenes dort noch nicht zu sehen.
- [Checkpoint und Log-Flush](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-checkpoint.html): Schreibt die DB in regelmäßigen Abständen die Änderungen aus dem Arbeitsspeicher gebündelt auf den Datenträger, werden Queries in diesem Moment langsam.
- [Kalter Cache (direkt nach Neustart)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-cold-cache.html): Nach einem Neustart der DB ist der Cache im Arbeitsspeicher leer, und eine Zeit lang wird jede Abfrage vom Datenträger gelesen.
- [Login-Ansturm und N+1-Queries](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-login-storm.html): Fragt das Laden eines einzigen Charakters die DB einige Dutzend Mal einzeln ab, werden aus Zehntausenden gleichzeitigen Logins Millionen von Queries.
- [Große Batch-Jobs](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-batch.html): Laufen Ranglistenberechnung, Massenversand von Ingame-Post oder das Aufräumen alter Daten im laufenden Betrieb, belegen sie Locks und Datenträger.
- [DB-Failover](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-failover.html): Fällt die Primär-DB aus und wird auf die Reserve-DB umgeschaltet, sind währenddessen keine Schreibvorgänge möglich, und die letzten noch nicht replizierten Daten können verloren gehen.
- [Fortschrittsverlust durch lange Speicherintervalle](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-save-interval.html): Wird zur Lastsenkung nur alle paar Minuten gespeichert, geht der Fortschritt verloren, wenn der Server dazwischen abstürzt.
- [Cache-Stampede](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-cache-stampede.html): Laufen die Cache-Einträge beliebter Daten gleichzeitig ab, stürzen sich Tausende Anfragen auf einmal auf die DB.
- [Lange offene Transaktion](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-long-tx.html): Bleibt eine Transaktion lange offen, hält sie ihre Locks weiter, und die DB kann alte Datenversionen nicht bereinigen (Purge). Dadurch wird alles nach und nach langsamer.
- [Langsame Redis-Befehle](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-redis-block.html): Redis arbeitet Befehle einzeln nacheinander ab. Ein einziger langsamer Befehl blockiert deshalb alle nachfolgenden Anfragen.
- [Langsame Query durch geänderten Ausführungsplan](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-plan-flip.html): Ändert die DB bei unverändertem Code die Art, wie sie dieselbe Query abarbeitet (Ausführungsplan), dauert eine Query, die gestern 2 ms brauchte, heute mehrere hundert ms.
- [Locks durch Schemaänderung (DDL) im laufenden Betrieb](https://jungrok5.github.io/mmo-lag-anatomy/de/c/db-ddl-lock.html): Werden einer Tabelle im laufenden Betrieb Spalten oder Indizes hinzugefügt, kann ein einziger, nur kurz benötigter Lock alle Anfragen auf diese Tabelle warten lassen.

## L13 Serverarchitektur und Betrieb

- [Gateway oder Proxy als Zwischenstation](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-gateway.html): Steht zwischen Client und Spielserver ein Zwischenserver, kommt bei jeder Station Verarbeitungszeit hinzu, und dieser Server wird zum Single Point of Failure.
- [Zonenwechsel (Übergabe zwischen Servern)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-zone-transfer.html): Beim Betreten eines anderen Gebiets oder Dungeons werden die Charakterdaten an einen anderen Server übergeben. Dabei kommt es zu Verzögerungen und Fehlschlägen.
- [Kaskadierender Ausfall](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-cascade.html): Wird ein Dienst langsam, hängen die Server, die ihn aufrufen, beim Warten auf Antworten fest, und selbst unbeteiligte Funktionen bleiben stehen.
- [Ausfall eines Zusatzservers](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-subservice.html): Fällt ein Server aus, der getrennt vom Spielserver läuft, etwa für Chat, Gruppen oder das Auktionshaus, funktioniert nur diese eine Funktion nicht mehr.
- [Deployment und Neustart](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-deploy.html): Werden Server für ein Update neu gestartet, ohne die Verbindungen umzuziehen, verlieren alle Spieler auf diesem Server die Verbindung. Speichervorgänge kurz vor dem Herunterfahren und anschließende Reconnects ballen sich.
- [Verzögertes Autoscaling](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-autoscale.html): Bei großem Andrang werden automatisch weitere Server gestartet, doch die Vorbereitung dauert einige Minuten. In dieser Zeit sind die vorhandenen Server überlastet.
- [Überlastung durch Logging und Monitoring](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-monitoring.html): Bei einer Störung explodiert die Logmenge, und Server, die Logs synchron weitergeben, werden durch das Logging noch langsamer.
- [Uhrenabweichung zwischen Servern](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-clock-skew.html): Gehen die Uhren der Server leicht unterschiedlich, werden Cooldowns, Buffs und Eventstarts auf jedem Server etwas anders bewertet.
- [Zu viele Makros und Bots](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-bots.html): Bots senden viel häufiger Anfragen als Menschen und zehren die Verarbeitungskapazität des Servers auf.
- [Abhängigkeit von externen Diensten](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-external.html): Sind externe Dienste wie Plattform-Login, Zahlung oder Identitätsprüfung langsam oder ausgefallen, bleibt der Vorgang an diesem Schritt hängen.
- [Fehlerhaftes Matchmaking oder falsche Regionszuweisung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-region-match.html): Wird ein Spieler einem Server in einer weit entfernten Region zugewiesen, obwohl es eine nähere gibt, hat genau dieser Spieler dauerhaft hohen Ping, auch wenn seine Leitung in Ordnung ist.
- [Abgelaufenes oder falsch konfiguriertes TLS-Zertifikat](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-cert.html): Läuft das Zertifikat eines Login-, API- oder Patchservers ab oder fehlt ein Zwischenzertifikat, scheitern ab diesem Moment die TLS-Verbindungen aller Clients, die sich neu verbinden.
- [Obergrenze der Login-Warteschlange und zu kurze Reconnect-Karenzzeit](https://jungrok5.github.io/mmo-lag-anatomy/de/c/in-login-queue.html): Strömen nach Release oder Wartung viele Spieler herein, erreicht die Login-Warteschlange ihre Obergrenze und weist neue Wartende ab. Wer schon wartet, verliert bei einem kurzen Verbindungsabbruch seinen Platz und muss sich wieder hinten anstellen.

## Synchronisationsdesign

- [Feedback erst nach der Serverantwort (Request-Response)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-request-response.html): Nach einem Tastendruck gibt es weder Animation noch Ton, bis die Antwort des Servers eintrifft. Der Ping bestimmt direkt die Reaktionszeit.
- [Protokoll mit vielen aufeinanderfolgenden Round Trips (chatty)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-chatty.html): Braucht eine einzige Aktion mehrere Round Trips zum Server nacheinander, vervielfacht sich der Ping um deren Anzahl.
- [Kein Input-Buffering für Skills](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-no-queue.html): Lässt sich der nächste Skill erst auslösen, wenn der Server das Ende des vorigen bestätigt hat, schiebt sich zwischen alle Skills einer Kombo ein Round Trip.
- [Kurze Zeitfenster, die der Ping aufzehrt](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-short-window.html): Ist die Reaktionszeit für Ausweichen, Parieren oder Blocken kurz, zehrt der Ping sie auf, und manche Angriffe lassen sich gar nicht mehr vermeiden.
- [Trefferabfrage ohne Lag-Compensation](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-no-lagcomp.html): Prüft der Server Treffer nur gegen die „aktuelle Position auf dem Server“, weicht die Trefferabfrage von dem ab, was man auf dem eigenen Bildschirm gesehen hat.
- [Übermäßige Lag-Compensation](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-lagcomp-overreach.html): Spult der Server für den Angreifer zu weit zurück, wird der Getroffene noch erwischt, obwohl er schon in Deckung ist.
- [Client-Autorität](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-client-auth.html): Entscheidet jeder Client selbst über seine Ergebnisse, läuft es auf dem eigenen Bildschirm flüssig. Die Ergebnisse weichen aber von denen auf anderen Bildschirmen ab, und das System ist anfällig für Cheats.
- [Warten auf den langsamsten Spieler im Lockstep](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-lockstep.html): Berechnen alle gemeinsam denselben Zug, müssen alle warten, sobald die Eingabe eines Einzelnen zu spät kommt.
- [Fehlvorhersagen beim Rollback-Netcode](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-rollback.html): Die Eingabe des Gegners wird vorhergesagt und vorab angezeigt. Liegt die Vorhersage falsch, wird zurückgespult und neu berechnet. Je höher der Ping, desto weiter wird zurückgespult.
- [Wiedergabe bei Ankunft ohne Zeitstempel](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-no-timestamp.html): Bekommen Server-Events keinen Entstehungszeitpunkt und werden sofort bei Ankunft abgespielt, überträgt sich der Netzwerk-Jitter direkt auf das Timing der Darstellung.
- [Doppeltes Warten auf den Tick](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-double-tick.html): Werden Anfragen bis zum nächsten Tick gesammelt und erst dann verarbeitet, und geht auch das Ergebnis erst im darauffolgenden Tick hinaus, kommt das Tick-Intervall zweimal hinzu.
- [Zu strenge Servervalidierung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-strict-check.html): Prüft der Server Bewegungsgeschwindigkeit, Cooldowns und Reichweite zu streng, lehnt er auch normale Eingaben ab, die durch Jitter gebündelt ankommen.
- [Host-Architektur (Spieler-PC als Server)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-host.html): Übernimmt der PC eines Spielers die Rolle des Servers, bestimmen dessen Leitung und PC-Leistung das Spielgefühl aller.
- [Ablehnung durch den Server nach clientseitigem Feedback](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-optimistic-reject.html): Erkennt der Server einen Treffer oder Skill, den der eigene Bildschirm schon gezeigt hat, nachträglich nicht an, wird ein eindeutig gesehenes Ergebnis rückgängig gemacht.
- [Abweichende Pfadberechnung bei Befehlssynchronisation](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-path-mismatch.html): Werden nur Befehle wie „geh dorthin“ ausgetauscht und beide Seiten berechnen den Pfad selbst, laufen Charaktere oder Monster schon bei kleinen Rechenunterschieden einen anderen Weg und werden dann an die richtige Position zurückgezogen.
- [Niedrige Snapshot-Senderate](https://jungrok5.github.io/mmo-lag-anatomy/de/c/sy-low-send-rate.html): Sendet der Server Positionsupdates (Snapshots) nur wenige Male pro Sekunde, muss der Interpolationspuffer entsprechend lang sein, und andere Charaktere erscheinen weiter in der Vergangenheit.

## Probleme, die nur einige betreffen

- [Laggender Spieler bewegt sich auf fremden Bildschirmen schubweise](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-slow-burst.html): Die Eingaben eines Spielers mit schlechter Leitung kommen unregelmäßig und gebündelt beim Server an. Wendet der Server pro Tick alles an, was gerade eingetroffen ist, sehen andere diesen Charakter stocken und dann mehrere Schritte auf einmal machen.
- [Zeitraffer bei Servern, die sofort bei Ankunft verarbeiten](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-event-server.html): Auf einem Server, der Pakete sofort bei Ankunft verarbeitet und weitermeldet, werden die gebündelt eintreffenden Aktionen eines langsamen Spielers direkt hintereinander ausgeführt.
- [Größe des Eingabepuffers pro Spieler](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-input-buffer.html): Sammelt der Server pro Spieler ein paar Eingaben und entnimmt pro Tick eine, sieht es für andere flüssig aus. Die eigenen Aktionen werden auf dem Server aber entsprechend später bestätigt.
- [Gehäufte False Positives der Validierung bei bestimmten Providern](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-isp-validation.html): Bei Spielern, deren Leitung hohen Jitter hat, kommen Eingaben gebündelt an und bleiben deshalb oft in den Geschwindigkeits- und Cooldown-Prüfungen des Servers hängen.
- [Ein laggendes Gruppenmitglied und Boss-Mechaniken](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-raid-member.html): Bei Raid-Mechaniken, auf die alle im selben Moment reagieren müssen, wird die verspätete Reaktion eines einzelnen langsamen Spielers zum Fehlschlag der ganzen Gruppe.
- [Autorität über Monster bei einem langsamen Client](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-mob-control.html): Manche Spiele übertragen die Berechnung von Monsterbewegungen an den Client eines Spielers in der Nähe, um den Server zu entlasten. Hat dieser Spieler eine schlechte Leitung, bewegt sich das Monster auf allen Bildschirmen seltsam.
- [Aufgeblähte Daten eines bestimmten Charakters](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-heavy-char.html): Bei einem Charakter mit Tausenden Items oder Postnachrichten, ungewöhnlich langen Freundes- oder Blocklisten oder sehr vielen Buffs ist die Datenmenge beim Login, beim Speichern und beim Melden an die Umgebung um ein Vielfaches größer als bei anderen. Unabhängig von der Leitung ist es nur mit diesem Charakter langsam.
- [Unterschiede bei Kanal, Instanz oder Phasing](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-phase.html): Befinden sich zwei Charaktere in verschiedenen Kanälen oder Instanzen oder in unterschiedlichen „Phasen“, in denen je nach Questfortschritt andere NPCs sichtbar sind, sehen sie unterschiedliche Welten.
- [Verworfene Spawn-Meldungen während des Ladens](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-loading-drop.html): Direkt beim Betreten einer Zone schickt der Server Spawn-Meldungen für die NPCs in der Umgebung, aber der Client lädt noch die Karte und verwirft sie.
- [Reihenfolgefehler bei der Sichtbereichsregistrierung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-aoi-race.html): Fällt der Moment, in dem ein Charakter im Sichtbereichsraster registriert wird, mit dem Moment zusammen, in dem ein NPC die Rasterzelle wechselt, kann die Spawn-Meldung für diesen NPC ausbleiben.
- [Verlorener Basis-Snapshot](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-baseline.html): Sendet der Server nur „Änderungen seit dem letzten Mal“, lassen sich spätere Änderungen nicht anwenden, wenn die einmalig gesendete Gesamtinformation (Basis) verloren geht.
- [Verlorene Despawn-Meldung (Geisterobjekt)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-ghost.html): Geht umgekehrt die Meldung „verschwunden“ verloren, bleiben bereits tote oder gegangene NPCs und Spieler nur auf dem eigenen Bildschirm stehen.
- [Verlust gebündelter Spawn-Daten direkt nach dem Betreten](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-spawn-burst.html): Beim Betreten einer Zone schickt der Server die Spawn-Daten von Dutzenden bis Hunderten Objekten in der Umgebung auf einmal. Gehen sie über einen Unreliable-Kanal oder läuft der Empfangspuffer über, während der Client beim Laden den Socket nicht liest, verschwindet ein Teil davon und kommt nicht wieder.
- [Verwechslung durch wiederverwendete Objekt-IDs](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-id-reuse.html): Verwendet der Server beim Respawn eines getöteten NPCs dieselbe Objekt-ID erneut, hält ein Client, der zwischendurch die Despawn-Meldung verpasst hat, den neuen NPC fälschlich für den alten.
- [Kollision fester UDP-Ports](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-port-collision.html): Ist der Client so gebaut, dass er einen festen lokalen Port verwendet, kann ein zweiter Client auf demselben PC den Port nicht nutzen oder teilt sich die Pakete mit dem ersten.
- [Fehlerhafte Session-Zuordnung nach IP oder Gerät](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-session-key.html): Unterscheiden der Server oder ein Zwischenserver Verbindungen anhand von IP oder Geräte-ID, werden zwei Clients auf demselben PC (gleiche öffentliche IP) als ein Spieler erkannt.
- [Multi-Client-Beschränkung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-multiclient.html): Beschränken ein Sicherheitsmodul oder eine Serverrichtlinie mehrere Clients auf einem PC, wird der Start oder Login des zweiten Clients blockiert, oder der zuerst gestartete verliert die Verbindung. Manche Spiele sperren nur Funktionen des zusätzlichen Clients.
- [Drosselung von Hintergrundfenstern](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-background.html): Bei einem Client im Hintergrundfenster reduzieren Spiel, Engine und OS Frames und Verarbeitung. Empfangene Pakete werden nicht rechtzeitig verarbeitet, stauen sich oder laufen über.
- [Zugriffskonflikte bei Cache- und Asset-Dateien](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-asset-lock.html): Schreiben zwei Clients gleichzeitig in denselben Cache-Ordner oder sperren Dateien, kann einer von ihnen NPC-Modelle oder Texturen nicht laden.
- [Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-vram.html): Teilen sich zwei Clients den Grafikspeicher, ist kein Platz für neu benötigte Modelle und Texturen, und manches wird nicht gezeichnet.
- [Unterschiedliche Anzeigeoptionen](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-display-option.html): Unterscheiden sich Optionen wie die Begrenzung angezeigter Charaktere, ausgeblendete NPC-Namensschilder oder -Modelle oder ein Low-Spec-Modus zwischen zwei Clients, sehen sie Unterschiedliches.
- [Abweichende Client-Version oder Spieldaten](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-version.html): Ist der zweite Client eine andere Installation oder nicht vollständig gepatcht, kennt er neue NPC-IDs vom Server nicht und ignoriert sie stillschweigend.
- [Sendebudget und Priorität pro Verbindung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-priority.html): Begrenzt der Server die Sendemenge pro Verbindung und sendet Nahes zuerst, bekommen Verbindungen mit niedrigem Limit entfernte NPCs spät oder gar nicht.
- [Zurückgehaltene Objekte durch falsch geschätzte Serverzeit](https://jungrok5.github.io/mmo-lag-anatomy/de/c/pt-clock-hold.html): Liegt die vom Client geschätzte Serverzeit falsch, hält er gerade eingetroffene Objektdaten als „noch in der Zukunft“ zurück oder verwirft sie als „zu alt“.

## Grundursachen von TCP-Retransmissions

- [Verlust auf der Funkstrecke](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-wireless.html): WLAN und Mobilfunknetz wiederholen eine Übertragung auf der Funkstrecke einige Male und verwerfen das Paket, wenn es dann immer noch nicht klappt. Verworfene Pakete sendet TCP erst deutlich später erneut.
- [Warteschlangenüberlauf am Engpass (Verlust durch Überlast)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-queue-drop.html): Ist die Warteschlange an der engsten Stelle voll, etwa am Router, am Übergabepunkt zwischen Providern oder an der Leitung des Rechenzentrums, werden neu ankommende Pakete verworfen.
- [Überlauf flacher Puffer durch Sende-Bursts](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-burst.html): Sendet der Server in jedem Tick die Updates für Tausende Spieler im selben Augenblick, laufen kleine Switch-Puffer oder kurzfristige Limits in der Cloud in weniger als 1 ms über, und ein Teil der Pakete wird verworfen.
- [Policer verwirft Überschuss](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-policer.html): Provider-Tarife, Limits von Cloud-Instanzen und DDoS-Schutzgeräte verwerfen Pakete oberhalb einer festgelegten Rate teils sofort, ohne sie in eine Warteschlange zu stellen.
- [Physische Fehler (defekte Kabel, optische Module, Stecker)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-physical.html): Beschädigte Kabel, verschmutzte optische Stecker und gealterte optische Module verursachen Bitfehler, und beschädigte Pakete verwerfen die Geräte stillschweigend.
- [Duplex-Mismatch](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-duplex.html): Nutzt eine Seite Autonegotiation und hat die andere Geschwindigkeit und Duplex fest eingestellt, arbeitet eine Seite im Halbduplex und verliert unter Last durch Kollisionen Pakete.
- [Verworfene Pakete auf dem empfangenden Server-Host](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-host-drop.html): Die Pakete erreichen den Server, werden aber verworfen, weil der Ringpuffer der NIC (ein Puffer, der ankommende Pakete kurz zwischenspeichert) überläuft oder der CPU-Kern, auf dem der Kernel den Empfang verarbeitet, voll ausgelastet ist.
- [Verworfene Pakete in Firewall und Connection Tracking](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-stateful-fw.html): Firewalls und das Linux-Connection-Tracking (conntrack, eine Funktion, die durchlaufende Verbindungen in einer Tabelle vermerkt) verwerfen Pakete, wenn die Tabelle voll ist oder der Verbindungszustand nicht zu passen scheint.
- [Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-appliance-pps.html): Firewalls, Intrusion-Prevention-Systeme (IPS) und DDoS-Schutzgeräte prüfen jedes durchlaufende Paket einzeln. Sobald ihre Prüfkapazität überschritten ist, verwerfen sie die Pakete, die sie nicht mehr verarbeiten können.
- [MTU-Blackhole (nur große Pakete gehen wiederholt verloren)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-mtu.html): Ist die zulässige Paketgröße auf einem Abschnitt der Strecke kleiner geworden und wird die Meldung „Paket zu groß“ (ICMP) blockiert, verschwinden große Pakete immer wieder, egal wie oft sie erneut gesendet werden.
- [Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-mapping.html): Löscht ein Zwischengerät das Mapping einer Idle-Verbindung (den Eintrag, wohin diese Verbindung weitergeleitet wird), kommt das nächste gesendete Paket nicht mehr an. Entweder folgen Retransmissions, bis die Verbindung abbricht, oder das Gerät schickt eine Verbindungsablehnung (RST) zurück, und die Verbindung bricht sofort ab.
- [Routenwechsel oder defekter ECMP-Pfad](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-path.html): Pakete verschwinden in den Sekunden, in denen sich die Internet-Route ändert, oder auf Verbindungen, die unter mehreren ECMP-Pfaden einem defekten Pfad zugeordnet sind.
- [Unnötige Retransmission durch Latenzsprünge](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-spurious-delay.html): Das Paket ist gar nicht verschwunden, es kommt nur kurz sehr spät an. Dauert diese Verzögerung länger als das RTO, wertet der Sender das als Verlust und sendet erneut.
- [Unnötiger Fast Retransmit durch vertauschte Reihenfolge](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-reorder.html): Kommt die Paketreihenfolge über mehrere Pfade oder gebündelte Links durcheinander, meldet der Empfänger per doppelter ACKs „Paket fehlt“, und der Sender schickt intakte Pakete erneut.
- [Verspätete oder verlorene ACKs (ausgelasteter Upload)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-ack-path.html): Die Daten sind angekommen, aber das ACK („erhalten“) verspätet sich in der vollen Upload-Warteschlange oder geht verloren. Dann wertet der Sender das als Verlust und sendet erneut.
- [RTO-Einstellung passt nicht zur Umgebung](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-rto-setting.html): Ist das RTO-Minimum zu weit gesenkt, kommt es schon bei leichter Verspätung zu unnötigen Retransmissions. Der Standardwert (200 ms) ist für Spiele zu lang, jeder einzelne Verlust führt zu einem langen Stillstand.
- [Langsame Wiederherstellung bei Thin Streams](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-thin.html): Sendet eine Verbindung wie bei Spielen nur vereinzelt kleine Pakete, läuft das RTO ab, bevor „3 nachfolgende Pakete“ beisammen sind. Beim selben Verlust steht sie deutlich länger still als eine große Übertragung.
- [Zwischengeräte entfernen TCP-Optionen](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-sack-stripped.html): Entfernen oder verändern manche Firewalls und WAN-Beschleuniger TCP-Optionen, wird bei mehreren Verlusten nur ein Paket pro Round Trip wiederhergestellt, oder das Window (die Menge, die auf einmal gesendet werden darf) schrumpft, und alles wird langsamer.
- [Zero Window (Stillstand, der wie eine Retransmission aussieht)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-zero-window.html): Liest das empfangende Programm den Socket nicht rechtzeitig und läuft der Puffer voll, stellt der Sender die Übertragung ein und schickt nur noch Zero-Window-Probes. Die Leitung ist in Ordnung.
- [Retransmission der Verbindungsanfrage (SYN)](https://jungrok5.github.io/mmo-lag-anatomy/de/c/rt-syn.html): Geht die Verbindungsanfrage durch einen Überlauf der Verbindungswarteschlange (Backlog) oder eine Firewall-Sperre verloren, sendet das Client-OS sie ab 1 s in wachsenden Abständen erneut.

## Diagnose und Fallbeispiele

- [Diagnose anhand von Messdaten](https://jungrok5.github.io/mmo-lag-anatomy/de/#judge): Eingrenzung nach Betroffenenkreis → Zeitpunkt → Schicht, Signaltabelle, 13 Graphmuster, Zahlen richtig lesen (Durchschnitt und p99)
- [Playbooks für typische Situationen](https://jungrok5.github.io/mmo-lag-anatomy/de/text.html#playbooks): Lag nach einem Patch, Erweiterung um neue Länder und Regionen
- [Reale Störungsfälle](https://jungrok5.github.io/mmo-lag-anatomy/de/text.html#cases): Von Entwicklern und Betreibern veröffentlichte Postmortems mit zugehörigen Ursachen

## Weitere Sprachen

- [한국어 (Korean)](https://jungrok5.github.io/mmo-lag-anatomy/llms.txt)
- [English](https://jungrok5.github.io/mmo-lag-anatomy/en/llms.txt)
- [日本語 (Japanese)](https://jungrok5.github.io/mmo-lag-anatomy/ja/llms.txt)
- [简体中文 (Chinese (Simplified))](https://jungrok5.github.io/mmo-lag-anatomy/zh-cn/llms.txt)
- [繁體中文 (Chinese (Traditional, Taiwan))](https://jungrok5.github.io/mmo-lag-anatomy/zh-tw/llms.txt)
- [ไทย (Thai)](https://jungrok5.github.io/mmo-lag-anatomy/th/llms.txt)
- [Tiếng Việt (Vietnamese)](https://jungrok5.github.io/mmo-lag-anatomy/vi/llms.txt)
- [Русский (Russian)](https://jungrok5.github.io/mmo-lag-anatomy/ru/llms.txt)
- [Português (Brasil) (Portuguese (Brazil))](https://jungrok5.github.io/mmo-lag-anatomy/pt-br/llms.txt)
- [Español (Spanish)](https://jungrok5.github.io/mmo-lag-anatomy/es/llms.txt)
- [Bahasa Indonesia (Indonesian)](https://jungrok5.github.io/mmo-lag-anatomy/id/llms.txt)

## Optional

- [GitHub-Repository](https://github.com/jungrok5/mmo-lag-anatomy): Quellcode, Datenformat, Mitwirken
- [Autor: Jeongrok Oh](https://jungrok5.github.io/resume/en/): Lebenslauf