One-stop learning Wireshark (III): Using Wireshark I/O graphics tools to analyze data streams | kuai.com

Great ~~

BasicIo graphs:

Io graphs is a very useful tool. The basic Wireshark Io graph displays the overall traffic in the packet capture file, usually in the unit of per second (number of packets or bytes ). By default, the x-axis interval is 1 second, And the y-axis is the number of packets at each time interval. To view the number of bits or bytes per second, click "unit" and select the desired content from the "Y axis" drop-down list. This is a basic application that helps you view traffic peaks and troughs. Click any point in the graph to view the Message Details.

For ease of explanation, click the sample packet or use your Wireshark to click statistics-io graphs. This packet capture is caused by packet loss during HTTP download.

Note: The filter condition is empty. This chart displays all traffic.

The display in this default condition is not very useful in most troubleshooting. Change the Y axis to bits/tick to see the traffic per second. From this figure, we can see that the peak speed is about kbps. If you see that traffic drops to zero in some places, it may be a problem. This problem is well found in the figure, but it may not be so obvious when reading the report list.

Filter:

A filter condition can be applied to each graph. Here we create two different graphs, one HTTP and one ICMP. In the filter condition, graph 1 uses "HTTP" Graph 2 and "ICMP ". The figure shows some gaps in the red ICMP traffic for further analysis.

Create two images, one for ICMP echo (type = 8) and the other for ICMP reply (type = 0 ). Under normal circumstances, each echo request will have a continuous reply. Here the situation is:

We can see that there is a gap between the red pulse line (ICMP type = 0-ICMP reply), while the ICMP request in the whole figure remains continuous. This means that some reply do not receive the message. This is the reply drop caused by packet loss. The Ping information shown in CLI is as follows:

Common Error Filtering Conditions:

Some filtering conditions are useful for troubleshooting network latency/application problems:

TCP. analysis. lost_segment: Indicates that the serial number is not consecutive in the captured packet. Packet loss may cause duplicate ACK, which may cause retransmission.

TCP. analysis. duplicate_ack:Displays messages that have been confirmed more than once. Repeated ack with great coolness is a sign of high latency between TCP endpoints.

TCP. analysis. retransmission:Displays all retransmissions In the captured packet. If the number of retransmissions is small, it is normal that too many retransmissions may be faulty. This usually means slow application performance and/or loss of user packets.

TCP. analysis. window_update:Graphical display of the TCP window size during transmission. If the window size drops to zero, it means that the sender has exited and waits for the receiver to confirm that all data has been transferred. This may indicate that the acceptor is overwhelmed.

TCP. analysis. bytes_in_flight:The number of unconfirmed bytes on the network at a certain time point. The number of unconfirmed bytes cannot exceed your TCP window size (defined in the first three TCP handshakes). To maximize the throughput, you want to get as close as possible to the TCP window size. If the number of consecutive windows is lower than the TCP window size, it may cause packet loss or other problems affecting the throughput in the path.

TCP. analysis. ack_rtt:Measure the captured TCP packets and corresponding ACK packets. If the time interval is long, it may indicate some type of network latency (packet loss, congestion, and so on ).

Apply the following filter conditions to capture packets:

Note: Graph 1 is the overall HTTP traffic, in the format of packets/tick. The interval is 1 second. Graph 2 is a TCP packet loss segment. Graph 3 is a TCP duplicate ack. Graph 4 is a TCP retransmission.

From this figure, we can see that compared to the overall HTTP traffic, there are a lot of retransmission and repeated ack. In this figure, we can see the time when these events occur and the proportion of the total traffic.

Function:

Io graphs has six available functions: Sum, Min, AVG, Max, count, and load.

Min (), AVG (), max ()

First, let's take a look at the minimum, average, and maximum time between frames, which is very useful for viewing the latency between frames/packets. We can combine these functionsFrame. time_delta"The filtering conditions clearly show the frame latency and make the round-trip latency more obvious. If the packet capture file contains multiple sessions between different hosts and only wants to know one pair,Frame. time_delta"Combined with source and target host conditions such as" ip. ADDR = x. x & IP. ADDR = Y. Y ". As shown in:

We have done the following steps:

• Set the Y axis to "advanced" to make the caculation field visible. If you do not do this step, you will not be able to see the computing options.
• The X axis time interval is 1 second, so each bar chart represents the calculation result of one second interval.
• Filter out the HTTP sessions of two specific IP addresses and use the following conditions: "(IP. ADDR = 192.168.1.4 & IP. ADDR = 128.173.87.169) & HTTP ".
• Use three different graphs to calculate min (), AVG (), and Max () respectively ().
• Apply the condition "frame. time_delta" to each calculation result and set the style to "fbar". The best effect is displayed.

It can be seen that the max frame. delta_time of the data stream reaches 106th seconds in 0.7 seconds, which is a serious delay and causes packet loss. If you want to study it in depth, you only need to click this in the figure to jump to the corresponding frame. It corresponds to 1,003rd packets in the packet capture file in this example. If you see that the average latency between frames is relatively low, but suddenly a certain latency is very long, you can click this frame to see what happened at this time point.

Count ()

This function calculates the number of events that occurred during the interval and is useful when viewing TCP analysis identifiers, such as retransmission. The example is as follows:

Sum ()

This function calculates the cumulative value of the event. There are two common cases: capture the TCP data volume and check the TCP serial number. Let's take a look at the first example of TCP length. Create two diagrams. One uses the Client IP address 192.168.1.4 as the source, and the other uses the Client IP address as the destination address. For each graph, we combine the sum () function with the TCP. Len filter condition. Split it into two different graphs and we can see the data volume moving in a single direction.

From the chart, we can see that the data volume sent to the client (IP. dst = 192.168.1.4 filtering condition) is higher than the data volume from the client. In red. Black bars show data from the client to the server, with a relatively small amount of data. This makes sense, because the client only requests a file and sends confirmation data after receiving it, while the server sends a large file. It is very important that, if you switch the order of the graph, use the Client IP address as the destination address of Figure 1 and the client IP address as the source address of Figure 2, when fbar is used, the correct data display may not be displayed. The lower the image number, the higher the image number.

Now let's take a look at the TCP serial number of the same packet loss and delay.

You can see several peaks and drops in the figure, indicating that there is a problem with TCP transmission. Compared with normal TCP Packets:

In this figure, we can see that the TCP serial number increases steadily, indicating that the transmission is stable and there is no excessive retransmission or packet loss.

One-stop learning Wireshark (I): basic usage of Wireshark

One-stop learning Wireshark (2): Applying Wireshark to observe basic network protocols

From Weizhi note (wiz)