Jak biernie monitorować utratę pakietów TCP? (Linux)


61

Jak mogę pasywnie monitorować utratę pakietów na połączeniach TCP do / z mojego komputera?

Zasadniczo chciałbym, aby narzędzie, które siedzi w tle i obserwowało TCP ack / nak / re-transmisję, wygenerowało raport, w którym adresy „równorzędne” „wydają się” doświadczać dużej utraty.

Większość takich pytań, które znalazłem w SF, sugeruje użycie narzędzi takich jak iperf. Ale muszę monitorować połączenia z / do prawdziwej aplikacji na moim komputerze.

Czy te dane po prostu znajdują się tam na stosie TCP Linux?

Odpowiedzi:


49

Dla ogólnego zrozumienia skali problemu netstat -sbędzie śledzić całkowitą liczbę retransmisji.

# netstat -s | grep retransmitted
     368644 segments retransmitted

Możesz również przywitać się, segmentsaby uzyskać bardziej szczegółowy widok:

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

Na głębsze nurkowanie prawdopodobnie będziesz chciał odpalić Wireshark.

W Wireshark ustaw filtr tak, tcp.analysis.retransmissionaby wyświetlał retransmisje według przepływu.

To najlepsza opcja, jaką mogę wymyślić.

Inne zbadane ślepe zaułki:

  • narzędzia netfilter / conntrack wydają się nie utrzymywać retransmisji
  • stracing netstat -spokazał, że to tylko drukowanie/proc/net/netstat
  • kolumna 9 w / proc / net / tcp wyglądała obiecująco, ale niestety wydaje się nieużywana.

i możesz monitorować utracone pakiety za pomocą # watch 'netstat -s | grep retransmited '
brak

To pokazałoby tylko problemy wychodzące. „netstat -s | grep segmenty” wydaje mi się bardziej rozsądny.
akostadinov

1
Jeśli zarządzasz siecią o rozsądnych rozmiarach, polecam pastmon zamiast wireshark do ciągłego monitorowania - pastmon.sourceforge.net/Wikka-1.1.6.5/wikka.php?wakka=HomePage
symcbean

4
Z jakiegoś powodu jest to retransmiteddla mnie pisownia (Ubuntu Server 14).
sudo

1
jaka jest dobra stawka za retransmisje w porównaniu do wysłanych lub odebranych?
abourget

12

Te statystyki znajdują się w / proc / net / netstat i collectlbędą monitorować je interaktywnie lub zapisywać na dysku w celu późniejszego odtworzenia:

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

Oczywiście, jeśli chcesz zobaczyć obok ruchu sieciowego, po prostu dołącz nz -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

7

Możesz użyć tego ssnarzędzia, aby uzyskać szczegółowe statystyki TCP:

$ /sbin/ss -ti

W Debianie użyj, apt-get install iprouteaby uzyskać plik binarny.


Zauważ, że osoba zadająca pytanie szukała narzędzia, z którego mogłaby obserwować wyniki. Chociaż niektóre z wymienionych do tej pory poleceń nie działają w ten sposób, wszystkie wyżej ocenione odpowiedzi zawierały co najmniej jedną metodę.
Andrew B,

2
@AndrewB: Możesz watch ss -ti.
John Zwinck

3

Wygląda na to, że niektórzy faceci z University of North Carolina (UNC) zbudowali narzędzie do zbadania dokładnie tego:

Metodologia

TCP jest klasycznym przykładem starszego protokołu, który podlega modyfikacjom. Niestety, ocena czegoś tak fundamentalnego jak mechanizm wykrywania / odzyskiwania strat TCP nie jest wyczerpująca. Naszym celem jest przeprowadzenie pełnej realistycznej oceny strat TCP i ich wpływu na wydajność TCP.

Opieram się na pasywnej analizie połączeń TCP w świecie rzeczywistym, aby osiągnąć wymagany poziom szczegółowości i realizmu w mojej analizie.

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

Narzędzie

Celem tego narzędzia jest dostarczenie bardziej kompletnych i dokładnych wyników do identyfikowania i charakteryzowania segmentów spoza sekwencji niż te dostarczane przez wcześniejsze narzędzia, takie jak tcpanaly, tcpflows, LEAST i Mystery. Nasza metodologia klasyfikuje każdy segment, który pojawia się poza kolejnością (OOS) w śledzeniu pakietów, do jednej z następujących kategorii: zmiana kolejności sieci lub retransmisja TCP wywołana przez jeden z limitów czasu, duplikaty ACK, częściowe ACK, selektywne ACK lub niejawne odzyskiwanie. Ponadto, każda retransmisja jest również oceniana pod kątem tego, czy była potrzebna, czy nie.

Nie powiem, że to jakość produkcji. Wcześniej zbudowałem szybkie skrypty perla do przechowywania krotek IP / portu / ack w pamięci, a następnie raportowania o zduplikowanych danych ze skanowania wyników pcap, wygląda na to, że zapewnia to dokładniejszą analizę.



0

Najwyraźniej stary dobry sar może zbierać retransmisję (i inne statystyki TCP), a także wszelkiego rodzaju inne statystyki systemowe, które mogą być również interesujące, jeśli zbadasz problem, taki jak procesor, pamięć, operacje we / wy dysku itp.

Może być konieczne zainstalowanie pakietu: sysstat i włączenie tego rodzaju statystyk za pomocą przełącznika -S SNMP, na RHEL / OracleLinux konfiguruje się to w /etc/cron.d/sysstat, gdzie wywoływane jest / usr / lib64 / sa / sa1 domyślnie co 5 minut, ale można to również dostroić.

Do analizy tych danych użyj:

  • sar (linia poleceń, tekst)
  • sadf tworzy SVG zgodnie z http://sebastien.godard.pagesperso-orange.fr/matrix.html
  • ksar (który potrafi drukować ładne wykresy i działa na Javie - istnieje kilka różnych klonów do wyboru na sf.net i github, jeśli dobrze pamiętam)
  • http://www.sargraph.com (oparty na PHP, z którym nie mam żadnego doświadczenia - pamiętajcie o aplikacji, a nie o języku programowania 😉)
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.