Let's take an example where a website is loading slow. For example, lets say the dreaded loading gif is displayed when navigating to www.example.com. Wireshark cannot always determine why there is latency. However, Wireshark can determine if the latency 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 a server. The goal here is to determine if the dreaded loading gif 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 if a website is running slow. 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 latency, such as packet loss, congestion, and TCP errors, et cetera. 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, start a Wireshark capture, and then navigate to www.example.com. In this example, it took the DNS server a meer 0.147 seconds to resolve www.example.com to 93.184.216.34, 0.019 seconds to complete the 3-way handshake, 0.025 seconds for the server to acknowledge [ACK] the GET request, 0.001 seconds for the server to give the OK, and 0.026 for the client to acknowledge [ACK] the server. The total combined time for the entire conversation is 0.218 seconds, which is just over 2 milliseconds. In the scenario where www.example.com loads fast, this confirms that the client, the path, and the server are at least capable of serving a very small amount of data very quickly.

Do similar captures on other devices in the LAN, and see if the times are similar or different. In this example, www.example.com consistently loads fast on every device except for the device connected to interface 12. If www.example.com consistently loads slow on the device connected to interface 12, this suggests some issue with the client connected to interface 12. Remember, Wireshark helps you to determine if the issue is with the client, the path, or the server, but doesn't always let you know why there is latency. When the client is the problem, you need to examine the client.

If www.example.com is loading slow on multiple devices in the LAN, check for the following issues. It is usually best to create a custom Wireshark profile, with a collection of custom buttons that can be used to quickly spot common issues. For example, you could create a packet loss button, a DNS errors button, an HTTP error button, et cetera. in this way, no matter what issue you are looking at, you can jump through your buttons to quickly spot the issue. Buttons can be created for the following common issues.

• HTTP continuation packets
• HTTP errors
• Packet Loss
• Round Trip Time (RTT)
• SMB / Samba
• TCP delta time
• Unresponsive server
• Window Size 0

www.example.com is a very light weight website. In fact, the entire website can fit within a single packet. In the screen shot above, packet 10 is 1010 bytes, and contains all of the HTML of the www.example.com site. Modern applications and network services tramsit much more data than www.example.com. Once www.example.com is constantly loading fast, next examine the application that is running slow. Let's consider the scenario where www.pbs.org is taking a long time to load. 

Unlike www.example.com, the www.pbs.org server transmitts nearly 100 files to the client.

Comparing the load time of www.example.com to the load time of www.pbs.org is like comparing apples and oranges. These websites should not be compared, because www.example.com loads one small file, and www.pbs.org loads just under 100 files. www.pbs.org will certainly take longer to load than www.example.com, but this doesn't mean there is some issue with the path or the server.

Finding the packets in Wireshark associated with www.pbs.org is not as straight forward as www.example, because www.pbs.org uses a number of different IP address. In this example capture, www.pbs.org has the following IP address:23.36.34.44, 23.45.180.160, 23.46.218.75, 23.207.195.163, 52.20.41.184, 52.85.112.114, 52.85.112.124, 52.85.112.126, 54.225.158.137, 54.243.141.169, 74.125.202.155, 74.217.253.60, 104.152.142.68, 108.168.174.48, 149.174.66.134, 151.101.128.207, 157.240.2.25, 157.240.2.35, 162.247.242.18, 172.217.4.98, 172.217.6.98, 205.185.216.10, 216.58.216.225, 216.58.216.226, 216.58.216.227, 216.58.216.230, 216.58.216.232, 216.58.216.234, 216.58.216.238. A problem with any of the web servers associated with these IP addresses can cause www.pbs.org to take a long time to load.