Experimenting with Ping and Traceroute

In this blog post, I will explore using the ping and traceroute functions. Using the ping function allows you to determine if a server is online and to see how quickly you can reach it, while tracerouting provides an exact route of a ping request from your device to the server you are sending the request to.

I chose three addresses in three different locations: Google.com (the U.S.), Amazon.co.uk (the U.K.), and Yahoo.co.jp (Japan). I received the quickest ping responses from the U.S. address (roundtrip speeds of 27-30ms), while the ping responses became far longer the further I got from the U.S.: for the U.K. address, the roundtrip times ranged from 121ms to 178ms, while in Japan they ranged from 207ms to 326ms.

I used the same addresses to test the traceroute function. Fittingly, I had the most success tracerouting Google.com, my sent packets only taking 12 “hops” to reach their destination. Meanwhile, it took 28 hops to reach Amazon.co.uk (just shy of Windows’ 30-hop maximum), and 16 hops to reach Yahoo.co.jp.

The ping data gives me a basic idea of just how long it took for my request to reach the respective servers. Through my results for this experiment, a direct correlation between speed and distance can be seen. Given that the location of Google.com’s servers would be in the U.S., my request had to travel to less places, resulting in shorting roundtrip times. The further I got away from the U.S., the speeds decreased.

Using the traceroute function largely backs up my ping data, though it includes far more detail of the exact journey my request packet took to its destination. Each line of a traceroute inquiry shows my request “hopping” to the next router on the path towards my destination IP. In each of my results, you can see the packet beginning at my home network, switching to my ISP’s network, then jumping to the ISP of the host server I am trying to communicate with prior to making it to the website’s servers themselves. Naturally, my packet took less “hops” to reach the Google.com network as it is geographically closer to me. Speeds decrease as I get further away from my home network, which resulted in some of the hops timing out as I tried to reach the Amazon.co.uk and Yahoo.co.jp addresses.

One purpose that the traceroute function serves is to elucidate network issues. An interesting thing I noticed in comparing the Amazon.co.uk and Yahoo.co.jp traceroute results is that my request began to time out far more as it got closer to the Amazon.co.uk destination, while the Yahoo.co.jp address did not run into those issues to the same degree. In reviewing the traceroute results, the Amazon.co.uk request began to run into issues once the packet received routers belonging to Cogent Communications (“cogentco.com”); presumably, this is the ISP being used by the Amazon.co.uk servers. In contrast, there were comparatively few timeouts once my packet reached the Japan ISP (“iij.net”). This indicates that, at the time of my traceroute request, Cogent may have been encountering a worse connection to the internet than my ISP or IIJ. If the traceroute request timed out entirely around the same location and the trace did not complete, it could be ascertained that Cogent’s connections were down or encountering issues. Alternatively, if my packet timed out and stalled once it left my home network (somewhere in the first 2 hops), this would indicate network issues on my end.