La Fibre
Télécom => Logiciels et systèmes d'exploitation => Logiciels => Discussion démarrée par: vivien le 12 août 2014 à 10:59:10
-
Je cherche un outil pour récupérer les "Extended TCP statistics", sous Windows.
Je souhaiterais faire un téléchargement et avoir ces statistiques proposées par Microsoft avec sa pile TCP/IP.
Si c'est l'outil qui fait le téléchargement, cela ne me pose pas de problème.
Voici les stats de "Extended TCP statistics", c'est vraiment complet :
----------------------------------------------------------------------------------------
------------------- Extended statistics for an IPv4 TCP connection -------------------
----------------------------------------------------------------------------------------
Bandwidth estimation:
OutboundBandwidth: 0
InboundBandwidth: 127675824
OutboundInstability: 0
InboundInstability: 3182011
OutboundBandwidthPeaked: No
InboundBandwidthPeaked: Yes
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720195(v=vs.85).aspx
----------------------------------------------------------------------------------------
Fine RTT:
Rtt Var: 7327 µs
Max Rtt: 14654 µs
Min Rtt: 14654 µs
Sum Rtt: 14654 µs
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720196(v=vs.85).aspx
----------------------------------------------------------------------------------------
Data transfert:
DataBytesOut: 237
DataSegsOut: 1
DataBytesIn: 63742140
DataSegsIn: 43659
SegsOut: 21082
SegsIn: 43660
SoftErrors: 0
SoftErrorReason: 0
SndUna: 1559684330
SndNxt: 1559684330
SndMax: 1559684330
ThruBytesAcked: 237
RcvNxt: 2886263480
ThruBytesReceived: 63736300
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee391627(v=vs.85).aspx
----------------------------------------------------------------------------------------
Sender congestion related data:
SndLimTransRwin: 0
SndLimTimeRwin: 0
SndLimBytesRwin: 0
SndLimTransCwnd: 0
SndLimTimeCwnd: 0
SndLimBytesCwnd: 0
SndLimTransSnd: 1
SndLimTimeSnd: 30010
SndLimBytesSnd: 237
SlowStart: 1
CongAvoid: 0
OtherReductions: 0
CurCwnd: 3157
MaxSsCwnd: 3157
MaxCaCwnd: 0
CurSsthresh: 4294967295
MaxSsthresh: 4294967295
MinSsthresh: 4294967295
LimCwnd: 4294967295
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720201(v=vs.85).aspx
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720202(v=vs.85).aspx
----------------------------------------------------------------------------------------
Network path measurement:
FastRetran: 0
Timeouts: 0
SubsequentTimeouts: 0
CurTimeoutCount: 0
AbruptTimeouts: 0
PktsRetrans: 0
BytesRetrans: 0
DupAcksIn: 0
SacksRcvd: 0
SackBlocksRcvd: 0
CongSignals: 0
PreCongSumCwnd: 0
PreCongSumRtt: 0
PostCongSumRtt: 0
PostCongCountRtt: 0
EcnSignals: 0
EceRcvd: 0
SendStall: 0
QuenchRcvd: 0
RetranThresh: 3
SndDupAckEpisodes: 0
SumBytesReordered: 0
NonRecovDa: 0
NonRecovDaEpisodes: 0
Ack After Fr: 0
DsackDups: 0
SampleRtt: 20
SmoothedRtt: 16
RttVar: 20
MaxRtt: 20
MinRtt: 20
SumRtt: 20
CountRtt: 1
CurRto: 300
MaxRto: 300
MinRto: 300
CurMss: 1460
MaxMss: 1460
MinMss: 1460
SpuriousRtoDetections: 0
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720198(v=vs.85).aspx
----------------------------------------------------------------------------------------
Output queuing:
CurRetxQueue: 0
MaxRetxQueue: 237
CurAppWQueue: 0
MaxAppWQueue: 237
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720200(v=vs.85).aspx
----------------------------------------------------------------------------------------
Statistics observed on the remote receiver:
CurRwinRcvd: 15744
MaxRwinRcvd: 15744
MinRwinRcvd: 15744
WinScaleRcvd: 8
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720197(v=vs.85).aspx
----------------------------------------------------------------------------------------
Local receiver:
CurRwinSent: 430700
MaxRwinSent: 776720
MinRwinSent: 118260
LimRwin: 16776960
DupAckEpisodes: 38
DupAcksOut: 1074
CeRcvd: 0
EcnSent: 0
EcnNoncesRcvd: 0
CurReasmQueue: 0
MaxReasmQueue: 102200
CurAppRQueue: 5840
MaxAppRQueue: 27740
WinScaleSent: 0x07
doc: http://msdn.microsoft.com/en-us/library/windows/desktop/ee720199(v=vs.85).aspx
----------------------------------------------------------------------------------------
-
Je suis toujours à la recherche d'un outil capable de sortir ces statistiques sous Windows...
Bandwidth estimation : (TCP_ESTATS_BANDWIDTH_ROD_v0 structure)
- OutboundBandwidth: 0 => The computed outbound bandwidth estimate, in bits per second, for the network path for the TCP connection.
- InboundBandwidth: 127675824 => The computed inbound bandwidth estimate, in bits per second, for the network path for the TCP connection.
- OutboundInstability: 0 => A measure, in bits per second, of the instability of the outbound bandwidth estimate for the network path for the TCP connection.
- InboundInstability: 3182011 => A measure, in bits per second, of the instability of the inbound bandwidth estimate for the network path for the TCP connection.
- OutboundBandwidthPeaked: No => A boolean value that indicates if the computed outbound bandwidth estimate for the network path for the TCP connection has reached its peak value.
- InboundBandwidthPeaked: Yes => A boolean value that indicates if the computed inbound bandwidth estimate for the network path for the TCP connection has reached its peak value.
Fine RTT : (TCP_ESTATS_FINE_RTT_ROD_v0 structure)
- Rtt Var: 7327 µs => The round trip time variation, in microseconds, used in receive window auto-tuning when the TCP extended statistics feature is enabled.
- Max Rtt: 14654 µs => The maximum sampled round trip time, in microseconds.
- Min Rtt: 14654 µs => The minimum sampled round trip time, in microseconds.
- Sum Rtt: 14654 µs => A smoothed value round trip time, in microseconds, computed from all sampled round trip times. The smoothing is a weighted additive function that uses the RttVar member.
Data transfert : (TCP_ESTATS_DATA_ROD_v0 structure)
- DataBytesOut: 237 => The number of octets of data contained in transmitted segments, including retransmitted data. Note that this does not include TCP headers.
- DataSegsOut: 1 => The number of segments sent containing a positive length data segment.
- DataBytesIn: 63742140 => The number of octets contained in received data segments, including retransmitted data. Note that this does not include TCP headers.
- DataSegsIn: 43659 => The number of segments received containing a positive length data segment.
- SegsOut: 21082 => The total number of segments sent.
- SegsIn: 43660 => The total number of segments received.
- SoftErrors: 0 => The number of segments that fail various consistency tests during TCP input processing. Soft errors might cause the segment to be discarded but some do not. Some of these soft errors cause the generation of a TCP acknowledgment, while others are silently discarded.
- SoftErrorReason: 0 => A value that identifies which consistency test most recently failed during TCP input processing. This object is set every time the SoftErrors member is incremented.
- SndUna: 1559684330 => The value of the oldest unacknowledged sequence number. Note that this member is a TCP state variable.
- SndNxt: 1559684330 => The next sequence number to be sent. Note that this member is not monotonic (and thus not a counter), because TCP sometimes retransmits lost data by pulling the member back to the missing data.
- SndMax: 1559684330 => The farthest forward (right most or largest) sequence number to be sent. Note that this will be equal to the SndNxt member except when the SndNxt member is pulled back during recovery.
- ThruBytesAcked: 237 => The number of octets for which cumulative acknowledgments have been received. Note that this will be the sum of changes to the SndNxt member.
- RcvNxt: 2886263480 => The next sequence number to be received. Note that this member is not monotonic (and thus not a counter), because TCP sometimes retransmits lost data by pulling the member back to the missing data.
- ThruBytesReceived: 63736300 => The number of octets for which cumulative acknowledgments have been sent. Note that this will be the sum of changes to the RcvNxtmember.
Sender congestion related data : (TCP_ESTATS_SND_CONG_ROD_v0 et TCP_ESTATS_SND_CONG_ROS_v0 structure)
- SndLimTransRwin: 0 => The number of transitions into the "Receiver Limited" state from either the "Congestion Limited" or "Sender Limited" states. This state is entered whenever TCP transmission stops because the sender has filled the announced receiver window.
- SndLimTimeRwin: 0 => The cumulative time, in milliseconds, spent in the "Receiver Limited" state where TCP transmission stops because the sender has filled the announced receiver window.
- SndLimBytesRwin: 0 => The total number of bytes sent in the "Receiver Limited" state.
- SndLimTransCwnd: 0 => The number of transitions into the "Congestion Limited" state from either the "Receiver Limited" or "Sender Limited" states. This state is entered whenever TCP transmission stops because the sender has reached some limit defined by TCP congestion control (the congestion window, for example) or other algorithms (retransmission timeouts) designed to control network traffic.
- SndLimTimeCwnd: 0 => The cumulative time, in milliseconds, spent in the "Congestion Limited" state. When there is a retransmission timeout, it is counted in this member and not the cumulative time for some other state.
- SndLimBytesCwnd: 0 => The total number of bytes sent in the "Congestion Limited" state.
- SndLimTransSnd: 1 => The number of transitions into the "Sender Limited" state from either the "Receiver Limited" or "Congestion Limited" states. This state is entered whenever TCP transmission stops due to some sender limit such as running out of application data or other resources and the Karn algorithm. When TCP stops sending data for any reason, which cannot be classified as "Receiver Limited" or "Congestion Limited", it is treated as "Sender Limited".
- SndLimTimeSnd: 30010 => The cumulative time, in milliseconds, spent in the "Sender Limited" state.
- SndLimBytesSnd: 237 => The total number of bytes sent in the "Sender Limited" state.
- SlowStart: 1 => The number of times the congestion window has been increased by the "Slow Start" algorithm.
- CongAvoid: 0 => The number of times the congestion window has been increased by the "Congestion Avoidance" algorithm.
- OtherReductions: 0 => The number of congestion window reductions made as a result of anything other than congestion control algorithms other than "Slow Start" and "Congestion Avoidance" algorithms.
- CurCwnd: 3157 => The size, in bytes, of the current congestion window.
- MaxSsCwnd: 3157 => The maximum size, in bytes, of the congestion window size used during "Slow Start."
- MaxCaCwnd: 0 => The maximum size, in bytes, of the congestion window used during "Congestion Avoidance."
- CurSsthresh: 4294967295 => The current size, in bytes, of the slow start threshold.
- MaxSsthresh: 4294967295 => The maximum size, in bytes, of the slow start threshold, excluding the initial value.
- MinSsthresh: 4294967295 => The minimum size, in bytes, of the slow start threshold.
- LimCwnd: 4294967295 => The maximum size, in bytes, of the congestion window that may be used.
Network path measurement : (TCP_ESTATS_PATH_ROD_v0 structure)
- FastRetran: 0 => The number of invocations of the Fast Retransmit algorithm.
- Timeouts: 0 => The number of times the retransmit timeout has expired when the retransmission timer backoff multiplier is equal to one.
- SubsequentTimeouts: 0 => The number of times the retransmit timeout has expired after the retransmission timer has been doubled.
- CurTimeoutCount: 0 => The current number of times the retransmit timeout has expired without receiving an acknowledgment for new data. The CurTimeoutCount member is reset to zero when new data is acknowledged and incremented for each invocation of Section 5.5 of RFC 2988.
- AbruptTimeouts: 0 => The number of timeouts that occurred without any immediately preceding duplicate acknowledgments or other indications of congestion. Abrupt timeouts indicate that the path lost an entire window of data or acknowledgments. Timeouts that are preceded by duplicate acknowledgments or other congestion signals (Explicit Congestion Notification, for example) are not counted as abrupt, and might have been avoided by a more sophisticated Fast Retransmit algorithm.
- PktsRetrans: 0 => The number of segments transmitted containing at least some retransmitted data.
- BytesRetrans: 0 => The number of bytes retransmitted.
- DupAcksIn: 0 => The number of duplicate ACKs received.
- SacksRcvd: 0 => The number of Selective Acknowledgement (SACK) options received.
- SackBlocksRcvd: 0 => The number of SACK blocks received (within SACK options).
- CongSignals: 0 => The number of multiplicative downward congestion window adjustments due to all forms of congestion signals, including Fast Retransmit, Explicit Congestion Notification (ECN), and timeouts. This member summarizes all events that invoke the Multiplicative Decrease (MD) portion of Additive Increase Multiplicative Decrease (AIMD) congestion control, and as such is the best indicator of how a congestion windows is being affected by congestion. Note that retransmission timeouts multiplicatively reduce the window implicitly by setting the slow start threshold size, and are included in the value stored in the CongSignals member. In order to minimize spurious congestion indications due to out-of-order segments, the CongSignals member is incremented in association with the Fast Retransmit algorithm.
- PreCongSumCwnd: 0 => The sum of the values of the congestion window, in bytes, captured each time a congestion signal is received. This member is updated each time the CongSignals member is incremented, such that the change in the PreCongSumCwnd member divided by the change in the CongSignals member is the average window (over some interval) just prior to a congestion signal.
- PreCongSumRtt: 0 => The sum, in milliseconds, of the last sample of the network round-trip-time (RTT) prior to the received congestion signals. The last sample of the RTT is stored in the SampleRtt member. The PreCongSumRtt member is updated each time the CongSignals member is incremented, such that the change in the PreCongSumRtt divided by the change in the CongSignals member is the average RTT (over some interval) just prior to a congestion signal.
- PostCongSumRtt: 0 => The sum, in milliseconds, of the first sample of the network RTT (stored in the SampleRtt member) following each congestion signal. The change in the PostCongSumRtt member divided by the change in the PostCongCountRtt member is the average RTT (over some interval) just after a congestion signal.
- PostCongCountRtt: 0 => The number of RTT samples, in bytes, included in the PostCongSumRtt member. The change in the PostCongSumRtt member divided by the change in the PostCongCountRtt member is the average RTT (over some interval) just after a congestion signal.
- EcnSignals: 0 => The number of congestion signals delivered to the TCP sender via ECN. This is typically the number of segments bearing Echo Congestion Experienced (ECE) bits, but also includes segments failing the ECN nonce check or other explicit congestion signals.
- EceRcvd: 0 => The number of segments received with IP headers bearing Congestion Experienced (CE) markings.
- SendStall: 0 => The number of interface stalls or other sender local resource limitations that are treated as congestion signals.
- QuenchRcvd: 0 => Reserved for future use. This member is always set to zero.
- RetranThresh: 3 => The number of duplicate acknowledgments required to trigger Fast Retransmit. Note that although this is constant in traditional Reno TCP implementations, it is adaptive in many newer TCP implementations.
- SndDupAckEpisodes: 0 => The number of Duplicate Acks Sent when prior Ack was not duplicate. This is the number of times that a contiguous series of duplicate acknowledgments have been sent. This is an indication of the number of data segments lost or reordered on the path from the remote TCP endpoint to the near TCP endpoint.
- SumBytesReordered: 0 => The sum of the amounts SND.UNA advances on the acknowledgment which ends a dup-ack episode without a retransmission. Note the change in the SumBytesReordered member divided by the change in the NonRecovDaEpisodes member is an estimate of the average reordering distance, over some interval.
- NonRecovDa: 0 => The number of duplicate acks (or SACKS) that did not trigger a Fast Retransmit because ACK advanced prior to the number of duplicate acknowledgments reaching the RetranThresh. Note that the change in the NonRecovDa member divided by the change in the NonRecovDaEpisodes member is an estimate of the average reordering distance in segments over some interval.
- NonRecovDaEpisodes: 0 => The number of duplicate acknowledgment episodes that did not trigger a Fast Retransmit because ACK advanced prior to the number of duplicate acknowledgments reaching the RetranThresh.
- Ack After Fr: 0 => Reserved for future use. This member is always set to zero.
- DsackDups: 0 => The number of duplicate segments reported to the local host by D-SACK blocks.
- SampleRtt: 20 => The most recent raw network round trip time measurement, in milliseconds, used in calculation of the retransmission timer (RTO).
- SmoothedRtt: 16 => The smoothed round trip time, in milliseconds, used in calculation of the RTO.
- RttVar: 20 => The round trip time variation, in milliseconds, used in calculation of the RTO.
- MaxRtt: 20 => The maximum sampled round trip time in milliseconds.
- MinRtt: 20 => The minimum sampled round trip time in milliseconds.
- SumRtt: 20 => The sum of all sampled round trip times in milliseconds. Note that the change in the SumRtt member divided by the change in the CountRtt member is the mean RTT, uniformly averaged over an enter interval.
- CountRtt: 1 => The number of round trip time samples included in the SumRtt member.
- CurRto: 300 => The current value, in milliseconds, of the retransmit timer.
- MaxRto: 300 => The maximum value, in milliseconds, of the retransmit timer.
- MinRto: 300 => The minimum value, in milliseconds, of the retransmit timer.
- CurMss: 1460 => The current maximum segment size (MSS), in bytes.
- MaxMss: 1460 => The maximum MSS, in bytes.
- MinMss: 1460 => The minimum MSS, in bytes.
- SpuriousRtoDetections: 0 => The number of acknowledgments reporting segments that have already been retransmitted due to a Retransmission Timeout.
Output queuing : (TCP_ESTATS_SEND_BUFF_ROD_v0 structure)
- CurRetxQueue: 0 => The current number of bytes of data occupying the retransmit queue.
- MaxRetxQueue: 237 => The maximum number of bytes of data occupying the retransmit queue.
- CurAppWQueue: 0 => The current number of bytes of application data buffered by TCP, pending the first transmission (to the left of SND.NXT or SndMax). This data will generally be transmitted (and SND.NXT advanced to the left) as soon as there is an available congestion window or receiver window. This is the amount of data readily available for transmission, without scheduling the application. TCP performance may suffer if there is insufficient queued write data.
- MaxAppWQueue: 237 => The maximum number of bytes of application data buffered by TCP, pending the first transmission. This is the maximum value of the CurAppWQueue member. The MaxAppWQueue and CurAppWQueue members can be used to determine if insufficient queued data is steady state (suggesting insufficient queue space) or transient (suggesting insufficient application performance or excessive CPU load or scheduler latency).
Statistics observed on the remote receiver : (TCP_ESTATS_REC_ROD_v0 structure)
- CurRwinRcvd: 15744 => The most recent window advertisement, in bytes, received from the remote receiver.
- MaxRwinRcvd: 15744 => The maximum window advertisement, in bytes, received from the remote receiver.
- MinRwinRcvd: 15744 => The minimum window advertisement, in bytes, received from the remote receiver.
- WinScaleRcvd: 8 => The value of the received window scale option if one was received from the remote receiver; otherwise, a value of -1. Note that if both the WinScaleSent member of the TCP_ESTATS_REC_ROD_v0 structure and the WinScaleRcvd member are not -1, then Snd.Wind.Scale will be the same as this value and used to scale receiver window announcements from the remote host to the local host.
Local receiver : (TCP_ESTATS_REC_ROD_v0 structure)
- CurRwinSent: 430700 => The most recent window advertisement, in bytes, that has been sent.
- MaxRwinSent: 776720 => The maximum window advertisement, in bytes, that has been sent.
- MinRwinSent: 118260 => The minimum window advertisement, in bytes, that has been sent.
- LimRwin: 16776960 => The maximum window advertisement, in bytes, that may be sent.
- DupAckEpisodes: 38 => The number of Duplicate Acks Sent when prior Ack was not duplicate. This is the number of times that a contiguous series of duplicate acknowledgments have been sent. This is an indication of the number of data segments lost or reordered on the path from the remote TCP endpoint to the near TCP endpoint.
- DupAcksOut: 1074 => The number of duplicate ACKs sent. The ratio of the change in the DupAcksOut member to the change in the DupAckEpisodes member is an indication of reorder or recovery distance over some interval.
- CeRcvd: 0 => The number of segments received with IP headers bearing Congestion Experienced (CE) markings.
- EcnSent: 0 => Reserved for future use. This member is always set to zero.
- EcnNoncesRcvd: 0 => Reserved for future use. This member is always set to zero.
- CurReasmQueue: 0 => The current number of bytes of sequence space spanned by the reassembly queue. This is generally the difference between rcv.nxt and the sequence number of the right most edge of the reassembly queue.
- MaxReasmQueue: 102200 => The maximum number of bytes of sequence space spanned by the reassembly queue. This is the maximum value of the CurReasmQueue member.
- CurAppRQueue: 5840 => The current number of bytes of application data that has been acknowledged by TCP but not yet delivered to the application.
- MaxAppRQueue: 27740 => The maximum number of bytes of application data that has been acknowledged by TCP but not yet delivered to the application.
- WinScaleSent: 0x07 => The value of the transmitted window scale option if one was sent; otherwise, a value of -1. Note that if both the WinScaleSent member and the WinScaleRcvd member of the TCP_ESTATS_OBS_REC_ROD_v0 structure are not -1, then Rcv.Wind.Scale will be the same as this value and used to scale receiver window announcements from the local host to the remote host.
-
Le bon vieux netstat ne fonctionne pas sous windows ?
-
Là, c'est un peu plus évolué...
Au passage, si vous savez comment récupérer ca sous Linux... J'arrive a récupérer une partie des informations mais il faut réaliser une capture Wireshark et utiliser tshark pour lire les informations de la capture...
-
Ben, j'ai ça:
4% [robert:~]netstat -s
Ip:
9737095 total packets received
65 with invalid addresses
0 forwarded
0 incoming packets discarded
9710939 incoming packets delivered
5796797 requests sent out
1 dropped because of missing route
Icmp:
29838 ICMP messages received
32 input ICMP message failed.
Histogramme d'entrée ICMP
destination unreachable: 112
timeout in transit: 24307
echo requests: 2616
echo replies: 2803
37225 ICMP messages sent
0 ICMP messages failed
Histogramme de sortie ICMP
destination unreachable: 250
echo request: 494
echo replies: 2616
IcmpMsg:
InType0: 2803
InType3: 112
InType8: 2616
InType11: 24307
OutType0: 2616
OutType3: 250
OutType8: 494
OutType69: 33865
Tcp:
107155 active connections openings
474 passive connection openings
239 failed connection attempts
73753 connection resets received
27 connections established
9637597 segments received
5811741 segments send out
3025 segments retransmited
1579 bad segments received.
91693 resets sent
Udp:
26192 packets received
245 packets to unknown port received.
0 packet receive errors
20606 packets sent
UdpLite:
TcpExt:
8979 TCP sockets finished time wait in fast timer
1 packets rejects in established connections because of timestamp
134423 delayed acks sent
57 delayed acks further delayed because of locked socket
Quick ack mode was activated 3619 times
3351 packets directly queued to recvmsg prequeue.
342 bytes directly in process context from backlog
275993 bytes directly received in process context from prequeue
6496308 packet headers predicted
1289 packets header predicted and directly queued to user
267118 acknowledgments not containing data payload received
1039570 predicted acknowledgments
94 times recovered from packet loss by selective acknowledgements
11 congestion windows recovered without slow start by DSACK
262 congestion windows recovered without slow start after partial ack
TCPLostRetransmit: 2
14 timeouts after SACK recovery
6 timeouts in loss state
151 fast retransmits
22 forward retransmits
2 retransmits in slow start
1062 other TCP timeouts
TCPLossProbes: 1054
TCPLossProbeRecovery: 454
1 SACK retransmits failed
3527 DSACKs sent for old packets
2 DSACKs sent for out of order packets
391 DSACKs received
1 DSACKs for out of order packets received
2672 connections reset due to unexpected data
73481 connections reset due to early user close
82 connections aborted due to timeout
TCPDSACKIgnoredNoUndo: 254
TCPSpuriousRTOs: 1
TCPSackShifted: 83
TCPSackMerged: 92
TCPSackShiftFallback: 1461
TCPDeferAcceptDrop: 201
TCPRcvCoalesce: 3973293
TCPOFOQueue: 146325
TCPOFOMerge: 11
TCPChallengeACK: 1581
TCPSYNChallenge: 1581
TCPSpuriousRtxHostQueues: 2
TCPAutoCorking: 60748
IpExt:
InMcastPkts: 33969
OutMcastPkts: 1992
InBcastPkts: 6987
OutBcastPkts: 11
InOctets: 9901588939
OutOctets: 813811244
InMcastOctets: 1227460
OutMcastOctets: 63744
InBcastOctets: 2793293
OutBcastOctets: 803
InNoECTPkts: 10034526
InECT0Pkts: 18974
-
Mon but, c'est de récupérer ca pour un transfert précis (un wget)
-
c'est l'API C++ IP Helper de Windows non? donc faut développer un truc en C++ ou en trouver un...j'en connais pas.
Y'a a peu pres la meme en API en .Net mais j'ai pas fouillé plus: http://msdn.microsoft.com/en-us/library/System.Net.NetworkInformation(v=vs.110).aspx (http://msdn.microsoft.com/en-us/library/System.Net.NetworkInformation(v=vs.110).aspx)
si c'est suffisant, les API .Net peuvent s'utiliser en ligne de commande avec Powershell, par exemple, la ligne de commande (sous PS) :
[System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties().GetTcpIPv4Statistics()
va afficher les stats TCP v4.
-
A regarder de plus pres l'API .Net a moins de choses... typique de MS ca :-\
En regardant la doc la fonction GetPerTcpConnectionEStats il y a un code de demo. En le compilant ca donne un .exe qui fait une connexion local sur lui meme en tcp, genere un peu de trafic et ensuite affiche les stats suivantes:
Dumping Estats for server socket:
<lignes de stats>
Dumping Estats for client connect socket:
<lignes de stats>
Dumping Estats for server socket after client sends data:
<lignes de stats>
Dumping Estats for client socket after client sends data:
<lignes de stats>
pius la meme chose a nouveau en IPv6
avec par block de <lignes de stats>:
Syn Opts
Active Open: No
Mss Received: 65495
Mss Sent 0
Data
Bytes Out: 0
Segs Out: 0
Bytes In: 0
Segs In: 0
Segs Out: 0
Segs In: 0
Soft Errors: 0
Soft Error Reason: 0
Snd Una: 3771097015
Snd Nxt: 3771097015
Snd Max: 3771097015
Bytes Acked: 0
Rcv Nxt: 3558549856
Bytes Rcv: 0
Snd Cong
Trans Rwin: 0
Lim Time Rwin: 0
Lim Bytes Rwin: 0
Lim Trans Cwnd: 0
Lim Time Cwnd: 0
Lim Bytes Cwnd: 0
Lim Trans Snd: 1
Lim Time Snd: 0
Lim Bytes Snd: 0
Slow Start: 0
Cong Avoid: 0
Other Reductions: 0
Cur Cwnd: 2920
Max Ss Cwnd: 2920
Max Ca Cwnd: 0
Cur Ss Thresh: 0xffffffff (4294967295)
Max Ss Thresh: 0xffffffff (4294967295)
Min Ss Thresh: 0xffffffff (4294967295)
Lim Cwnd: 0xffffffff (4294967295)
Path
Fast Retran: 0
Timeouts: 0
Subsequent Timeouts: 0
Cur Timeout Count: 0
Abrupt Timeouts: 0
Pkts Retrans: 0
Bytes Retrans: 0
Dup Acks In: 0
SacksRcvd: 0
Sack Blocks Rcvd: 0
Cong Signals: 0
Pre Cong Sum Cwnd: 0
Pre Cong Sum Rtt: 0
Post Cong Sum Rtt: 0
Post Cong Count Rtt: 0
Ecn Signals: 0
Ece Rcvd: 0
Send Stall: 0
Quench Rcvd: 0
Retran Thresh: 3
Snd Dup Ack Episodes: 0
Sum Bytes Reordered: 0
Non Recov Da: 0
Non Recov Da Episodes: 0
Ack After Fr: 0
Dsack Dups: 0
Sample Rtt: 0xffffffff (4294967295)
Smoothed Rtt: 0
Rtt Var: 0
Max Rtt: 0
Min Rtt: 0xffffffff (4294967295)
Sum Rtt: 0
Count Rtt: 0
Cur Rto: 300
Max Rto: 300
Min Rto: 300
Cur Mss: 1460
Max Mss: 1460
Min Mss: 1460
Spurious Rto: 0
Send Buff
Cur Retx Queue: 0
Max Retx Queue: 0
Cur App W Queue: 0
Max App W Queue: 0
Rec
Cur Rwin Sent: 0x2000 (8192)
Max Rwin Sent: 0x2000 (8192)
Min Rwin Sent: 0x2000 (8192)
Lim Rwin: 0xffff00 (16776960)
Dup Acks: 0
Dup Acks Out: 0
Ce Rcvd: 0
Ecn Send: 0
Ecn Nonces Rcvd: 0
Cur Reasm Queue: 0
Max Reasm Queue: 0
Cur App R Queue: 0
Max App R Queue: 0
Win Scale Sent: 0x08
Obs Rec
Cur Rwin Rcvd: 0x2000 (8192)
Max Rwin Rcvd: 0x2000 (8192)
Min Rwin Rcvd: 0xffffffff (4294967295)
Win Scale Rcvd: 0x8 (8)
Bandwidth
Outbound Bandwidth: 0
Inbound Bandwidth: 0
Outbound Instability: 0
Inbound Instability: 0
Outbound Bandwidth Peaked: No
Inbound Bandwidth Peaked: No
Fine RTT
Rtt Var: 0
Max Rtt: 0
Min Rtt: 0xffffffff (4294967295)
Sum Rtt: 0
(ps: le code ne marche pas correctement car ils ont oublié un truc mais l'idée est la :)).
En fait ca affiche toutes les valeurs dispos venant des stats suivantes:
TcpConnectionEstatsSynOpts
TcpConnectionEstatsData
TcpConnectionEstatsSndCong
TcpConnectionEstatsPath
TcpConnectionEstatsSendBuff
TcpConnectionEstatsRec
TcpConnectionEstatsObsRec
TcpConnectionEstatsBandwidth
TcpConnectionEstatsFineRtt
TcpConnectionEstatsMaximum
Donc exactement ce que tu cherches.
MAIS ces API marchent que par connexion donc doivent être intégrer directement dans le programme qui génère le trafic, donc par exemple prendre le code source de wget et le modifier pour ajouter la collection de ces stats. En effet, il faut explicitement appeler la fonction SetPerTcpConnectionEStats pour activer la collecte des 'extended stats' et ensuite recuper les valeurs avec la fonction GetPerTcpConnectionEStats quand on le souhaite (début, fin, toutes les X secondes, etc):
The SetPerTcpConnectionEStats function is defined on Windows Vista and later.
The SetPerTcpConnectionEStats function is used to enable or disable extended statistics on an IPv4 TCP connection passed in the Row parameter. Extended statistics on a TCP connection are disabled by default. The SetPerTcpConnectionEStats function is used to set the value of a member in the read/write information for extended statistics for an IPv4 TCP connection. The type and format of the structure to be set is specified by the EstatsType parameter. The Rw parameter contains a pointer to the structure being passed. All members in the structure pointed to by Rw parameter must be specified.
Éventuellement, mais je n'ai pas vérifier en pratique, il serait possible de faire un programme qui lance une autre programme et suit chacune de ses connections TCP avec ces API...ca ne me parait pas trop sorcier à faire...
Comme indiqué, les extented stats ne sont dispo qu'a partir de Vista donc ca ne marchera pas sous XP.
Ca n'est pas vraiment nouveau donc et c'est curieux qu'on ne trouve pas sur Internet un outil qui fait ca deja.
Je n'ai pas trop de temps ces temps ci mais c'est un sujet qui m’intéresse et qui est connexe a mon projet de speedtest donc si tu ne trouves rien d'ici 2 semaines, on peut envisager de développer un outil comme ca. Ca ne me parait pas compliqué du tout, suffit de 'choper' les connexions TCP qu'on veut suivre et utiliser l'API.
A moins qu'un autre dev C/C++Windows traine dans le coin et n'a rien à faire en ce moment :p
-
Ok. Je pensais qu'il existait un outil Microsoft pour télécharger un fichier et qui sortait ces stats.
Pour un outil grand public, il faut mieux se concentrer sur ce qu'il est possible de faire avec un navigateur sans extension.
-
Sous Windows ou Linux vous ne connaissez pas un outil type curl ou wget mais qui affiche les paquets retransmis ?
curl donne de nombreuses statistiques sur le découpage du temps entre la résolution DNS, le temps de faire le [SYN / SYN-ACK] le temps entre le wget et le 1er paquet et le temps de transfert effectif.
Maintenant pour comprendre pourquoi le débit est mauvais, il est crucial d'avoir des informations sur le nombre de paquets retransmis ou le nombre de "DupAckEpisodes"...
-
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 (http://www.microsoft.com/en-us/download/details.aspx?id=24826) (1,3 Go) et installé uniquement les 'tools'.
L'outil s'appele tcpanalyzer.exe
Le probleme c'est que c'est vieux et abandonné. Sur certains de mes Windows 7 les textes sont illisibles...
Mais quand ca marche, ca affiche bien la liste de connexions tcp en cours et on peut cliquer sur une pour activer et suivre les 'extended statistics'. Dommage le source n'est pas fourni , on aurait pu le mettre a jour.
Ca marche mieux sur XP et Server 2008 j'imagine.
Autre défaut : y'a un delai avant qu'une nouvelle connexion s'affiche donc on loupe son début.
L'outils 'a jour' chez MS c'est Microsoft Message Analyzer (http://www.microsoft.com/en-ca/download/details.aspx?id=40308). Ca permet des traces/captures et des analyses hierachisées, par exemple au niveau HTTP, ou au niveau TCP , ou IP donc sur un wget/curl de 5Go par exemple a tres peu de lignes si on est en mode HTTP (ils appelent ca des Viewpoints). En plus y'a des alertes et flags si quelque chose d'anormal est détecté.
Par exemple la capture d'un curl de 5Go:
(http://i.imgur.com/QTkQz3u.png?1)
pour chaque ligne HTTP on peut 'drill down' en cliquant sur le '+ rouge' au début pour voir les paquets TCP en dessous.
Ce produit est assez complexe et a des 'modules', peut-etre on peut y trouver les extended statistics mais faut chercher.
Depuis que j'ai résolue mon probleme de limite de débit par connexion TCP avec Windows 7 je ne cherche plus trop ce genre d'outils.
J'ai détaillé la solution dans ce topic (https://lafibre.info/sfr-debit/300gbps-sur-speedtest-mais-12mosec-en-dl/msg165225/#msg165225).
Je ne sais pas si c'est cela que tu recherches ou si c'est pour un autre souci avec Windows.
-
Sous Windows j'ai aussi trouvé TCP Segment Retransmission Viewer
C'est open source : http://sourceforge.net/projects/tcpsegmentretransmissionviewer/ (http://sourceforge.net/projects/tcpsegmentretransmissionviewer/)
Sous linux, j'ai trouvé nuttcp qui est mentionné sur le blog de Stéphane Bortzmeyer (http://www.bortzmeyer.org/6349.html) et qui permet visiblement de voir les paquets retransmis. Le logiciel est dispo sous Ubuntu (sudo apt install nuttcp)
Je vais réaliser des tests.
-
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 (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 (http://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);
}
-
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
-
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 (http://www.microsoft.com/en-us/download/details.aspx?id=24826) (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/ (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 (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.
-
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 (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 (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 :)
-
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)