Auteur Sujet: Outil pour récupérer les "Extended TCP statistics" (Microsoft) (Lu 8004 fois)

vivien · « **Réponse #12 le:** 09 septembre 2014 à 09:10:36 »

réponse de Stéphane Bortzmeyer sur un outil linux type wget / curl qui permet de voir les paquets TCP retransmis sur un téléchargement http ou https, sans avoir besoin de faire de capture Wireshark :

Hmmm, ce n'est pas possible de le faire de façon portable, même entre tous les Unix. Linux a sa struct tcpinfo (très bien expliquée en http://linuxgazette.net/136/pfeiffer.html ) et qui a un champ qui semble le bon :

__u32 tcpi_lost;
__u32 tcpi_retrans;

Mais je ne connais pas de logiciel de transfert de fichier qui l'utilise. Mon echoping <http://echoping.sourceforge.net/> le fait (quand il est compilé sur Linux) mais n'affiche pas cette valeur particulière :

% echoping -v -h / www.bortzmeyer.org

This is echoping, version 6.0.2.

Trying to connect to internet address 2001:4b98:dc0:41:216:3eff:fece:1902 80 to transmit 91 bytes...
Trying to send 256 bytes to internet address 2001:4b98:dc0:41:216:3eff:fece:1902...
Connected...
TCP Latency: 0.002406 seconds
Sent (91 bytes)...
Application Latency: 0.002813 seconds
150373 bytes read from server.
Estimated TCP RTT: 0.0035 seconds (std. deviation 0.002) Elapsed time: 0.017364 seconds %

l faudrait modifier le source dont le TODO indique bien ce qui reste à faire :

if (getsockopt(sockfd, SOL_TCP, TCP_INFO, &tcpinfo, &socket_length)
!= -1) {
/* TODO: find out the meaning of the various fields in the struct
* tcp_info (it seems documented only in the Linux kernel sources)
* and display stuff like reordering (see RFC 4737), window, lost
* packets, etc. */
printf
("TCP-Estimated RTT: %.04f seconds (std. deviation %0.03f)\n",
tcpinfo.tcpi_rtt / 1000000.0, tcpinfo.tcpi_rttvar / 1000000.0);
}

vivien · « **Réponse #13 le:** 09 septembre 2014 à 11:34:56 »

Sous linux, une autre solution consiste a afficher netstat -s avant et après un téléchargement.

Pas facile a automatiser car certaines lignes ne s’affichent que en cas de problème.

Voici le netstat -s de LaFibre.info après 28 jours d'uptime, ce qui permet d'avoir probablement tous les cas tordus qui se sont produits comme des "réassemblement de paquets raté" ou des "cookies SYN invalides reçus" ou "paquets ICMP rejetés par ce qu'ils étaient en dehors de la fenêtre d'acquittement" :

$ netstat -s Ip: 1722728810 paquets reçus au total 0 réacheminés 9 avec un protocole inconnu 0 paquets arrivant rejetés 1720306638 paquets entrants délivrés 1647564989 requêtes envoyées 36 paquets sortants rejetés 131 fragments dropped after timeout 3227 réassemblements requis 1548 paquets réassemblés correctement 131 réassemblement de paquets raté 5 fragments échoués Icmp: 21245859 Messages ICMP reçus 4479 messages ICMP entrant échoués InCsumErrors: 5 Histogramme d'entrée ICMP destination injoignable: 52729 temps de transit maximal dépassé: 90764 source quenches: 16 redirections : 11163 requêtes d'echo : 12310008 echo replies: 8781173 timestamp request: 1 21843944 messages ICMP envoyés 0 messages ICMP échoués Histogramme de sortie ICMP destination injoignable: 149868 temps dépassé : 24 requête d'écho : 9381069 echo replies: 12310008 timestamp replies: 1 IcmpMsg: InType0: 8781173 InType3: 52729 InType4: 16 InType5: 11163 InType8: 12310008 InType11: 90764 InType13: 1 OutType0: 12310008 OutType3: 149868 OutType8: 9381069 OutType11: 24 OutType14: 1 OutType69: 2974 Tcp: 1189580 ouvertures de connexions actives 10117658 connexions passives ouvertes 108634 tentatives de connexion échouées 1206206 reinitialisation de la connection détéctée 31 connexions établies 1760302878 segments reçus 3135863866 segments envoyés 29463842 segments retransmis 4085 mauvais segments reçus 2407334 réinitailisations envoyées InCsumErrors: 3858 Udp: 6771520 packets reçus 337223 paquets reçus sur un port inconnu 7 erreurs de réception de paquet 7172814 paquets envoyés InCsumErrors: 7 UdpLite: TcpExt: 477721 cookies SYN invalides reçus 108612 resets received for embryonic SYN_RECV sockets 262 packets pruned from receive queue because of socket buffer overrun 80 paquets ICMP rejetés par ce qu'ils étaient en dehors de la fenêtre d'acquittement 4 ICMP packets dropped because socket was locked 5476212 TCP sockets finished time wait in fast timer 184743 paquets rejetés parmis les connections établies à cause de la date 5282493 accusés de réception envoyés en retard 4845 delayed acks further delayed because of locked socket Le mode ACK rapide a été activé 1842229 fois 29 times the listen queue of a socket overflowed 3454 SYNs to LISTEN sockets dropped 259048143 paquets directement mis en attente dans la file d'attente recvmsg. 79837331 bytes directly in process context from backlog 130226476 bytes directly received in process context from prequeue 356451140 en-têtes de paquets prédits 5912402 packets header predicted and directly queued to user 717491703 acknowledgments not containing data payload received 504802673 accusés de réception prédits 3268 times recovered from packet loss due to fast retransmit 6224708 times recovered from packet loss by selective acknowledgements 13495 bad SACK blocks received Detected reordering 11619 times using FACK Detected reordering 23305 times using SACK Detected reordering 311 times using reno fast retransmit Detected reordering 28879 times using time stamp 22598 congestion windows fully recovered without slow start 20170 congestion windows partially recovered using Hoe heuristic 88419 congestion windows recovered without slow start by DSACK 292792 congestion windows recovered without slow start after partial ack TCPLostRetransmit: 898703 410 timeouts after reno fast retransmit 131816 timeouts after SACK recovery 84960 timeouts in loss state 24481247 fast retransmits 1074420 forward retransmits 1744282 retransmits in slow start 1219613 other TCP timeouts TCPLossProbes: 1454650 TCPLossProbeRecovery: 368516 461 classic Reno fast retransmits failed 297190 SACK retransmits failed 2137 times receiver scheduled too late for direct processing 7541 packets collapsed in receive queue due to low socket buffer 2020998 DSACKs sent for old packets 168292 DSACKs sent for out of order packets 1255815 DSACKs received 18255 DSACKs for out of order packets received 1025069 connections reset due to unexpected data 5630 connections reset due to early user close 70277 connections aborted due to timeout TCPSACKDiscard: 15987 TCPDSACKIgnoredOld: 22849 TCPDSACKIgnoredNoUndo: 450128 TCPSpuriousRTOs: 254789 TCPSackShifted: 4924670 TCPSackMerged: 50990313 TCPSackShiftFallback: 75695778 TCPDeferAcceptDrop: 9705821 TCPRetransFail: 1064 TCPRcvCoalesce: 2759397 TCPOFOQueue: 33859408 TCPOFOMerge: 162264 TCPChallengeACK: 92152 TCPSYNChallenge: 14 TCPFastOpenPassive: 129 TCPSpuriousRtxHostQueues: 2254 IpExt: InMcastPkts: 19416 InBcastPkts: 818 InOctets: -1821438442 OutOctets: 51667828 InMcastOctets: 621312 InBcastOctets: 191576 InNoECTPkts: 1795714230 InECT1Pkts: 1051 InECT0Pkts: 465434 InCEPkts: 410243

Voici ce que donne un grep sur "ret" sur LaFibre.info :
$ netstat -s | grep ret 29479317 segments retransmis 5284786 accusés de réception envoyés en retard 3270 times recovered from packet loss due to fast retransmit Detected reordering 312 times using reno fast retransmit 410 timeouts after reno fast retransmit 24494340 fast retransmits 1074796 forward retransmits 1745302 retransmits in slow start 461 classic Reno fast retransmits failed 297428 SACK retransmits failed

Inversement, sur une machine qui viens de démarrer, seul la ligne "segments retransmis" s'affiche si elle est à 0

$ netstat -s | grep ret 0 segments retransmis

vivien · « **Réponse #14 le:** 09 septembre 2014 à 17:57:57 »

Citation de: kgersen le 03 septembre 2014 à 16:04:23

En cherchant dans les vieux SDK Windows, il y a bien un outil qui permet de faire ce dont on parlais.

Pour obtenir ce programme il faut télécharger le SDK suivant : Windows SDK for Windows Server 2008 and .NET Framework 3.5 (1,3 Go) et installé uniquement les 'tools'.
L'outil s'appele tcpanalyzer.exe

Je ne sais pas si on parle du même TCP Analyser, mais le mien se télécharge sur http://research.microsoft.com/en-us/projects/tcpanalyzer/
Il faut installer le wireshark de Miscrosoft avant TCP Analyser : Microsoft Network Monitor 3.4 dispo sur http://www.microsoft.com/en-us/download/details.aspx?id=4865
Ensuite ce n'est pas une analyse en temps réel, mais une analyse sur des fichiers capturés par Microsoft Network Monitor 3.4

Le seul intérêt de Microsoft Network Monitor 3.4 sur Wireshark, c'est d'avoir le nom du process qui génère le trafic.

kgersen · « **Réponse #15 le:** 09 septembre 2014 à 18:11:49 »

Non je parle d'un tout petit programme qu'on trouve dans le SDK en question: tcpanalyzer.exe (91 ko, daté de 2008). Il faut installer les dev tools du sdk pour l'installer (j'ai fait ca dans une VM de Windows 7 ou XP pour l'avoir, il y en a des gratuites ici : https://www.modern.ie/fr-fr/virtualization-tools (celles pour virtualbox sont tres bien)).

Je te link l'executable mais il risque de mal marché a cause des dépendances (dll,etc): https://mega.co.nz/#!XZQXiChZ!2mRPbak4UqKG0nLV7eiiAoURQ9qZW5xxCTQcpY1pNfg (actives le mode compatibilité server 2008).

Mais c'est vraiment pas terrible , perds par trop de temps la dessus

vivien · « **Réponse #16 le:** 09 septembre 2014 à 18:32:57 »

Pas de souci de compatibilité, je me suis installé un Windows Server 2008 SP2.

Ton petit utilitaire, je l'ai bien trouvé après l’installation du SDK (par contre il est bien caché) mais il n'indique pas les pertes de paquets... (et oui, il est mal codé les 3 bouton en dessous ne sont plus visible si on réduit la fenêtre)