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.
Warum „TCP-Normalisierung“ in der Firewall oder alte WAN-Beschleuniger entfernen die Optionen SACK, Timestamps und Window Scaling → Folge Bei mehreren verlorenen Paketen wird pro Round Trip nur eines wiederhergestellt, das Window ist auf 64 KB begrenzt → Auf dem Bildschirm Jeder Verlust führt zu einem deutlich längeren Freeze (ohne SACK funktioniert auch RACK-TLP nicht), danach Zeitraffer. Auch große Übertragungen wie Patches sind langsam
Netzwerk: TCP-Normalisierung im betroffenen Gerät abschalten, auch die Sequenznummer-Randomisierung der Firewall prüfen, die Optionen im SYN per Paketmitschnitt an beiden Enden vergleichen. Server/OS: in ss -ti prüfen, ob sich Verbindungen ohne sack- und wscale-Angabe auf bestimmten Routen häufen (ts lassen Windows-PCs je nach Einstellung weg, fehlt nur ts, kann das normal sein), prüfen, ob net.ipv4.tcp_sack auf dem Server 1 ist.
Im Graphen
Von Anfang an dauerhaft hoch · Wiederherstellungen ohne SACK (TcpExtTCPRenoRecovery)
Wo nachsehen
In ss -ti pro Verbindung prüfen, ob sack und wscale angezeigt werden, in nstat das Verhältnis von TcpExtTCPRenoRecovery (Wiederherstellung ohne SACK) zu TcpExtTCPSackRecovery sowie TcpExtTCPSACKDiscard (wegen Widersprüchen verworfene SACK-Blöcke) ansehen. Auf verdächtigen Routen den SYN an beiden Enden mitschneiden und die Optionen vergleichen (in Wireshark z. B. tcp.options.sack_perm)
Spricht dafür
Nur Verbindungen über eine bestimmte Route oder ein bestimmtes Gerät haben kein sack und wscale, hoher Anteil von TcpExtTCPRenoRecovery. Die SACK-Permitted-Option aus dem SYN des Senders fehlt im SYN, der beim Empfänger ankommt. Ist die Sequenznummer-Randomisierung die Ursache, sind die Optionen vorhanden, aber TcpExtTCPSACKDiscard steigt
Spricht dagegen
sack fehlt bei allen Verbindungen: zuerst net.ipv4.tcp_sack auf dem Server prüfen. Optionen intakt und TcpExtTCPSACKDiscard unverändert: Die langsame Wiederherstellung hat einen anderen Grund („Langsame Wiederherstellung bei Thin Streams“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch wenn die Optionen erhalten bleiben, kann SACK kaputtgehen. Ändert die Sequenznummer-Randomisierung (sequence randomization) einer Firewall nur die Sequenznummern im Header und lässt die Nummern im SACK unverändert, verwirft der Sender die widersprüchlichen SACKs. Dasselbe Ergebnis hat ein tcp_sack=0, das wegen der SACK-Sicherheitslücke von 2019 auf dem Server gesetzt und dann vergessen wurde.