Principal Thoughts

Moving Bits: Networking Fundamentals, Part 2

Moving Bits: Networking Fundamentals, Part 2

In the first part of this series on Networking Fundamentals, I discussed three basic layer concepts in networking, and described them using an analogy to a physical postal system. If you haven’t read that post, please review it before moving on. However, to briefly recap, the three layers I discussed were:

  • a physical layer, which allows for the conveyance of information, and is analogous to the carriers, logistics systems, and delivery and drop-off points in a postal system; 
  • a packaging layer, which allows for addressing and packaging of information, and is analogous to the envelope a letter goes into;
  • and a protocol layer, which allows for two parties to interpret the data they share, and is analogous to the language and grammar used in the letters I would share with a friend.

In technical terms, these layers are link-layer protocols (such as Ethernet, WiFi, or DSL), connection protocols (such as TCP/IP) and application protocols (such as HTTP), respectively.

In this post, I will move on to discuss addressing, in the most common and basic forms, and briefly work through a simple example of an HTTP request and response. I will continue to build on the postal system analogy, in order to provide a consistent mental model as you continue to deepen your understanding of networking fundamentals.

Addresses, and a Practical Example

Addressing is the mechanism for telling the network where you want your information to go. In modern systems, addressing is fairly complex and multi-layered, but the basics mechanisms remain simple.

First, in order to exist on the network, a computer must have an address, just as a house must have an address in the postal system to receive mail. In computer terms, these are IP addresses and, at least for the most part, they consist of ‘IPv4’ addresses. Most people are at least passingly familiar with these, as they have existed since the very early days of the Internet and have made appearances in popular movie and television programming for decades.

IPv4 addresses are most often expressed as a “dotted quad,” which looks like ‘192.168.123.101’. Each of the four numbers in the dotted quad is a single byte, and, to maintain validity, cannot exceed 255. In addition, since these are addresses that are shared across the world, and which need to be unique in order for the Internet to deliver traffic to the right recipient (just like postal addresses need to be unique to properly deliver post), there are rules and governing bodies that restrict what IP addresses may be used for what purposes, and even enforce ownership on a global basis.

So, stepping back, an IP address is like a postal address. Like a postal address, which specifies a house, an IP address specifies a machine on the network. But humans aren’t very good at remembering numbers, and even before the global expansion of the World Wide Web, the scientists and researchers who were using the early Internet wanted a way to refer to these computer systems using something more human-friendly.

To solve this problem, the Domain Name System (DNS) was created. While the technical details of the implementation of DNS are fascinating, for the purposes of this fundamental overview, it is sufficient to know that DNS is a mapping of a string to an IP address. This mapping is scoped and hierarchical such that resolving a particular domain name is deterministic, and ownership of names can be strongly enforced.

But in the end, DNS is just like having a set of postal addresses that you can look up by name in an address book. When I want to find a friend — let’s assume their name is Joan Smith — I will start by going to the ‘S’ section of my address book, find Smith, then go through the entries until I find Joan. Then I have the address, which I don’t have to remember, because I can look it up. In exactly the same way, when I want to find the IP address of www.theaspiringprincipal.com, I first go to the .com authority and ask who I should ask about theaspiringprincipal.com. Then I go to the theaspiringprincipal.com authority and ask for www.theaspiringprincipal.com and get an IP address back. This is in fact what your web browser does when you type ‘www.theaspiringprincipal.com’ into your address bar.

Once you have this IP address, you have the means to send information to another computer on the network. So what happens next? For the sake of illustration, I will first consider the hypothetical case of Joan Smith providing a web page result. Once I have Joan’s address, I will take a piece of paper, and using language and grammar that Joan can understand, I will write a request for some information, maybe the details for an upcoming party. I will then put this request in an envelope, write her address on the envelope along with my own return address, and place that envelope in the postal system. The postal system will route the envelope to Joan using the address information. Joan then opens the envelope, interprets the language and grammar in the letter, acquires the requested information, writes it out on a new piece of paper, puts that in a new envelope, puts my address on it (from the return address on the original letter), puts her own return address on it, and puts it in the post. The postal system routes the return letter to me, I open it, interpret it, and now I know where to go for the event I asked about.

How does this all translate to HTTP? Almost directly. When you put ‘http://www.theaspiringprincipal.com/’ in your browser, the first thing that happens (as discussed above) is that the IP address is looked up for www.theaspiringprincipal.com using DNS. Once the address is known, your browser constructs a request using the HTTP protocol (language and grammar) asking for the homepage contents. This is then packaged in a TCP/IP stream and sent to the address. The TCP/IP stream contains return address information, so when the machine located at the IP address for theaspiringprincipal receives the request, it can package up the homepage information and send it back. Your browser then interprets that information and displays it on your screen.

This is, necessarily at this point, simplified. In fact, for example, TCP/IP is not one thing, but two: TCP is a connection-oriented stream protocol on top of IP, which is a stateless message-oriented protocol. These details, however, are beyond the scope of this introductory series. The mental model described here is enough to help understand the fundamentals and allows us to continue expanding our analogy by adding more components to the system that are common in modern software engineering.

Be sure to join our mailing list, if you haven’t already, to ensure you don’t miss the next installment of this series, where we will add NAT and private addresses to the mix.

Justin, of The Aspiring Principal