Comment surveiller passivement la perte de paquets tcp ? (Linux)

Pour avoir une idée générale de l'ampleur de votre problème netstat -s suivra votre nombre total de retransmissions.

# netstat -s | grep retransmitted
     368644 segments retransmitted

Vous pouvez également rechercher segments pour obtenir une vue plus détaillée :

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

Pour une plongée plus profonde, vous aurez probablement envie de lancer Wireshark.

Dans Wireshark, réglez votre filtre sur tcp.analysis.retransmission pour voir les retransmissions par flux.

C'est la meilleure option que j'ai trouvée.

Autres impasses explorées :

• Les outils netfilter/conntrack ne semblent pas conserver les retransmissions.
• stratification netstat -s a montré que c'est juste une impression /proc/net/netstat
• La colonne 9 dans /proc/net/tcp semblait prometteuse, mais elle semble malheureusement inutilisée.

Ces statistiques sont dans /proc/net/netstat et collectl les surveillera pour vous, soit de manière interactive, soit en les écrivant sur le disque pour une lecture ultérieure :

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

Bien sûr, si vous souhaitez voir le trafic du réseau côte à côte, il suffit d'inclure n avec -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

Vous pouvez utiliser le ss pour obtenir des statistiques TCP détaillées :

$ /sbin/ss -ti

Sous Debian, utilisez apt-get install iproute pour obtenir le binaire.

Il semble que des gars de l'Université de Caroline du Nord (UNC) aient construit un utilitaire pour étudier exactement cette question :

Méthodologie

TCP est un exemple classique d'un protocole hérité qui est soumis de modifications. Malheureusement, l'évaluation d'un élément aussi fondamental que le mécanisme de détection/récupération des pertes de TCP n'est pas complète. Notre objectif est d'effectuer une évaluation réaliste complète des pertes TCP et de son impact sur les performances du TCP.

Je m'appuie sur l'analyse passive de connexions TCP réelles pour atteindre le niveau de détail et de réalisme requis dans mon analyse.

http://www.cs.unc.edu/~jasleen/Recherche-passivetcp.htm#Outil

Outil

L'objectif de l'outil est de fournir des données plus complètes et plus précises sur l'état d'avancement du projet. plus complets et plus précis pour identifier et caractériser les segments hors séquence que ceux fournis par les outils précédents tels que tcpanaly, tcpflows, LEAST, et Mystery. Notre méthodologie classifie chaque segment qui apparaît hors séquence (OOS) dans une trace de paquets dans l'une des catégories suivantes catégories suivantes : réorganisation du réseau ou retransmission TCP déclenchée par l'un des éléments suivants déclenchée par l'un des éléments suivants : timeout, ACKs dupliqués, ACKs partiels, ACKs sélectifs, ou récupération implicite. récupération implicite. En outre, chaque retransmission est également évaluée pour savoir si elle nécessaire ou non.

Je ne dirai pas que c'est une production de qualité. Auparavant, j'ai construit des scripts perl rapides pour stocker des tuples ip/port/ack en mémoire et ensuite faire un rapport sur les données dupliquées à partir du balayage de la sortie pcap, ceci semble fournir une analyse plus approfondie.

Vous pouvez consulter le dropwatch utilitaire.