Jan 8 8:20pm
Three websites were chosen for this assignment, and both pinged and tracerouted.
The three websites chosen were: 1. Google.com {74.125.138.138,188.177.122.139}. 2. Google.com.au {64.233.185.94,74.125.138.94}. 3. Docomo.ne.jp {35.71.162.15, 52.223.34.187}.
Notice that each website uses a group of addresses, also known as an aggregate. This allows for load balancing so that each server does not become overwhelmed. As you can see (below), the PING (Packet Internet Groper) results show the DNS (Domain Name Server) results for the IP address conversion, the time it takes to echo a signal to that point and back to your computer x four attempts (normally), and the statistical information for the PING.
For each example listed here and many more attempted, the maximum time for echo was 26ms, which is less time than it takes to type a new command. However, we see a different dimension if we turn our attention to the route. The command TRACEROUTE or TRACERT sends 3 small packets of information to the intended IP address as it attempts to document the path these packets travel to get there. Each and every trace attempted shows time-outs where no data was received within time frame, while this was initially concerning, I started to wonder if this is some kind of firewall effort blocking the information.
Notice that on each attempt, the first hop is to my local wireless router, then on to my ISP, and from there, it travels internally to Atlanta hubs. Even from there, it shows some consistency for between one and four hops before diverging. I even threw in a bonus route to a Japanese computer website. I would have expected that servers farther away from me would be slower, even if not significantly so. However, timing does not seem to be much different in any way. Because the route packets take across the internet is fluid and may be changed due to usage or even server balancing, the time it takes to travel could be affected, even to the point of timing out or losing packets. Another problem I can see is that DNS servers are often slow to update due in part to caches used to speed up the service provided. It would not be unthinkable for a company to go out of business or change web-hosting facilities, which would temporarily cause their website to be unreachable to consumers.
On the plus side, by using these two commands, one can determine if there is a local problem or a remote issue. If the PING command works then there is a connection, if the TRACEROUTE command gets beyond your ISP section, then it is somewhere on the internet that the problem lies. At least you can rest assured that it is not a problem with your computer.
No comments:
Post a Comment