Fehlerbehebung bei langsamer Leistung: Effektive Nutzung von 'netstat' und 'ss'

Wenn ein Linux-Dienst sich langsam anfühlt, ist die Socket-Tabelle einer der schnellsten Orte, um zu unterscheiden, ob "die Anwendung überlastet ist" oder "der Netzwerkpfad chaotisch ist". Ein Webserver, der keine neuen Verbindungen annehmen kann, ein Worker, der beim Öffnen von Datenbanksitzungen hängt, und ein Host mit einem Haufen halboffener TCP-Handshakes – all das erscheint der wartenden Person am anderen Ende als vage Langsamkeit.

netstat und ss helfen Ihnen, eine engere Frage zu beantworten: Welche Netzwerk-Sockets existieren auf diesem Rechner gerade, in welchem Zustand sind sie und welcher Prozess besitzt sie? netstat ist auf älteren Systemen und in alten Runbooks immer noch nützlich. ss ist das Tool, das ich auf modernen Linux-Systemen zuerst verwende, weil es auf stark ausgelasteten Hosts schneller ist und bessere integrierte Filterfunktionen hat.

Warum Netzwerk-Sockets überwachen?

Netzwerklatenz und Trägheit sind häufig eher auf Verbindungsprobleme als auf CPU- oder Speichererschöpfung zurückzuführen. Die Überwachung von Sockets hilft Administratoren, kritische Fragen zu beantworten wie:

• Welche Ports lauschen aktiv auf Verbindungen?
• Gibt es zu viele Verbindungen, die in den Zuständen SYN_RECV oder TIME_WAIT feststecken?
• Welcher Prozess (PID) verwendet einen bestimmten Port?
• Gibt es unerwartete ausgehende Verbindungen?

Durch die Untersuchung von Socket-Statistiken können Sie Netzwerkkonfigurationsprobleme schnell ausschließen oder Ressourcenkonflikte im Zusammenhang mit der Verbindungsverwaltung identifizieren.

Das Legacy-Tool: netstat

netstat ist seit Jahrzehnten das Standard-Dienstprogramm zur Anzeige von Netzwerkverbindungen, Routing-Tabellen, Schnittstellenstatistiken und Masquerade-Verbindungen. Obwohl es auf vielen modernen Systemen zugunsten von ss als veraltet gilt, ist es immer noch weit verbreitet und oft älteren Administratoren vertraut.

Häufige netstat-Beispiele

Die gebräuchlichsten Flags, die mit netstat verwendet werden, bieten einen umfassenden Überblick:

Flag	Beschreibung
-a	Zeigt alle Sockets an (lauschende und nicht lauschende)
-n	Zeigt numerische Adressen an, anstatt zu versuchen, Hostnamen und Dienstnamen aufzulösen (beschleunigt die Ausgabe)
-t	Zeigt TCP-Verbindungen an
-u	Zeigt UDP-Verbindungen an
-l	Zeigt nur lauschende Sockets an
-p	Zeigt die PID/den Programmnamen an, der dem Socket zugeordnet ist (erfordert Root-Rechte)

Beispiel: Alle aktiven TCP-Verbindungen numerisch anzeigen

sudo netstat -ant

Beispiel: Herausfinden, was auf Port 80 (HTTP) lauscht

sudo netstat -tulpen | grep ':80'

Verbindungszustände verstehen (netstat)

Die Ausgabe von netstat enthält oft eine Spalte State. Wichtige Zustände, auf die Sie achten sollten, sind:

• LISTEN: Wartet auf eingehende Verbindungen.
• ESTABLISHED: Eine aktive, offene Verbindung.
• TIME_WAIT: Ein Socket wartet kurz nach dem Schließen, um sicherzustellen, dass verzögerte Pakete verarbeitet werden.
• SYN_RECV: Wartet auf die letzte Bestätigung eines Drei-Wege-Handshakes (kann bei übermäßigem Auftreten auf einen SYN-Flood-Angriff hindeuten).

Warnung zu netstat: netstat verlässt sich oft auf das Parsen von /proc/net/*-Dateien, was langsam sein kann, insbesondere auf Systemen mit einer sehr hohen Anzahl aktiver Verbindungen (Tausende). Dies ist der Hauptgrund, warum ss entwickelt wurde.

Der moderne Ersatz: ss (Socket-Statistiken)

Das Dienstprogramm ss ist deutlich schneller als netstat, da es Socket-Informationen direkt aus dem Kernelbereich mithilfe von Netlink-Sockets abruft und langsamere Dateisystemzugriffe umgeht.

Häufige ss-Beispiele

Die Flag-Struktur für ss ist der von netstat sehr ähnlich, was einen einfachen Übergang fördert:

Flag	Beschreibung
-a	Zeigt alle Sockets an
-n	Zeigt numerische Adressen an
-t	Zeigt TCP-Sockets an
-u	Zeigt UDP-Sockets an
-l	Zeigt lauschende Sockets an
-p	Zeigt Prozessinformationen an (PID/Programm)

Beispiel: Alle aktiven TCP-Verbindungen numerisch anzeigen (Äquivalent zu netstat -ant)

ss -ant

Beispiel: Herausfinden, was auf Port 443 (HTTPS) lauscht

sudo ss -tulpen | grep ':443'

Erweiterte Filterung mit ss

Einer der größten Vorteile von ss ist die Möglichkeit, direkte Filterungen nach Verbindungszuständen durchzuführen, was viel effizienter ist, als die Ausgabe von netstat an grep weiterzuleiten.

Filtern nach Verbindungszustand

Sie können die Option state direkt innerhalb des ss-Befehls verwenden. Dies ist äußerst nützlich, um Verbindungsaufbauten zu diagnostizieren.

Alle Sockets finden, die sich derzeit im Zustand TIME-WAIT befinden:

ss -tan state time-wait

Alle Sockets im Zustand SYN-SENT finden (Client-Seite wartet auf Serverantwort):

ss -tan state syn-sent

Filtern nach Port oder Adresse

Das Filtern nach Ziel- oder Quelladresse/-port ist unkompliziert:

Etablierte Verbindungen anzeigen, die für Port 22 (SSH) bestimmt sind:

ss -tn state established '( dport = :22 or sport = :22 )'

Verbindungen anzeigen, die sich auf eine bestimmte lokale IP-Adresse beziehen:

ss -ant '( daddr = 192.168.1.100 or saddr = 192.168.1.100 )'

Leistungsanalyse: Vergleich netstat vs. ss

Bei der Fehlerbehebung hängt die Wahl zwischen den Tools oft von Geschwindigkeit und Detailtiefe ab.

Merkmal	netstat	ss
Geschwindigkeit	Langsamer (liest Dateien)	Viel schneller (verwendet Netlink-Sockets)
Syntax	Ausgereift, gut dokumentiert	Ähnliche Flags, neuere spezifische Optionen
Filterung	Erfordert Weiterleitung an grep	Native Unterstützung für Zustands- und Adressfilterung
Informationstiefe	Gut für Grundlagen	Mehr Details zu Socket-Puffergrößen (TCP-Info)
Verfügbarkeit	Nahezu universell	Standard auf modernen Linux-Distributionen

Diagnose eines langsamen Verbindungsaufbaus

Wenn Clients über langsame Verbindungen berichten, überprüfen Sie, ob Sockets auf Handshakes warten. Die Verwendung von ss ist der schnellste Weg, dies festzustellen:

1. Überprüfen Sie auf hohe SYN-RECV-Anzahlen: Dies deutet darauf hin, dass der Server Verbindungsanfragen erhält, den Handshake aber nicht abschließt, oft aufgrund von Ressourcenerschöpfung oder hohem Verkehrsaufkommen.

   ss -s | grep syn-rec
   

2. Überprüfen Sie auf hohe SYN-SENT-Anzahlen: Wenn der Server selbst viele Verbindungen initiiert (z. B. als Client zu Datenbanken oder anderen APIs), zeigt dies, dass er auf Antworten wartet.

   ss -s | grep syn-sent
   

Wenn Sie in einer der beiden Kategorien anhaltend hohe Zahlen sehen, behandeln Sie diese als Hinweis, nicht als endgültiges Urteil. SYN-SENT kann bedeuten, dass ein Remote-Host ausgefallen ist, eine Route falsch ist, eine Firewall Datenverkehr stillschweigend verwirft oder der Remote-Dienst überlastet ist. SYN-RECV kann bedeuten, dass der Server unter Last steht, Pakete verloren gehen oder Clients Verbindungen öffnen und nicht abschließen.

Ein praktischer Triage-Ablauf

Wenn jemand sagt "die App ist langsam", beginne ich normalerweise mit einem kurzen, wiederholbaren Durchlauf:

sudo ss -tulpen
ss -s
sudo ss -tan state established '( sport = :443 or dport = :443 )' | head
sudo ss -tan state syn-recv
sudo ss -tan state time-wait | head

Der erste Befehl bestätigt, dass der erwartete Dienst tatsächlich lauscht, und zeigt den besitzenden Prozess. Die Zusammenfassung zeigt, ob der Host eine überraschende Anzahl von TCP-Sockets hat. Der gefilterte established-Befehl beweist, ob tatsächlicher Client-Verkehr an den Port angeschlossen ist. Die syn-recv- und time-wait-Prüfungen zeigen, ob der Verbindungsaufbau oder der Verbindungswechsel Aufmerksamkeit verdient.

Stellen Sie sich zum Beispiel einen Nginx-Reverse-Proxy vor, bei dem Benutzer sich beschweren, dass neue Anfragen einige Sekunden hängen. sudo ss -tulpen | grep ':443' bestätigt, dass Nginx den HTTPS-Listener besitzt. ss -s zeigt eine große TCP-Gesamtzahl, und sudo ss -tan state syn-recv '( sport = :443 )' gibt immer wieder Zeilen aus denselben Quellbereichen zurück. Das beweist nicht automatisch einen Angriff, aber es sagt Ihnen, dass Sie sich die Load-Balancer-Health-Checks, Upstream-Paketverluste, den SYN-Backlog-Druck, Firewall-Protokolle und möglicherweise Ratenbegrenzungen ansehen sollten.

Stellen Sie sich nun denselben Proxy mit sehr wenigen SYN_RECV-Sockets, aber vielen etablierten Verbindungen zu einer Upstream-Datenbank auf Port 5432 vor. Das lenkt den Fokus weg vom öffentlichen HTTPS und hin zum Datenbankpfad:

sudo ss -tanp '( dport = :5432 or sport = :5432 )'

Wenn der besitzende Prozess Ihre Anwendung ist und die Anzahl ständig steigt, ist die nächste nützliche Frage, ob die Anwendung Verbindungen leckt, auf langsame Abfragen wartet oder Verbindungen nicht an einen Pool zurückgibt. ss beantwortet diese Frage auf Anwendungsebene nicht, bringt Sie aber in den richtigen Raum.

TIME_WAIT lesen, ohne in Panik zu geraten

TIME_WAIT ist ein normaler TCP-Zustand, kein Fehler an sich. Ein Server, der viele kurzlebige Verbindungen verarbeitet, wird natürlich TIME_WAIT-Sockets aufweisen. Sie existieren, damit verzögerte Pakete einer alten Verbindung nicht mit einer neuen verwechselt werden.

Die nützliche Frage ist, ob TIME_WAIT zur Arbeitslast passt. Ein Batch-Job, der für jede kleine Anfrage eine frische HTTP-Verbindung öffnet, kann eine Welle von TIME_WAIT erzeugen. Ein Dienst, der Keep-Alive verwenden sollte, es aber nicht tut, kann dasselbe tun. Bevor Sie Kernel-Einstellungen optimieren, prüfen Sie, ob die Anwendung Verbindungen wiederverwenden, HTTP-Keep-Alive aktivieren oder einen ordentlichen Client-Pool verwenden kann.

Seien Sie vorsichtig mit alten Ratschlägen, die blindes Ändern von TCP-Sysctls zur "Behebung" von TIME_WAIT empfehlen. Einige Einstellungen sind kernelversionsabhängig, einige wurden im Laufe der Zeit entfernt oder davon abgeraten, und einige verursachen subtile Fehler hinter NAT oder Load-Balancern. Beginnen Sie damit zu verstehen, warum die Verbindungen kurzlebig sind.

Überprüfung von lokalem vs. remote Druck

Ein Detail, das Zeit spart, ist die Frage, ob der lokale Host hauptsächlich Verbindungen akzeptiert oder hauptsächlich herstellt. Ein Frontend-Proxy hat normalerweise viele Verbindungen, bei denen der lokale Port 80 oder 443 ist. Ein Anwendungsserver, der mit Datenbanken und APIs spricht, kann viele Verbindungen haben, bei denen der Remote-Port 5432, 3306, 6379 oder 443 ist.

Für lokale Listener und eingehenden Verkehr:

sudo ss -tan '( sport = :443 )'

Für ausgehenden Verkehr zu einer Abhängigkeit:

sudo ss -tan '( dport = :6379 )'

Diese Unterscheidung ändert das nächste Gespräch. Wenn eingehendes HTTPS sich stapelt, müssen Sie möglicherweise den Load-Balancer, die TLS-Terminierung, Worker-Limits oder das Client-Verhalten überprüfen. Wenn ausgehende Redis-Verbindungen sich stapeln, erstellt die lokale Anwendung möglicherweise zu viele Client-Verbindungen, wartet auf Redis oder wiederholt zu aggressiv.

Wenn Sie eine schnelle Anzahl benötigen, ohne Hunderte von Zeilen zu lesen, kombinieren Sie ss mit einfachen Shell-Tools:

sudo ss -tan state established '( dport = :443 )' | wc -l
sudo ss -tan state established '( dport = :5432 )' | wc -l

Die Anzahl enthält die Kopfzeile, ist also keine perfekte Metrik. Für die Triage ist sie dennoch nützlich. Wenn sich die Anzahl während eines Vorfalls jede Minute verdoppelt, haben Sie ein stärkeres Signal als eine einzelne Momentaufnahme.

Container und Netzwerk-Namespaces

Seien Sie auf containerisierten Hosts vorsichtig, wo Sie den Befehl ausführen. Die Ausführung von ss auf dem Host zeigt Host-Netzwerk-Namespaces und veröffentlichte Ports, aber möglicherweise nicht dieselbe Ansicht, die der Prozess innerhalb seines Containers sieht. Wenn ein Dienst in einem Container läuft, vergleichen Sie beide Ansichten:

sudo ss -tulpen
docker exec <container> ss -tulpen

Verwenden Sie für Kubernetes die Knotenansicht für Listener auf Host-Ebene und kubectl exec für den Netzwerk-Namespace des Pods. Ein Port kann innerhalb des Containers geöffnet sein, während der Host, der Dienst, das Ingress oder die Netzwerkrichtlinie dennoch verhindern, dass Verkehr ihn erreicht. ss ist ein Werkzeug für lokale Wahrheiten, kein End-to-End-Konnektivitätstest.

Best Practices für die Netzwerk-Fehlerbehebung

1. Verwenden Sie immer -n: Verwenden Sie bei der Fehlerbehebung oder Skripterstellung das numerische Flag (-n), um Verzögerungen durch DNS-Auflösung zu vermeiden, die die Diagnose verlangsamen können.
2. Priorisieren Sie ss: Machen Sie ss zu Ihrem Standardwerkzeug. Reservieren Sie netstat nur für Legacy-Systeme, auf denen ss nicht verfügbar ist.
3. Als Root für PID ausführen: Um zu sehen, welches Programm einen Port verwendet, benötigen Sie im Allgemeinen sudo- oder Root-Rechte, wenn Sie das Flag -p mit beiden Dienstprogrammen verwenden.
4. Schnittstellenstatistiken prüfen: Vergessen Sie nicht die Schnittstellenzähler. Verwenden Sie ip -s link show <schnittstellenname>, um nach verworfenen Paketen oder Fehlern zu suchen, die auf ein Problem der physikalischen Schicht und nicht auf ein Socket-Problem hindeuten könnten.
5. Momentaufnahmen vergleichen. Eine einzelne ss-Ausgabe ist ein Foto. Zwei Ausgaben im Abstand von einer Minute zeigen Ihnen, ob die Situation wächst, schrumpft oder stabil ist.
6. Notieren Sie den genauen Filter. Während Vorfällen ist ein gespeicherter Befehl wie ss -tan '( dport = :5432 )' einfacher zu wiederholen und zu vergleichen als eine halb erinnerte grep-Pipeline.

Die Gewohnheit, die sich auszahlt, ist einfach: Beginnen Sie mit Listenern, gehen Sie zu Verbindungszuständen über, identifizieren Sie den besitzenden Prozess und entscheiden Sie dann, ob der nächste Schritt in die App, den Netzwerkpfad, die Firewall oder den Kernel gehört.