Netzwerkdurchsatz und Retransmits unter Linux: ss -ti, nstat und iperf3

Ziel

Feststellen, ob ein langsamer Netzwerkpfad tatsächlich Pakete verliert und erneut sendet oder ob er lediglich weniger Verkehr trägt als erwartet. Dafür die bereits auf dem Host vorhandenen Zähler nutzen, bevor zu einem Packet Capture gegriffen wird.

Voraussetzungen

iproute2 für ss und nstat (normalerweise vorinstalliert); iperf3 auf zwei Hosts für einen aktiven Durchsatztest; Bewusstsein, dass ein aktiver Test auf einer realen Verbindung echte Bandbreite verbraucht.

Schritte

1. Die Sicht einer einzelnen Verbindung prüfen: ss -ti dst <ip> (mit sport/dport weiter eingrenzen). Laut Manual von ss zeigt -i/--info interne TCP-Informationen an. Die Ausgabe enthält die geglättete Round-Trip-Time (rtt:), das Congestion Window (cwnd:) und, sobald welche aufgetreten sind, retrans:<in flight>/<total> für genau diesen Socket.
2. Die hostweiten Zähler prüfen: nstat. Laut Manual ist nstat ein Werkzeug zur Überwachung der SNMP-Zähler des Kernels und der Statistiken der Netzwerkschnittstellen. Standardmässig gibt es die Zuwächse seit dem vorherigen Aufruf aus (-a gibt die absoluten Werte seit dem Booten aus, -z schliesst Zähler mit Wert null ein). Gesucht sind Retransmission-Zähler, die zwischen zwei Aufrufen wachsen.
3. Vor jeder Massnahme verstehen, was diese Zähler bedeuten: Die Netzwerkdokumentation des Kernels definiert erweiterte TCP-Statistiken wie TcpExtTCPRetransFail (ein Retransmission-Versuch, der in einer tieferen Schicht fehlgeschlagen ist) unter den auf diesem Weg bereitgestellten Zählern, neben der einfacheren, per SNMP definierten Anzahl erneut gesendeter Segmente, TcpRetransSegs.
4. Vor dem Nachstellen einer langsamen Übertragung eine Baseline setzen: nstat -n aktualisiert die gespeicherte Historie, ohne etwas auszugeben, sodass das nächste nstat nur die Änderung seither meldet.
5. Sind die Retransmits niedrig, der Durchsatz aber weiterhin enttäuschend, den erreichbaren Durchsatz direkt messen: iperf3 -s -1 auf dem einen Host (-1 bedient genau einen Test und beendet sich danach; TCP-Port 5201 muss erreichbar sein), iperf3 -c <server> -t 10 auf dem anderen, mit -R für die Gegenrichtung. Laut iperf3-Dokumentation dient das Werkzeug der aktiven Messung der maximal erreichbaren Bandbreite in IP-Netzwerken. Die Dauer mit -t begrenzen und den Test auf einer produktiven Verbindung in einem Wartungsfenster ausführen, da er im standardmässigen TCP-Modus während dieser Zeit so viel Bandbreite wie möglich nutzt.
6. Wurde der Server ohne -1 gestartet, ihn nach Abschluss des Tests beenden; andernfalls bleibt er weiter im Listen-Zustand.

Erwartetes Ergebnis

Entweder ein Retransmission-Zähler einer bestimmten Verbindung oder des ganzen Hosts, der während der langsamen Phase wächst und auf Verluste auf dem Pfad hinweist, oder ein sauberer Durchsatztest, der den Erwartungen entspricht und stattdessen auf die Anwendung oder ein Ratenlimit hindeutet.

Grenzen und Prüfbasis

ss -ti zeigt nur aktuell offene Sockets; eine geschlossene Verbindung erscheint in der Ausgabe nicht mehr, ihr Beitrag steckt aber weiterhin in den kumulativen Zählern von nstat. iperf3 misst den Pfad zwischen den beiden Testhosts, der vom Pfad eines realen Clients abweichen kann. Keines dieser Werkzeuge ordnet Retransmits einer Ursache zu (Überlast, instabile Verbindung, Middlebox); dafür ist weiterhin ein Packet Capture nötig.