Wireshark is a software designed to troubleshoot communication networks, but communication does not live alone. Usually when users complain about a “slow network” they actually mean “something here works slow”, and of course, the network is the first to blame. Wireshark that is commonly used for network analysis can also show you indications, and in many cases to discover problems that comes from the applications and the computing hardware.
This article is based on the Wireshark courses series: Wireshark Basics, Core Protocols Analysis, Applications Protocols Analysis and Network Forensics.
One of the simple ways to discover slowness in end points (PCs, servers or applications running on them) is locating slowness issues with the TCP Sliding Windows mechanism.
How does this mechanism work? quite simple. When two stations open a TCP connection each side informs the other what is the size of the memory it allocates for the process (A process can be file transfer, DB Client talking to DB Server, browsing a web server in HTTP or any other application that works over TCP), referred to as a memory buffer. The buffer size is set during TCP connection establishment and can be changed during operation.
The size of the window in memory determines the rate of data transfer, according to the approximate formula:
When:
- Throughput – effective application bytes/sec.
- Round Trip Time (RTT) – time between sent packet and the acknowledge for that packet.
- Window Size – size of the memory buffer on the receiver side.
The TCP Sliding Window mechanism principle is simple: for each process, the receiver allocates a buffer in its memory for receiving bytes from the sender. The sender sends bytes to the receiver, continuously filling the receiver buffer. The receiver on its side reads the information from the buffer, empties the buffer, and send an acknowledge back to the sender confirming that data has arrived.
If the receiver works properly, it will clear the buffer fast enough and send acknowledges on time to the sender. If the receiver is slow, or the applications that runs on it is slow, it will not clear the buffer fast enough, that will cause one of the two things (or both):
- Since Wireshark sees the window size of the receiver (it is sent in the window size field in every packet), and it sees also the number if bytes that were sent before they were acknowledged, Wireshark can notify that [receiver window is full] (square brackets indicate that Wireshark discovered this issue in the packet stream)
- When the receiver will see that its window is full, it will reduce the size of the window it advertises to the sender to zero. In this case Wireshark discover a window size value of “0” and present a “Zero Window” message.
Let’s look at some examples. First, every time I test a network using Wireshark, one of the first things I do is open the Expert Information window (from the Analysis menu) and see if there are any unusual effects. In our case, we see warnings and notes with various TCP window issues (see image below).
When we right click on the “TCP Zero Window segment” and chose “apply as Filter” and “Selected”, and we will get all the packets in which Wireshark has discovered it.
On the display-window bar, we see that the tcp.analysis.zero_window filter was used, and in the packet list we see all the packets that this filter applied to. From here we can see that for example on the first packet, packet 2284, a TCP Zero-window was sent from the sender 192.168.13.128 TCP port 4180 to the receiver 91.208.139.200 port 443. That happens when the sender tells the receiver to stop sending it additional packets.
To isolate the problem, and see if it happens on other connections, we will choose Statistics à Conversations, and click on the “Limit to display filter” checkbox.
We see that the only connections that appears here is the connection between the source 192.168.13.128 port 4180 to destination 91.208.139.200 port 443.
Right-clicking on this connection and choosing it will bring s back to the main Wireshark window, and on the packet list we will see that every certain amount of time a zero-window is send from 192.168.13.128 to 91.208.139.200. In the next figure we see that Wireshark discovers a TCP window full” on data sent from 91.208.139.200 to 192.168.13.128 in packet 2487, and two packets later 192.186.13.128 reduces its window to zero – telling the server to stop sending it more information.
Clicking in packet 2487, that is on a packet carrying information from the server to the client and choosing TCP stream graphs à Window scaling from the statistics menu will show us how the receiver window behaves, and we see clearly that it is “choked” many times during this data transfer from the server.
And if you zoom into it, you will see that there is a serious window issue on the client – probably a slow client or a slow browser. What we can see in the stream graphs – this worth another article, and we will get back to you on it.
