I found the traceroutes to be particularly interesting because it was fun to see where the data traveled. I chose to use a website that could be found in different countries, to see if their servers were hosted in those countries as well. So, I decided on cnn.com, cnn.co.jp, the Japanese version, and news18.com which is India’s version. Below are the pings and traceroutes.
It’s interesting to note that when using both ping and tracert IPv6 addresses are shown which make tracing and reading very difficult. So, I did some Googling, and the IP address is in San Francisco. It’s crazy to think that these small packets of data travel to San Francisco and back in a minimum of 30ms.
The times significantly increased when I pinged the Japanese CNN website as you can see below. The minimum ping jumped to 295ms, which is incredible to think that it only took 3/10s of a second to travel across the ocean and back. It’s mindboggling! During the tracert, you can see it bounce from my house in Memphis out to San Jose, CA, and then the big jump in time to the servers in Japan.
Now, News18.com, India’s CNN I found very interesting in the jumps it made. The ping time was a little faster than Japan’s, coming back at a minimum of 235ms. Looking at the tracert, after it leaves me here in Memphis, it travels to Atlanta, Ashburn VA, Newark, London, Marseille, and then finally Mumbai. Because the website URL didn’t end in India’s URL extension or .in, I wasn’t sure the website was hosted in India, but the tracert proved otherwise. Very Cool!
It’s evident that the further the location is from my laptop the longer the ping and tracert should take. What’s interesting though is that Tokyo is roughly 6,600 miles from Memphis and Mumbai is an estimated 8,500 miles from Memphis. Even though Mumbai is further away, the results returned faster. Maybe this is because the data sent and received travels over more land to Mumbai so it’s possible that the signal can move faster. I’m not sure, what do y’all think?
When a user pings an address and the request times out it may be because the address doesn’t exist or isn’t currently connected. The user can use tracert to see precisely where the data transfer is failing which is helpful to technicians trying to figure out if there’s a connection issue on their end or on the end of the server to which they are trying to connect.
No comments:
Post a Comment