One of the most fascinating things I did in my early years on the internet was click “View Page Source”. Down the rabbit hole I went, barely understanding what was going on or who to even ask for help.
Taking a network capture is much like viewing page source of the network traffic. Webmasters generally understand that their HTML source will be viewable if they post it. However, users don’t always understand that their web traffic is viewable by anyone with access.
For today’s exercise, lets open up Wireshark and start a capture. While that is running, clear your browser cache and check to see what is on http://www.brentozar.com/blog/
Lets grab the server name from the address bar and figure out what IP to filter on. We can do that with nslookup.
Take a moment to imagine yourself troubleshooting a server problem. Our client side capture has a source and destination IP. If we ran Wireshark on the server, the source and destination IPs would not simply be reversed. The webserver’s local IP would be displayed and my PCs public IP would be displayed. To find your local IP address use ipconfig (or ifconfig in linux). To find your public IP address search “IP Address” in google.
If we go back to our client based capture we can see a lot of chatter has happened. Lets filter than down a little bit more to only review the HTTP traffic. Add a second filter by using inclusive and logic. This filter syntax for AND is &&. That makes our filter “ip.addr eq 22.214.171.124 && http”
Entering http://www.brentozar.com/blog/ into the address bar produces a GET command 610 milliseconds after I started the capture. I know this because packet No.24 has a time of 0.6098. The next packet is the server responding with HTTP 200 which is a good response code. This packet was recieved almost 100ms after the request went out. If I ping the IP address I can see my network latency is about 40ms. Sending a slightly larger ping using the -l switch will let me know about how much time is server time and how much is network time. If packet 24 is sending 735 bytes and packet 95 responds with 1248 we can get a rough idea of latency by using ping 126.96.36.199 -l 2083.
That first GET request gives my browser the HTML. In that HTML are several scripts and files I have to go request separately from the original request. Those are in packets 101-107. This happens quickly because it is in the HEAD tags in the HTML. You can drill into each packet and if you expand the data, you might recognize HTML source code which is what you see when you click “view source” in your browser.
There are lots of ways to go from here. Before you start analyzing HTTP in Wireshark, I would suggest checking out some other tools that are specifically designed for website debugging such as Fiddler.