The bottom line is, of course, how to analyze the HTTP problems. This is what this recipe is all about. HTTP problems can happen because of a slow server or client, TCP performance issues, and some other reasons that we will see in this recipe.
When you experience bad performance while browsing the Internet, connect the Wireshark with port mirror to the PC that experiences the problem, and when it is the whole network that suffers from bad performance, port mirror the connection to the Internet.
There can be various reasons for a slow browsing problem, and we'll try to figure it out step-by-step. The steps are given as follows:
- First, check that you don't simply have loaded line to the Internet, high error rate on the communications line, or any of these obvious issues that cause most of the problems (see Chapter 4, Using Basic Statistics Tools and Chapter 5, Using Advanced Statistics Tools for further details).
- To negate a TCP issue (as explained in detail in Chapter 9, UDP/TCP Analysis), check the following details:
- In the Expert info window, you don't get too many retransmissions and duplicate ACKs (up to 0.5-0.8 percent is still tolerable).
- Make sure that you don't get resets on the HTTP connections. It might be due to firewalls or site restrictions.
- Make sure that you don't get the following DNS problems:
- Slow response time, as described earlier in this chapter
- Names are not found, not correct, and so on
- If none of these apply, well, let's dig in to HTTP.
Tip
Don't forget to look at the network and IT environment as a whole. You cannot separate TCP from HTTP, or the DNS problems from the slow browsing of applications. It can be that you have a very slow HTTP server; and because of its slow responses, you will get TCP retransmissions. Or, because of the slow DNS server, you will get a web page that opens after many seconds. Just go step- by-step and isolate the problems.
When you open a web page for the first time, it can take a few seconds. In this case, you should check the following conditions:
- Check if the line is not loaded.
- Check the delay on the line (a ping to the website will do the job).
- Look for error codes. Usually you will see the reason for the error on the browser, but not always.
- Configure the filter
http.response >= 400and see how many errors you get. In the following sections, we see several examples of what you should pay attention to.
A simple example for a client error is presented in the following screenshot. To get to this window, perform the following steps:
- Right-click on the packet with the error code.
- Choose Follow TCP stream. You will get the following window:
- You can see the following conditions:
- I tried to browse the URI
/poker-client/broadcast.htm(marked as 1 and 3 in the preceding screenshot) - The URI was forwarded by the referrer:
http://www.888poker.com/poker-client/promotions.htm(marked as 2 in the preceding screenshot) - The status code was 404 Not Found (marked as 4 in the preceding screenshot)
- I tried to browse the URI
Just to clarify things, I was not playing Poker, I was working on a networking problem.
You can get service unavailable (code 503) status due to various reasons. In the following example there is a small office that has the following complaint: they can browse Facebook, but the moment they click on a link on this site, they get the new page as blocked. In the following screenshot, you can see that the problem was simply a firewall that blocked it (obviously).
In standard HTTP browsing, you should see a very simple pattern as follows:
- TCP opens the connection (three-way handshake).
- HTTP sends a
GETcommand. - Data is downloaded to your browser.
Tip
In most cases, opening a web page will open multiple connections—in many cases, tens of them. For example, when you open a newspage (www.cnn.com, www.foxnews.com, www.bbc.co.uk), it opens the main page, news bars, commercials, temperature window, connections to other sites, and more. Don't be surprised if a single page will open nearly a hundred connections, or even more.
In case of a web page that opens multiple connections (as most web pages do), each connection requires a DNS query, response, TCP SYN-SYN/ACK-ACK, and HTTP GET; only then the data will start to appear on your screen.
When you don't see anything in the packet details pane, right-click on a packet and choose Follow TCP stream. This will give you a detailed window, (as in the preceding screenshot) which provides you with a lot of data for the connection.
Another tool that is widely used for HTTP is Fiddler. It can be found at http://fiddler2.com/. Fiddler is a free tool that is planned for HTTP debugging. It is not in the scope of this book.