Auteur Sujet: TCPtrace - analyse du protocole TCP d'une capture wireshark (Lu 7485 fois)

vivien · « **le:** 28 septembre 2011 à 20:33:30 »

TCPtrace est un outil pour analyser une capture Wireshark et voir de nombreux indicateur lié au protocole TCP

Detail des indicateurs fournis par TCPtrace :

total packets The total number of packets seen.
ack pkts sent The total number of ack packets seen (TCP segments seen with the ACK bit set).
pure acks sent The total number of ack packets seen that were not piggy-backed with data (just the TCP header and no TCP data payload) and did not have any of the SYN/FIN/RST flags set.
sack pkts sent The total number of ack packets seen carrying TCP SACK [4] blocks.
dsack pkts sent The total number of sack packets seen that carried duplicate SACK (D-SACK) [6] blocks.
max sack blks/ack The maximum number of sack blocks seen in any sack packet.
unique bytes sent The number of unique bytes sent, i.e., the total bytes of data sent excluding retransmitted bytes and any bytes sent doing window probing.
actual data pkts The count of all the packets with at least a byte of TCP data payload.
actual data bytes The total bytes of data seen. Note that this includes bytes from retransmissions / window probe packets if any.
rexmt data pkts The count of all the packets found to be retransmissions.
rexmt data bytes The total bytes of data found in the retransmitted packets.
zwnd probe pkts The count of all the window probe packets seen. (Window probe packets are typically sent by a sender when the receiver last advertised a zero receive window, to see if the window has opened up now).
zwnd probe bytes The total bytes of data sent in the window probe packets.
outoforder pkts The count of all the packets that were seen to arrive out of order.
pushed data pkts The count of all the packets seen with the PUSH bit set in the TCP header.
SYN/FIN pkts sent The count of all the packets seen with the SYN/FIN bits set in the TCP header respectively.
req 1323 ws/ts If the endpoint requested Window Scaling/Time Stamp options as specified in RFC 1323[9] a `Y' is printed on the respective field. If the option was not requested, an `N' is printed. For example, an ``N/Y'' in this field means that the window-scaling option was not specified, while the Time-stamp option was specified in the SYN segment.
Note that since Window Scaling option is sent only in SYN packets, this field is meaningful only if the connection was captured fully in the dumpfile to include the SYN packets.
adv wind scale The window scaling factor used. Again, this field is valid only if the connection was captured fully to include the SYN packets. Since the connection would use window scaling if and only if both sides requested window scaling [9], this field is reset to 0 (even if a window scale was requested in the SYN packet for this direction), if the SYN packet in the reverse direction did not carry the window scale option.
req sack If the end-point sent a SACK permitted option in the SYN packet opening the connection, a `Y' is printed; otherwise `N' is printed.
sacks sent The total number of ACK packets seen carrying SACK information.
urgent data pkts The total number of packets with the URG bit turned on in the TCP header.
urgent data bytes The total bytes of urgent data sent. This field is calculated by summing the urgent pointer offset values found in packets having the URG bit set in the TCP header.
mss requested The Maximum Segment Size (MSS) requested as a TCP option in the SYN packet opening the connection.
max segm size The maximum segment size observed during the lifetime of the connection.
min segm size The minimum segment size observed during the lifetime of the connection.
avg segm size The average segment size observed during the lifetime of the connection calculated as the value reported in the actual data bytes field divided by the actual data pkts reported.
max win adv The maximum window advertisement seen. If the connection is using window scaling (both sides negotiated window scaling during the opening of the connection), this is the maximum window-scaled advertisement seen in the connection. For a connection using window scaling, both the SYN segments opening the connection have to be captured in the dumpfile for this and the following window statistics to be accurate.
min win adv The minimum window advertisement seen. This is the minimum window-scaled advertisement seen if both sides negotiated window scaling.
zero win adv The number of times a zero receive window was advertised.
avg win adv The average window advertisement seen, calculated as the sum of all window advertisements divided by the total number of packets seen. If the connection endpoints negotiated window scaling, this average is calculated as the sum of all window-scaled advertisements divided by the number of window-scaled packets seen. Note that in the window-scaled case, the window advertisements in the SYN packets are excluded since the SYN packets themselves cannot have their window advertisements scaled, as per RFC 1323[9].
max owin The maximum outstanding unacknowledged data (in bytes) seen at any point in time in the lifetime of the connection.
min non-zero owin The minimum (non-zero) outstanding unacknowledged data (in bytes) seen.
avg owin The average outstanding unacknowledged data (in bytes), calculated from the sum of all the outstanding data byte samples (in bytes) divided by the total number of samples.
wavg owin The weighted average outstanding unacknowledged data seen. For example, if the outstanding data (odata) was 500 bytes for the first 0.1 seconds, 1000 bytes for the next 1 second, and 2000 bytes for the last 0.1 seconds of a connection that lasted 1.2 seconds, wavg owin= ((500 x 0.1) + (1000 x 1) + (2000 x 0.1)) / 1.2 = 1041.67 bytes an estimate closer to 1000 bytes which was the outstanding data for the most of the lifetime of the connection. Note that the straight-forward average reported in avg owin would have been (500+1000+2000)/1.2 = 2916.67 bytes, a value less indicative of the outstanding data observed during most of the connection's lifetime.
initial window The total number of bytes sent in the initial window i.e., the number of bytes seen in the initial flight of data before receiving the first ack packet from the other endpoint. Note that the ack packet from the other endpoint is the first ack acknowledgingsome data (the ACKs part of the 3-way handshake do not count), and any retransmitted packets in this stage are excluded.
initial window The total number of segments (packets) sent in the initial window as explained above.
ttl stream length The Theoretical Stream Length. This is calculated as the difference between the sequence numbers of the SYN and FIN packets, giving the length of the data stream seen. Note that this calculation is aware of sequence space wrap-arounds, and is printed only if the connection was complete (both the SYN and FIN packets were seen).
missed data The missed data, calculated as the difference between the ttl stream length and unique bytes sent. If the connection was not complete, this calculation is invalid and an ``NA'' (Not Available) is printed.
truncated data The truncated data, calculated as the total bytes of data truncated during packet capture. For example, with tcpdump, the snaplen option can be set to 64 (with -s option) so that just the headers of the packet (assuming there are no options) are captured, truncating most of the packet data. In an Ethernet with maximum segment size of 1500 bytes, this would amount to truncated data of 1500 - 64 = 1436 bytes for a packet.
truncated packets The total number of packets truncated as explained above.
data xmit time Total data transmit time, calculated as the difference between the times of capture of the first and last packets carrying non-zero TCP data payload.
idletime max Maximum idle time, calculated as the maximum time between consecutive packets seen in the direction.
throughput The average throughput calculated as the unique bytes sent divided by the elapsed time i.e., the value reported in the unique bytes sent field divided by the elapsed time (the time difference between the capture of the first and last packets in the direction).
RTT samples The total number of Round-Trip Time (RTT) samples found. tcptrace is pretty smart about choosing only valid RTT samples. An RTT sample is found only if an ack packet is received from the other endpoint for a previously transmitted packet such that the acknowledgment value is 1 greater than the last sequence number of the packet. Further, it is required that the packet being acknowledged was not retransmitted, and that no packets that came before it in the sequence space were retransmitted after the packet was transmitted. Note : The former condition invalidates RTT samples due to the retransmission ambiguity problem, and the latter condition invalidates RTT samples since it could be the case that the ack packet could be cumulatively acknowledging the retransmitted packet, and not necessarily ack-ing the packet in question.
RTT min The minimum RTT sample seen.
RTT max The maximum RTT sample seen.
RTT avg The average value of RTT found, calculated straightforward-ly as the sum of all the RTT values found divided by the total number of RTT samples.
RTT stdev The standard deviation of the RTT samples.
RTT from 3WHS The RTT value calculated from the TCP 3-Way Hand-Shake (connection opening) [2], assuming that the SYN packets of the connection were captured.
RTT full_sz smpls The total number of full-size RTT samples, calculated from the RTT samples of full-size segments. Full-size segments are defined to be the segments of the largest size seen in the connection.
RTT full_sz min The minimum full-size RTT sample.
RTT full_sz max The maximum full-size RTT sample.
RTT full_sz avg The average full-size RTT sample.
RTT full_sz stdev The standard deviation of full-size RTT samples.
post-loss acks The total number of ack packets received after losses were detected and a retransmission occurred. More precisely, a post-loss ack is found to occur when an ack packet acknowledges a packet sent (acknowledgment value in the ack pkt is 1 greater than the packet's last sequence number), and at least one packet occurring before the packet acknowledged, was retransmitted later. In other words, the ack packet is received after we observed a (perceived) loss event and are recovering from it.
ambiguous acks, RTT min, RTT max, RTT avg, RTT sdv These fields are printed only if there was at least one ack received that was ambiguous due to the retransmission ambiguity problem i.e., the segment being ack-ed was retransmitted and it is impossible to determine if the ack is for the original or the retransmitted packet. Note that these samples are not considered in the RTT samples explained above. The statistics below are calculated from the time of capture of the last transmitted instance of the segment.
ambiguous acks is the total number of such ambiguous acks seen. The following RTT min, RTT max, RTT avg, RTT sdv fields represent the minimum, maximum, average, and standard deviation respectively of the RTT samples calculated from ambiguous acks.
segs cum acked The count of the number of segments that were cumulatively acknowledged and not directly acknowledged.
duplicate acks The total number of duplicate acknowledgments received. An ack packet is found to be a duplicate ack based on this definition used by 4.4 BSD Lite TCP Stack [10] :
o The ack packet has the biggest ACK (acknowledgment number) ever seen.
o The ack should be pure (carry zero tcp data payload).
o The advertised window carried in the ack packet should not change from the last window advertisement.
o There must be some outstanding data.
Note : older versions of tcptrace (until version 6.4.2) used a legacy algorithm using just the first condition amongst the four listed above, to treat an ack as duplicate ack. This older behavior may be emulated (if necessary at all) with the --turn_off_BSD_dupack option.
triple dupacks The total number of triple duplicate acknowledgments received (three duplicate acknowledgments acknowledging the same segment), a condition commonly used to trigger the fast-retransmit/fast-recovery phase of TCP.
max # retrans The maximum number of retransmissions seen for any segment during the lifetime of the connection.
min retr time The minimum time seen between any two (re)transmissions of a segment amongst all the retransmissions seen.
max retr time The maximum time seen between any two (re)transmissions of a segment.
avg retr time The average time seen between any two (re)transmissions of a segment calculated from all the retransmissions.
sdv retr time The standard deviation of the retransmission-time samples obtained from all the retransmissions.

Site officiel de TCPtrace : http://www.tcptrace.org/
Le manuel en ligne (an anglais mais bien fait) : http://www.tcptrace.org/manual/index.html

Il est présent dans les dépots Debian et Ubuntu.

Ligne de commande : /usr/bin/tcptrace --nores_addr -lrW fichier.cap

vivien · « **Réponse #1 le:** 28 septembre 2011 à 20:35:07 »

Si vous souhaitez automatiser le post-traitement TCPtrace, j'ai déja écris un bout de code avec perl :

Code: [Sélectionner]

###################### TRAITEMENT DU FICIHIER .cap ######################
`/usr/bin/tcptrace --nores_addr -lrW $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.cap > $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace`;


###################### TRAITEMENT DU FICHIER .tcptrace ######################

### actual data pkts : PAQUETS ECHANGES ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "actual data pkts:"`;
$tmp = substr($valeur[0],23,10);
my $DownPaquets = sprintf("%.0f", $tmp);
$tmp = substr($valeur[1],23,10);
my $UpPaquets = sprintf("%.0f", $tmp);
if ($DownPaquets == 0) { `/bin/rm $Ramdisk_Dir/vigie.txt`; print "\nERREUR Nb paquets download = 0\n"; die "===> Paquets download = 0\n"; }
if ($UpPaquets == 0) { `/bin/rm $Ramdisk_Dir/vigie.txt`; print "\nERREUR Nb paquets upload = 0\n"; die "===> Paquets upload = 0\n"; }

### rexmt data pkts : PAQUETS RE-EMIS EN DOWNLOAD - PAQUETS RECUS EN DOUBLE (dupliqués) EN UPLAOD ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "rexmt data pkts:"`;
$tmp = substr($valeur[0],23,10);
my $DownPktsRetransmis = sprintf("%.0f", $tmp);
$tmp = substr($valeur[1],23,10);
my $UpPktsDupliques = sprintf("%.0f", $tmp);

### outoforder pkts : PAQUETS PERDU EN UPLOAD ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "outoforder pkts:"`;
# outoforder pkts : TRAITEMENT 2eme LIGNE (upload)
$tmp = substr($valeur[1],23,10);
my $UpPktsPerdus = sprintf("%.0f", $tmp);

### Calcul des pourcentages  ###
my $DownPaquetsUtile = $DownPaquets - $DownPktsRetransmis;
my $UpPaquetsUtile = $UpPaquets - $UpPktsDupliques;
my $UpPaquetsTotalCli = $UpPaquets + $UpPktsPerdus;
my $DownPcentRetransmis = sprintf("%.3f", 100 * $DownPktsRetransmis / $DownPaquetsUtile);
my $UpPcentDupliques = sprintf("%.3f", 100 * $UpPktsDupliques / $UpPaquetsUtile);
my $UpPcentPerdus = sprintf("%.3f", 100 * $UpPktsPerdus / $UpPaquetsUtile);

### Calcul des paquets retransmis en upload  ###
my $UpPcentRetransmis = sprintf("%.3f", $UpPcentPerdus + $UpPcentDupliques);


### DUPLICATE ACKS ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "duplicate acks:"`;
my $DownPktsdupacks = substr($valeur[0],23,10);
my $DownPcentdupacks = sprintf("%.3f", 100 * $DownPktsdupacks / $DownPaquetsUtile);
my $UpPktsdupacks = substr($valeur[1],23,10);
my $UpPcentdupacks = sprintf("%.3f", 100 * $UpPktsdupacks / $UpPaquetsUtile);

### TRIPLE DUPACKS ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "triple dupacks:"`;
my $DownPkts3dupacks = substr($valeur[0],23,10);
my $DownPcent3dupacks = sprintf("%.3f", 100 * $DownPkts3dupacks / $DownPaquetsUtile);
my $UpPkts3dupacks = substr($valeur[1],23,10);
my $UpPcent3dupacks = sprintf("%.3f", 100 * $UpPkts3dupacks / $UpPaquetsUtile);

### SEGMENTS ACQUITTES ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep " ack pkts sent:"`;
my $DownSegmentsAck = substr($valeur[0],23,10);
my $UpSegmentsAck = substr($valeur[1],23,10);
if ($DownSegmentsAck == 0) { `/bin/rm $Ramdisk_Dir/vigie.txt`; print "\nERREUR ségments acquittés down = 0\n"; die "===> ségments acquittés down = 0\n"; }
if ($UpSegmentsAck == 0) { `/bin/rm $Ramdisk_Dir/vigie.txt`; print "\nERREUR ségments acquittés up = 0\n"; die "===> ségments acquittés up= 0\n"; }

### PAQUETS ACK ENVOYES ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "segs cum acked:"`;
my $DownPktsAck = substr($valeur[0],23,10);
my $UpPktsAck = substr($valeur[1],23,10);
my $DownPcentPktsAck = sprintf("%.1f", 100 * $DownPktsAck / $DownSegmentsAck);
my $UpPcentPktsAck = sprintf("%.1f", 100 * $UpPktsAck / $UpSegmentsAck);

### MSS MAX ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "max segm size:"`;
$tmp = substr($valeur[0],23,10);
my $DownMss = sprintf("%.0f", $tmp);
$tmp = $tmp + 40; # MTU = MSS + 40 (20 entete TCP et 20 entete IP)
my $DownMtu = sprintf("%.0f", $tmp);
$tmp = substr($valeur[1],23,10);
my $UpMss = sprintf("%.0f", $tmp);
$tmp = $tmp + 40; # MTU = MSS + 40 (20 entete TCP et 20 entete IP)
my $UpMtu = sprintf("%.0f", $tmp);

### RWIN MAX ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "max win adv:"`;
$tmp = substr($valeur[0],62,10);
my $DownRwinMax = sprintf("%.1f", $tmp / 1000);
$tmp = substr($valeur[1],62,10);
my $UpRwinMax = sprintf("%.1f", $tmp / 1000);

### RTT ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "RTT full_sz min:"`;
$tmp = substr($valeur[0],23,10);
my $DownRttFullSzMin = sprintf("%.1f", $tmp);
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "RTT full_sz max:"`;
$tmp = substr($valeur[0],23,10);
my $DownRttFullSzMax = sprintf("%.1f", $tmp);
$tmp = substr($valeur[1],23,10);
my $GigueInterneSrvMax = sprintf("%.1f", $tmp);
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "RTT full_sz avg:"`;
$tmp = substr($valeur[0],23,10);
my $DownRttFullSzAvg = sprintf("%.1f", $tmp);

### TAILLE TOTALE ECHANGEE (INCLUS RETRANSMISSIONS) ###
@valeur = `/bin/cat $Ramdisk_Dir/$Port/$Client_Ip-$Client_id.tcptrace |/bin/grep "actual data bytes:"`;
$tmp = substr($valeur[0],23,10);
my $DownTransTotal = sprintf("%.2f", $tmp / 1000000);
$tmp = substr($valeur[1],23,10);
my $UpTransTotal = sprintf("%.2f", $tmp / 1000000);

### Calcul de la gigue ###
my $DownGigueInf = $DownRttFullSzAvg - $DownRttFullSzMin;
my $DownGigueSup = $DownRttFullSzMax - $DownRttFullSzAvg;
$tmp = ( $DownGigueInf > $DownGigueSup ) ? $DownGigueInf : $DownGigueSup;
my $DownGigueMax = sprintf("%.1f", $tmp);

Auteur Sujet: TCPtrace - analyse du protocole TCP d'une capture wireshark (Lu 7485 fois)

vivien

TCPtrace - analyse du protocole TCP d'une capture wireshark

vivien

TCPtrace - analyse du protocole TCP d'une capture wireshark