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.
Warum Bufferbloat, WLAN-Energiesparen, Zustandswechsel im Mobilfunk oder pausierte virtuelle Maschine: kurzzeitig mehrere hundert ms Latenz → Folge Das RTO läuft zuerst ab, es folgt eine Retransmission, kurz darauf kommt auch das Original an (der Empfänger erhält es doppelt) → Auf dem Bildschirm Freeze und Zeitraffer kommen vom Latenzsprung selbst. Die unnötige Retransmission verlängert den Freeze kaum, treibt aber die Retransmission-Metriken nach oben und wird für Verlust gehalten
Clients ab Android 10 fordern im Spiel den WLAN-Modus mit niedriger Latenz an (WLAN-Lock WIFI_MODE_FULL_LOW_LATENCY, gilt nur bei eingeschaltetem Bildschirm und Spiel im Vordergrund), um Latenzsprünge durch Energiesparen zu verringern.
Aufgaben Infrastrukturteam
Burstable-Instanzen meiden, RTO-Minimum nicht zu weit senken, F-RTO und Timestamps beibehalten (tcp_frto, tcp_timestamps), Retransmission-Metriken zusammen mit TCPSpuriousRTOs und TCPDSACKRecv in nstat betrachten, damit sie nicht fälschlich als Verlust gelten.
Aufgaben Extern
Um die Latenzsprünge selbst zu verringern, Spieler auf SQM am Router und das Abschalten des WLAN-Energiesparmodus hinweisen.
Größenordnungen
Linux erkennt unnötige RTOs per F-RTO und nimmt die Drosselung der Senderate teils wieder zurück. Zu prüfen sind TCPSpuriousRTOs (als unnötig eingestufte RTOs) und TCPDSACKRecv (wie oft der Empfänger „schon erhalten“ gemeldet hat) in nstat.
Im Graphen
Vereinzelte Spitzen ohne Muster · RTT (Ping), unnötige RTOs
Wo nachsehen
nstat im Minutentakt ausführen und den Zuwachs von TcpExtTCPTimeouts (abgelaufene RTOs), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv und TcpExtTCPLostRetransmit gemeinsam betrachten. Liegt ein Paketmitschnitt vor, den Wireshark-Filter tcp.analysis.spurious_retransmission nutzen
Spricht dafür
Steigen die RTOs, steigen auch TcpExtTCPSpuriousRTOs oder TcpExtTCPDSACKRecv, gleichzeitig schießt die RTT auf mehrere hundert ms hoch. Im Mitschnitt auf Empfängerseite sind Original und Retransmission beide angekommen
Spricht dagegen
TcpExtTCPSpuriousRTOs und DSACK unverändert, aber TcpExtTCPLostRetransmit steigt (auch die Retransmission geht verloren): echter Verlust. RTT ohne Spitzen, aber dauerhaft viele DSACKs: „Unnötiger Fast Retransmit durch vertauschte Reihenfolge“
WifiManagerAndroid (Google) WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): WLAN-Lock mit niedriger Latenz, der nur greift, wenn das Gerät mit einem AP verbunden, der Bildschirm eingeschaltet und die App im Vordergrund ist
net/ipv4/proc.cLinux kernel In nstat angezeigte Zählernamen TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv und TCPLostRetransmit
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts steigt, wenn der Retransmission-Timer (RTO) abläuft