One of the most important mechanisms of TCP is the Sliding Window mechanism, and the Flow Control mechanism that uses it in order to control the amount of data that a TCP end node is willing to accept on the connection.
In this recipe we will focus on these types of problems, and how to discover the problem and solve it.
Connect Wireshark with a port mirror to the suspected link or server, and start capture. Keep track of every window message you will see in the capture window.
There are several types of window messages that you should be aware of:
TCP Zero Window occurs when a receiver advertises a receive window size of zero (in the window field in the TCP header). This tells the sender to stop sending data because the receiver's buffer is full. This indicates a problem on the receiver that might be:
- A weak server that cannot allocate enough memory for the process
- A problem in the application that does not receive a sufficient buffer, so the TCP has to tell the sender to stop sending data
- An application that consumes too much memory so the operating system will limit the application resources
TCP Zero Window Probe is a message that is sent by the sender in order to see if the receiver's Zero Window condition still exists. This message works by sending the next byte of data to the receiver. If the receiver answers with window that is still zero, the sender doubles his timer before probing again.
The sender ignores the Zero Window condition of the receiver and sends additional bytes of data. TCP Zero Window Violation can indicate a TCP error or bug in the protocol stack.
In order to check what the problem is, check if these events are coming from:
- A specific end device (server or client) that will indicate a problem in the end device.
- A problem in a specific application that will indicate a general application problem.
- A problem when you do something specific in the application, for example, open a specific table, send a file to the printer, create a report, or anything else on the application. In this case, it is of course an application problem.
TCP sends Window Update to the other side in a connection in order to indicate that it changed the buffer size, and is ready to accept higher or lower data rate (buffer size determines the throughput that the sender is allowed to send). This can happen in the case of:
- The TCP receiver recovers from the Zero Window condition, and asks the sender to start sending data again. In this case, you don't have to do anything about it, just check for the problem that caused Zero Window the first time.
- The TCP receiver changes the window's size frequently. In this case check what is disturbing the receiver. It can be an application problem, memory problem, or any other performance problems on the end devices.
If you see this kind of phenomena, there is nothing to worry about. This is how TCP works.
This message is an indication that the sent packet will completely fill the receiver buffer on the receiver. This will happen when the receiver has not sent any ACK confirming the acceptance of the previous data, and therefore, this will be the last packet of data that the sender will send before accepting an ACK from the receiver.
On the receiver side, the moment it gets this packet, it will send a Zero Window message to the sender that will stop sending the data.
This event is triggered for the same reasons that trigger Zero Window. It is simply an indication to a non-responsive server or application. A typical example is shown in the following screenshot:
In the previous screenshot we see that:
- Packet
183816,192.168.2.138tells192.168.1.58that the sender window is full. - In the next packet,
192.168.1.58sends a signal to192.168.2.138, telling him to stop sending data. This is a Zero Window signal. - Both sides continue to send Zero Window and Zero Window Probe.
- The last packet of the connection is an RST sent by
192.168.2.138in order to break the connection. - In some cases Zero Window condition will be recovered by a window-change message. In some cases it will be closed with a reset (that can be because an application does not receive any data because of Zero Window).
The TCP Sliding Window mechanism works as follows:
- After the connection is established, the sender sends data to the receiver, filling the receiver window.
- After several packets, the receiver sends an ACK to the sender, confirming the acceptance of the bytes sent by it. Sending the ACK empties the receiver window.
- This process is continuous when the sender is filling the window, and the receiving party empties it and sends confirmation of the information.
- Increasing the receiver window size tells the sender to increase the throughput, and decreasing it tells him to decrease the throughput. It works according to the following WS/RTT rule (with some changes according to the TCP version):
You can also use the TCP throughput graphs and the IO graphs to view these problems. In the TCP throughput graphs, use the TCP trace graph, where the upper line indicates the window size, and its distance from the lower line indicates what is on the left-hand side of the window. No distance between them indicates a Zero Window.
A fixed distance between the lines (as shown in the preceding screenshot) indicates a good operation on the receiving side. When the lines are getting closer, it indicates that the sender is overwhelming the receiver. As long as lines are not overlapping, TCP will continue to send data.