Note: Graph 1 is the HTTP total traffic, displayed in the form of packets/tick, with a time interval of 1 second. If this interval is long, it may indicate some type of network delay (message loss, congestion, etc.).Īpply some of the above filters in the capture: _rtt：Measure the captured TCP packet with the corresponding ACK. If you see a continuous lower than TCP window size, it may mean that the message is lost or other problems affecting throughput on the path. The number of unacknowledged bytes cannot exceed your TCP window size (defined in the initial 3 TCP handshakes), in order to maximize throughput you want to get as close as possible to the TCP window size. _in_flight：The number of bytes not acknowledged on the network at a certain point in time. This may indicate that the receiving end is already overwhelmed. If you see that the window size drops to zero, this means that the sender has logged out and waits for the receiver to acknowledge all transmitted data. _update：Graphicalize the TCP window size during transmission. This usually means slow application performance and/or loss of user messages. If the number of retransmissions is small, it is still normal, and multiple transmissions may be problematic. ：Show all retransmissions in the capture package. A cool ACK is a sign of high latency between TCP endpoints. _ack：Displays messages that have been acknowledged more than once. Message loss can result in duplicate ACKs, which can result in retransmissions. _segment: Indicates that a discontinuous serial number has been seen in the packet capture. There are some filters for troubleshooting network latency/application issues that are very useful: The ping information seen in the CLI is as follows: This is due to a reply drop caused by packet loss.
This means that some reply is not received. You can see that there is a gap in the middle of the red pulse line (icmp type=0 – ICMP Reply), and the ICMP request remains continuous throughout the picture. Normally there will be a continuous reply for each echo request. Some gaps in the red ICMP traffic can be seen in the figure for further analysis.Ĭreate two graphics, one showing ICMP Echo (Type=8) and one showing ICMP Reply (Type=0). You can see that Graph 1 uses "http" Graph 2 to use "icmp" in the filter condition. Here create two different graphs, one HTTP and one ICMP. This problem is very well found on the graph, but may not be as obvious when looking at the message list.Ī filter can be applied to each graphic. If you see traffic in some places drop to zero, it could be a problem. From this picture we can see that the peak rate is around 300kbps. Change the Y-axis to bits/tick so that you can see the flow per second. This display under default conditions is not very useful in most troubleshooting. Note: The filter condition is empty and this graph shows all traffic. This packet capture is a case where the HTTP download encounters a message loss. To see it further, click on any point in the graph to see the details of the message.įor ease of explanation, click on the sample message package or click on Statistics - IO Graphs with your own wireshark. This is a basic application that is useful for viewing peaks/troughs in traffic. If you want to view the number of bits per second or the number of bytes, click on "Unit" and select the content you want to view in the "Y Axis" drop-down list. The default X-axis time interval is 1 second, and the Y-axis is the number of messages per interval.
The basic Wireshark IO graph shows the overall traffic in the capture file, usually in per second (number of messages or bytes). One-stop learning Wireshark (three): application Wireshark IO Graphs analyzes data streams
0 kommentar(er)
