Troubleshooting TCP Sliding Window Issues with Wireshark: A Comprehensive Guide

1. Introduction

In the previous article, we explored how Wireshark can be used to troubleshoot TCP duplicate ACKs, particularly the issues they can cause, such as fast retransmission, while discussing the role of TCP sliding window in managing these problems.

However, among the many flow control algorithms in TCP, the sliding window protocol is clearly the most important mechanism.

In this article, we will use Wireshark to troubleshoot and locate issues related to the TCP sliding window protocol.

2. Sliding Window Protocol

I previously wrote an article that detailed the sliding window protocol, which you can refer to:

Simply put, TCP’s sliding window mechanism works like this:

3. Wireshark Sliding Window Related Packets

3.1 Zero Window

The analysis results of Wireshark may show the following zero window situations:

Let’s analyze them one by one.

3.1.1 TCP ZeroWindow

The TCP ZeroWindow packet informs the sender to stop sending data, as the sender’s buffer is full at that moment.

This indicates a lack of memory in the sender’s process, or it could be caused by untimely ACKs from the receiver.

3.1.2 TCP ZeroWindowProbe

When one party in the communication receives a TCP ZeroWindow packet, it will periodically send a TCP ZeroWindowProbe packet for probing.

The probe packet includes the next byte of data to be sent, and through the receiver’s response, it can be determined whether the receiver’s window is still zero. If the receiver replies with a window size still of zero, the sender’s probe timer is doubled.

3.1.3 TCP ZeroWindowViolation

This packet is received after the receiver has already sent a zero window packet to the other side, indicating the other side has violated the TCP sliding window protocol.

At this point, it is necessary to check the TCP implementation of the sender of this packet.

3.2 TCP WindowUpdate

The TCP protocol allows changing the window size at any time, notifying the other side through messages marked with TCP WindowUpdate.

Two situations may cause the receipt of this packet:

3.3 TCP WindowFull

When Wireshark identifies a message that will completely fill the receiver’s window after being sent, this message will be marked as TCP WindowFull.

After this, the receiver will generally send a TCP ZeroWindow packet to the sender to pause sending.

4. Troubleshooting

The following image shows a typical example of a zero window issue:

Beyond checking memory allocation, the issue could very likely be due to insufficient processing capacity on the receiver’s end. You can further investigate by considering actual business processes.

Additionally, you can open the TCP throughput graph in Wireshark to check the throughput situation:

As the graph shows, the top line displays the window size, and the distance between it and the bottom line indicates the remaining size of the window. If the two lines coincide, it demonstrates a zero-window problem. A consistent distance between the lines indicates the receiver is working well.

5. RST Forced Disconnection

We know that normally a TCP connection is terminated through a four-way handshake:

This is the standard approach, but when you open a webpage, you might have dozens of connections open simultaneously (home page, news, advertisements, periodically updated images, etc.), and closing all these can sometimes require hundreds of FIN and FIN-ACK packets.

To prevent this situation, web servers often forcefully terminate the connection by sending an RST packet after sending request data, though more frequently, an RST packet indicates that a fault has occurred:

5.1 Firewall Sending Reset

As we have introduced in previous articles, if an RST packet is received after every SYN packet is sent, it’s a typical case of a firewall forcefully disconnecting the connection.

5.2 Fault-Induced RST

There are many scenarios where faults cause RST packets, some of the common ones are: