Traversing a Network

 Because the internet has many computers communicating, the same communication methods, or protocols, must be used when transmitting or receiving information.  This communication method is the internet protocol suite.  IP determines what route each information packet, consisting of a part of the file and an IP header, takes to get to its destination.  The receiving computer reads and removes the IP header.  Then, the receiving computer reconstructs the packets into the original file.

Another instance in which a header, this time containing a number, is sent along with a data packet is in TCP, or Transmission Control Protocol. This header, however, is not used to reconstitute the data, but to ensure data integrity.  The receiving computer sends a signal back to the server indicating it has received the packet.  If the server does not receive the signal from the recipient, the server sends the packet again.  This acknowledgment of receipt is important for successful data transmission because the receiving computer needs all the packets to reconstitute the file.  TCP is utilized for downloading emails, webpages, and programs where exact downloads are critical.  TCP is so vital to internet communication that that the protocol is abbreviated TCP/IP.

In contrast to TCP’s many positives, it has one major drawback, namely, speed.  By requiring acknowledgment of the information packets, TCP doubles the amount of traffic on the network media.  A protocol that does not have this shortcoming is UDP, User Datagram Protocol.  It, like TCP, attaches another header to the packet, but does not require verification that the packet was received.  Because of UDP’s increased speed it is used in VoIP and streaming of media.  These applications exchange accuracy for speed.

Yet another protocol in the internet suite is HTTP, Hypertext Transfer Protocol.  When you type a URL, DNS, Domain Name System, resolves your URL into an IP address.  HTTP then sends a request to the website’s server asking for its webpage.  The server then sends the page to your computer.  A benefit of HTTP is you do not have to navigate a file directory; instead, you click a hypertext link to acquire the desired information.  HTTP sends the information in plain text, making it susceptible to hackers acquiring and reading the data. 

HTTPS, however, uses TLS, Transport Layer Security, to encrypt the file.  This encryption means even if a hacker were able to intercept the transfer of information, he or she would be unable to read it.  Looking for HTTPS protocol being utilized by a website is essential if one is making a financial transaction.

The internet, even with all the protocols in the IP suite, is still prone to problems outside the suite’s realm, namely, connection problems.  For diagnosing issues with connection problems, Windows offers two tools, trace route and ping commands.  Ping sends packets of information to a website and waits for an echo from the webpage.  Trace route, on the other hand, follows a website request from server to server until it reaches its destination.  An issue that may not allow a trace route to capture the hops between routers on the way to the destination or a ping request to not receive a response from the targeted server is network congestion between the server and your computer  Some routers and firewalls on either the server or the requesting computer may also be set to not permit trace route and ping commands.  Additionally, any router on the path to the destination may be offline or experiencing temporary network problems.  Moreover, an issue as simple as a faulty wire or EMI, electromagnetic interference, between the wires may be the culprit.

Screenshots of my pings:

The highlights from the google ping were that all four packets of thirty-two bytes were received by google’s internet protocol address, 142.250.191.164, and an echo was sent back to my laptop.  In addition, the rate of round travel was consistent with a high of 29ms and a low of 27ms.  The average was 27ms.

Next, I pinged Oxford University’s webpage.  The webpage’s IP address, 172.67.20.89, is found on the fourth line next to the domain name.  All four packets sent were received with a surprising average round trip of 28ms.  The mean time was surprising because it was nearly the same as google’s round trip time with of course google being in the U.S. and Oxford in the UK.

I subsequently pinged yahoo’s site in Japan.  The roundtrip time was more like I expected at an average of 278ms.  The time was consistent with a low of 267ms and a high of 285ms.  Again, like the two pings above, zero packets were lost.

Trace Route Activities:

 

The first trace route was to google.com.  Because I was at work, I used my mobile phone as a hot spot to run this trace route.  Therefore, my router’s IP address and my ISP’s IP address are not shown.  The hops to each router were very inconsistent.  Also, the path to google.com had six unsuccessful hops, the most of the three webpages I chose.  This is undoubtedly due to using a 5G network to perform the trace route.  However, the hop was successful as the combination of hops led to the destination.

The second trace route was to Oxford University in the UK.  I performed this trace route at home, so my router’s IP address is 192.168.1.1, the first address listed after the destination’s address. The address immediately following is my ISP’s IP address, 142.254.158.221.  This trace route had nine successful hops and two partially successful ones.  The first partially successful hop was to 66.109.6.68 with two packets received and one packet either lost or timed out on its roundtrip.  Similarly, the hop to 66.109.0.109 was partially successful with one packet received, and two packets that were dropped or timed out.  The overall combination of hops, though, was successful as these combined to reach the destination.

The third trace route was to yahoo! in Japan.  This trace route can be directly compared to the one in the UK because both were done from my laptop at home.  The route to yahoo! in Japan consisted of nineteen hops, one of which was unsuccessful.  Two of the hops were only a partial success.  The hops in question lost six packets of information.  As compared to the UK trace route, this one took much longer and required more steps.  This increased time and number of hops are to be expected as Japan is a further distance away from the U.S. than the U.K.

As seen above, ping and tracert commands can be utilized to view network servers’ problems.  If an echo doesn’t return to your computer from a ping command, at least one of the routers along the roundtrip failed to receive the packets.  Once an echo from the ping command is not received, the tracert command can be utilized to gain further insight into the problem.  Trace route will show where latency is in the path as well as which router has the most latency (bottleneck).  Traceroute will also show if your ISP’s router, a router from the final destination, or a hopping point drops a packet or times out.  This information will allow you to contact the your ISP or the IP addresses owner directly to try and solve the issue.