📜 ⬆️ ⬇️

How to prepare TCP



When someone or something becomes bad, something more is needed than just a statement of this fact.

The first is to diagnose the problem, determine the cause of the failure.
Take and measure pressure, make palpation, check engine oil level, and so on and so forth.

What if problems arose when transferring data to the Internet / Intranet network?
Here, apparently, will require special diagnostic tools.
In particular, tools that allow statistical analysis of a large amount of data will be useful.
There are many different tools.
Some of them can be found in such a wonderful program like Wireshark.
The Statistics menu of Wireshark provides a rich set of functionality.
At the same time, the results can be presented not only in general, but also in graphical form.
')
Just about the graphic form and I want to talk.
Tell about a set of five graphs of TCP StreamGraph statistics.
Allow you to easily and efficiently analyze and diagnose TCP connections.

But before we start talking about graphs, for a better understanding of them, let’s look at the basics of TCP theory.

The minimum required for a general understanding of TCP StreamGraph





Below is a picture of a special case of TCP data exchange.
Should be considered as a simplified version.

In the example, the numbering of the segments starts from one.
Although in reality it is not so.
However, the same shows Wireshark with default settings.

The sender sends two segments (Seq = 1 and Seq = 6), each containing five bytes of data.
The receiver responds that all bytes to 10 are received successfully and the next 11th segment is expected (Ack = 11).
The sender transmits two more (Seq = 11 and Seq = 16), one of which is lost in the network (Seq = 11).
The recipient states that a gap has appeared in the stream of received data.
Reports that only 10 bytes have been continuously received since the first byte and it is still waiting for the 11th segment (Ack = 11).
However, at the same time in the confirming segment indicates the SACK ( Selective Acknowledgment, selective acknowledgment) block, with a range of bytes received after the break. Thanks to SACK, the sender will re-transmit only the missing segment (Seq = 11). Without SACK, you would need to repeat Seq = 16 too. The use of SACK must be supported by both parties to the exchange.



Now consider the process of transferring data in a TCP connection via TCP StreamGraph to Wireshark.

However, in order not to describe graphics just like that, I will do it with a simple and clear example.
Download the file from the test server to your computer using the HTTP protocol.
To do this, use the curl utility, and not a web browser.
curl will help create some problems that we will see on the charts.
Problems will arise due to the fact that the download will be conducted directly to the console, and not to the file.

So, I launch Wireshark, turn on traffic capturing.
I load with the curl utility a 10Mb test file from the v4.speedtest.reliableservers.com server (10MBtest.bin).

curl 'http://v4.speedtest.reliableservers.com/10MBtest.bin'



I stop capturing traffic.
In the received Wireshark network dump, I look for an HTTP packet with a GET request for the 10MBtest.bin file and determine the number of the TCP connection in which it was loaded. Or look for the filter tcp contains "10MBtest.bin" .



I filter all traffic by the TCP connection number in which the test file tcp.stream == 5 was loaded.



And now we are looking at TCP StreamGraph.

It is important to know that all the graphics from TCP StreamGraph are built on one TCP connection and are directed.
The direction indicates in which direction the analyzed data stream moved from the client to the server or vice versa.

The direction and connection is determined by the packet selected in the Wireshark interface.
In the case of the above example, I choose any package from the connection in which the test file 10MBtest.bin was downloaded.
The direction was from the server to the client, so the Source of the package must match the IP address of the server.
All graphics are in the Wireshark Statistics -> TCP StreamGraph menu.

Time-Sequence Graph (Stevens)




Time-Sequence Graph (Stevens) looks like a sloping curve consisting of points.
The coordinates of each point of the graph are the value of the Sequence number of the TCP segment (Y-axis - Bytes) and its capture time (X-axis - seconds).

Accordingly, as mentioned earlier, only segments with data from a single TCP connection moving in a certain direction from server to client (download, download) or vice versa (upload, upload) are taken into account.
According to the theory of Sequence number, this is the number of the first byte of data of a segment in the general data stream.
Therefore, we can say that the graph shows the dynamics of loading / unloading bytes of data in a TCP connection over time.

At any site, the data transfer rate is easily calculated, (Sequence number divided by Time, we get Byte / sec).
As a result, changes in the slope of the curve can be judged on changes in the data transfer rate.

Under ideal conditions, the graph looks like a diagonal line with a large angle of inclination.
However, in practice this is not always the case.
By anomalies on the curve of the graph, you can identify delays in data transmission, the loss of segments and their re-sending (Retransmission).
In the example of the graph below, during loading the file, two similar problems arose with stopping the transfer of data and loss of segments.



Windows hotkeys (quick reference):
Step-by-step zooming in or out of the graph is performed via the i / o keys or by direct selection of the area with the mouse. Return to the original scale, the Home key.
Spacebar - turns the cursor into a crosshair with vertical and horizontal auxiliary lines.
Number keys 1 to 5 - select a different graphic from the set.
Ctrl + right mouse button - a window appears with an enlarged image of the plot of the graph from under the cursor.

Clicking on any point of the graph leads to a transition in the Wireshark interface to the corresponding TCP packet.


Time-Sequence Graph (tcptrace)





In appearance, the Time-Sequence Graph (tcptrace) resembles the previous graph and is intended for a more complete analysis of possible problems. It still displays the values ​​of the Sequence number of data flow segments on the timeline.
However, another segment attribute has been added - its size (TCP Segment Len).
Therefore, the segments are no longer shown by points, but by vertical sections with serifs at the ends, like the English letter I - "ah." The base of the segment is the Sequence number, and the length is the size of the segment in bytes.

The graph also displays information from the backflow confirming segments, Window (Win), Acknowledgment number (Ack) and SACK. Ack values ​​are displayed by a stepped curve that runs below the data segments.
Each stage, its vertex is the instant of arrival of confirmation of the total number of continuously received bytes by the receiver.

Similarly, “stepwise” displays the size of the Win host window.
The curve passes above the data stream.
The top of the step is the sum of the Ack and Win values ​​of the confirming segment.



Blue vertical lines are visualized by SACK blocks.
SACK may be present in the acknowledgment if gaps have occurred in the continuous stream of received data.
The blue line is the range of bytes received after the break.



In general, the graph is a “corridor” of two step curves, within which segments with data are moved. The narrowing of the “corridor” indicates a decrease in the size of the reception window (Win), the extension indicates the opposite.

On the previous graph, two problems were found with stopping the transfer of data.
Time-Sequence Graph (tcptrace) clarified the causes of the incident.
The window size (Win) on the receiving side has decreased.
The sender transmitted the maximum allowable number of data segments so as not to overwhelm the window, and stopped.
After the recipient reported an increase in window size (Window Update), data transfer resumed.



Throughput Graph





Throughput Graph looks like a set of points, sometimes located very chaotically.
The coordinates of each point are the estimated speed of movement of the segment in the data stream (Y-axis - Byte / sec) and its capture time (X-second axis).

To be precise, to smooth the oscillations on the graph, not real, but average speed values ​​are fixed.
The averaging function of the moving average ( Moving Average , MA) is used by 20 values ​​for the previous period.
According to the Wireshark code, the average speed of the N-th segment is equal to the sum of the lengths of all the segments from N to N-20 divided by the delta over the time between their capture.

As a result, two delays in data transfer, caused by a decrease in the window size (Win), led to a drop in Throughput at problematic points in time. The rest of the time, the download speed varied within the range from 1.4 to 3.4 MB.



Round Trip Time Graph



Round Trip Time (RTT) is the time elapsed between sending a segment with data and receiving confirmation of its successful delivery.



Round Trip Time Graph shows RTT (Y axis - seconds) for each segment of the data stream.
The segment identifier is its Sequence number (X-axis - Bytes).



Under normal conditions, most of the points are concentrated at the bottom of the graph.

In the RTT example, almost all the time does not exceed 0.1 seconds, except for the problematic moments when the RTT jumped to 0.4 seconds.

All graphics are interconnected by the formula Throughput = Window size / RTT



Window Scaling Graph





The coordinates of each Window Scaling Graph point is the size of the Windowsize window (Y axis - Bytes) of the segment at the time it was captured (X axis is seconds).

In the current graph, the focus has been changed to reverse the flow of data (client -> server). It only analyzes confirmatory segments.

In the Window Scaling Graph there is information about two problematic cases of reducing the size of the window to critical sizes.
This fully confirms the indications on the Time-Sequence Graph.



Conclusion


Well, it seems that's all. What I wanted - said.
Information on the topic is much more. The article outlined only the basics to help better understand the graphics from TCP StreamGraph, Wireshark.
These graphs are very useful in their practical application and allow you to make a comprehensive overview of any TCP connection, identify network problems.

Of course, there are other tools like TCP StreamGraph, for example, tcptrace , captcp .
Do not forget about IO Graph of the same Wireshark. It has more extensive functionality extending far beyond TCP StreamGraph.

I hope this article will be useful to all those who are interested in network technologies or studying the TCP protocol.

Source: https://habr.com/ru/post/252819/


All Articles