Let's take an example where a web stream is slow. For example, lets say the dreaded loading gif appears when watching a video stream. Wireshark cannot always determine why the stream is freezing. However, Wireshark can determine if the freezing is an issue with the client, the path, or the server.

Let's use an example of a LAN with some devices connected to a switch, a few routers along the path, and the streaming server. The goal here is to determine if the freezing stream is a problem with the client, the path, or the server. It usually makes the most sense to first perform a Wireshark capture on the client, because chances are that you will typically have access to the client, but you may not always have access to the path or the server.

A single Wireshark capture cannot always tell you why a stream is freezing. Typically, you need to compare multiple Wireshark captures. To use an analogy, it is hard to say whether an orange is big or small if you only have a single orange.

It is only after comparing our orange to other oranges that we can say that our orange is big or small.

There are a number of things that can cause freezing, such as packet loss, congestion, and TCP errors. While there are a variety of places to start, I like to first close all of the open applications on the client and the flush the DNS cache.

PS C:> ipconfig /flushdns

Next, make two Wireshark captures, one where the stream is not freezing, and another when the stream is freezing. 

After capturing traffic for a few minutes, stop the Wireshark capture, then Statistics > Conversations. Select the IPv4 tab, and there should be a single IPv4 address that has the vast majority of the packets in the capture. In this example, the majority of the packets have 173.223.204.73. This is the IPv4 address of the streaming server.

Select Statistics > IO Graph. By default, the Y Axis will be Bits, not Bytes. This is preferable, since ISPs measure upload and download speeds in Mega Bits per second (Mbps), not Mega Bytes per second (MBps). In the Display filter area of the IO Graph, add the IPv4 address of the streaming server. The graph below was taken when the stream was not freezing. This graph shows the streaming server sending a chunk of packets in a steady interval.

In this example, the highest spikes are near 8 * 10 to the 6th power. The math for this is 8 x 1,000,000, which is 8 million bits per second, or 8 Mega Bits per second (Mbps). This type of graph does not necessarily mean there is a problem, and also does not mean there is not a problem. Since the spikes are near 8 Mbps, if your download speed is also 8 Mbps, this may suggests that your download speed is not adeqate. On the other hand, if your download speed is greater than 8 Mbps, the spikes are not necessarily a problem.

For comparison, the below graph was taken when the stream was freezing and blurry. Notice there are not consistent spikes, and noticable TCP errors. The goal here is to determine if this is an issue with the client, the path, or the server.