Wie passiv auf TCP-Paketverlust überwachen? (Linux)

Wie kann ich den Paketverlust bei TCP-Verbindungen von / zu meinem Computer passiv überwachen?

Grundsätzlich hätte ich gerne ein Tool, das im Hintergrund sitzt und die TCP-Bestätigung / Bestätigung / erneute Übertragung überwacht, um einen Bericht zu generieren, bei dem Peer-IP-Adressen "scheinbar" stark verloren gehen.

Die meisten Fragen wie diese, die ich von SF finde, schlagen die Verwendung von Werkzeugen wie iperf vor. Ich muss jedoch Verbindungen zu / von einer realen Anwendung auf meinem Computer überwachen.

Sitzen diese Daten nur im Linux-TCP-Stack?

Um einen allgemeinen netstat -sÜberblick über den Umfang Ihres Problems zu erhalten, wird die Gesamtzahl der erneuten Übertragungen aufgezeichnet.

# netstat -s | grep retransmitted
     368644 segments retransmitted

Sie können auch nachfragen segments, um eine detailliertere Ansicht zu erhalten:

# netstat -s | grep segments
         149840 segments received
         150373 segments sent out
         161 segments retransmitted
         13 bad segments received

Für einen tieferen Tauchgang möchten Sie wahrscheinlich Wireshark starten.

Stellen Sie in Wireshark Ihren Filter so ein tcp.analysis.retransmission, dass Neuübertragungen durch Datenfluss angezeigt werden.

Das ist die beste Option, die ich mir vorstellen kann.

Andere Sackgassen erkundet:

• netfilter / conntrack tools scheinen keine Retransmits zu halten
• Stracing netstat -szeigte, dass es nur Drucken ist/proc/net/netstat
• Spalte 9 in / proc / net / tcp sah vielversprechend aus, scheint aber leider ungenutzt zu sein.

Diese Statistiken befinden sich in / proc / net / netstat und collectlwerden entweder interaktiv für Sie überwacht oder zur späteren Wiedergabe auf die Festplatte geschrieben:

[root@poker ~]# collectl -st
waiting for 1 second sample...
#<------------TCP------------->
#PureAcks HPAcks   Loss FTrans
        3      0      0      0
        1      0      0      0

Natürlich, wenn Sie dann mit den Netzwerkverkehr-Seite an Seite sehen möchten, geben Sie einfach nmit -s:

[root@poker ~]# collectl -stn
waiting for 1 second sample...
#<----------Network----------><------------TCP------------->
#  KBIn  PktIn  KBOut  PktOut PureAcks HPAcks   Loss FTrans
      0      1      0       1        1      0      0      0
      0      1      0       1        1      0      0      0

Mit dem ssTool können Sie detaillierte TCP-Statistiken abrufen:

$ /sbin/ss -ti

Verwenden Sie unter Debian, apt-get install iprouteum die Binärdatei abzurufen.

Es sieht so aus, als hätten einige Leute an der Universität von North Carolina (UNC) ein Hilfsprogramm gebaut, um genau dies zu untersuchen:

Methodik

TCP ist ein klassisches Beispiel für ein Legacy-Protokoll, das Änderungen unterworfen ist. Leider ist die Bewertung eines so grundlegenden Aspekts wie der Verlusterkennungs- / Wiederherstellungsmechanismus von TCP nicht umfassend. Unser Ziel ist es, eine vollständige realistische Bewertung der TCP-Verluste und ihrer Auswirkungen auf die TCP-Leistung durchzuführen.

Ich verlasse mich auf die passive Analyse realer TCP-Verbindungen, um den erforderlichen Detaillierungsgrad und Realismus bei meiner Analyse zu erzielen.

http://www.cs.unc.edu/~jasleen/Research-passivetcp.htm#Tool

Werkzeug

Der Zweck des Tools besteht darin, vollständigere und genauere Ergebnisse für die Identifizierung und Charakterisierung von Segmenten außerhalb der Sequenz zu liefern, als dies mit früheren Tools wie tcpanaly, tcpflows, LEAST und Mystery möglich ist. Unsere Methodik klassifiziert jedes Segment, das in einer Paketverfolgung außerhalb der Reihenfolge (OOS) erscheint, in eine der folgenden Kategorien: Neuordnung des Netzwerks oder erneute TCP-Übertragung, ausgelöst durch Timeout, doppelte ACKs, teilweise ACKs, selektive ACKs oder implizite Wiederherstellung. Ferner wird jede erneute Übertragung auch dahingehend beurteilt, ob sie benötigt wurde oder nicht.

Ich werde nicht sagen, dass es Produktionsqualität ist. Bisher habe ich schnelle Perl-Skripte erstellt, um IP / Port / Ack-Tupel im Speicher zu speichern und dann doppelte Daten aus der Ausgabe des Scan-PCs zu melden. Dies scheint eine gründlichere Analyse zu bieten.

Vielleicht möchten Sie sich das dropwatchDienstprogramm ansehen .

Anscheinend kann ein guter alter sar eine erneute Übertragung (und andere TCP-Statistiken) zusammen mit allen anderen Systemstatistiken erfassen, die ebenfalls interessant sein könnten, wenn Sie ein Problem wie CPU, Speicher, Festplatten-E / A usw. untersuchen.

Möglicherweise müssen Sie ein Paket installieren: sysstat und diese Art von Statistik mit dem Schalter -S SNMP aktivieren. Unter RHEL / OracleLinux wird dies in /etc/cron.d/sysstat konfiguriert, wobei / usr / lib64 / sa / sa1 aufgerufen wird standardmäßig alle 5 Minuten, aber das kann auch eingestellt werden.

Zur Analyse dieser Daten verwenden Sie:

• sar (Befehlszeile, textbasiert)
• sadf erstellt SVG gemäß http://sebastien.godard.pagesperso-orange.fr/matrix.html
• ksar (das kann nette Grafiken zeichnen und läuft auf Java - es gibt verschiedene Klone, aus denen ich auf sf.net und github auswählen kann, wenn ich mich richtig erinnere)
• http://www.sargraph.com (basierend auf PHP, mit dem ich überhaupt keine Erfahrung habe - wohlgemerkt die Anwendung, nicht die Programmiersprache language)