Web pages can be slow for any number of reasons, but it usually comes down to this: either the network is slow and congested, or the actual server you're accessing is heavily loaded and taking a while to process your request.
It is hard to diagnose a server problem remotely, but some basic tools can help you check out the network. The three tools I use most often to debug networks are called ping, traceroute, and telnet. All three tools originated under Unix, but have spawned DOS and Windows programs that behave similarly (namely ping and tracert, which are available using the DOS command shell). There are also versions of these programs that work on a Macintosh. For the purposes of this article, I'm assuming you are using Unix or Linux, though it should apply directly to DOS and Windows.
In this article I am going start with ping, then show how to use Traceroute. What ping does is send out a special packet called the Internet Control Message Protocol (ICMP) Echo Request packet. ICMP packets are special IP control messages that are used to send network information between two hosts, usually things like "don't do that," "send fewer packets," "we don't provide what you want," and "don't go here - go there." When a machine receives an Echo Request, it responds with an Echo Reply, placing the original Echo Request packet into the data field of the Echo Reply.
The way you use ping is pretty simple: You enter ping hostname, where hostname can be a machine name or just an IP address. There are many different versions of ping. The really lame ones just print out, "hostname is alive" (which is only cool if you are pinging a host named elvis). If you have a good version of ping installed, it will produce output like:
$ ping www.aleeanne.org.uk
PING webmonkey.com (18.104.22.168): 56 data bytes
64 bytes from 22.214.171.124: icmp_seq=0 ttl=253 time=0.398 ms
64 bytes from 126.96.36.199: icmp_seq=1 ttl=253 time=0.552 ms
64 bytes from 188.8.131.52: icmp_seq=2 ttl=253 time=0.554 ms
64 bytes from 184.108.40.206: icmp_seq=3 ttl=253 time=0.553 ms
64 bytes from 220.127.116.11: icmp_seq=4 ttl=253 time=0.554 ms
64 bytes from 18.104.22.168: icmp_seq=5 ttl=253 time=0.551 ms
64 bytes from 22.214.171.124: icmp_seq=6 ttl=253 time=0.552 ms
64 bytes from 126.96.36.199: icmp_seq=7 ttl=253 time=0.554 ms
64 bytes from 188.8.131.52: icmp_seq=8 ttl=253 time=0.554 ms
64 bytes from 184.108.40.206: icmp_seq=9 ttl=253 time=0.553 ms
----localhost PING Statistics----
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max = 0.398/0.537/0.554 ms $
What's happening is that I'm pinging www.aleeanne.org.uk - that is, sending one ICMP Echo Request packet, every second, to www.webmonkey.com. When the ping program gets an Echo Reply back from the remote host (www.webmonkey.com), it prints out the response, giving me several interesting pieces of information: the first is the IP address of where it came from (usually this should be the IP address of www.webmonkey.com); the second is the sequence number, starting at 0; the third is the Time To Live field; and the last is the number of milliseconds it took to get a reply.
The sequence number indicates which ping packet it got a reply to. A skipped sequence number indicates a dropped packet, meaning either the Echo Request or the responding Echo Reply somehow got lost in the network. If this is low (low is under 1 percent of the time), there is nothing to worry about. If it is much higher, the network link has some problems. It's not unheard of to get occasional out-of-order responses or multiple replies, but if you get a lot of them, there's trouble.
The Time To Live (TTL) field can be interesting. Every IP packet that gets sent out has a TTL field which is set to a relatively high number (in this case, ping packets get a TTL of 255). As the packet traverses the network, the TTL field gets decreased by one by each router it goes through; when the TTL drops to 0, the packet is discarded by the router. The IP spec says that the TTL should be set to 60 (though it's 255 for ping packets). The main purpose of this is so that a packet doesn't live forever on the network and will eventually die when it is deemed "lost." But for us, it provides additional information. We can use the TTL to determine approximately how many router hops the packet has gone through. In this case it's 255 minus N hops, where N is the TTL of the returning Echo Replies. If the TTL field varies in successive pings, it could indicate that the successive reply packets are going via different routes, which isn't a great thing.
The time field is an indication of the round-trip time to get a packet to the remote host. The reply is measured in milliseconds. In general, it's best if round-trip times are under 200 milliseconds. The time it takes a packet to reach its destination is called latency. If you see a large variance in the round-trip times (which is called "jitter"), you are going to see poor performance talking to the host. However, a couple of laggards in a large sample (50 to 100) is no cause for worry.
To stop ping, type control-c. This terminates the program and prints out a nice summary of the number of packets transmitted, the number received, and the percentage of packets lost, plus the minimum, average, and maximum round-trip times of the packets.
As you can see, ping is a useful tool to test network connectivity and
to measure whether packets are getting from one host to another and details
about their journeys. If you're interested in a more sophisticated tool,
let's talk about traceroute, which tells you the router path a packet is taking.