At The Aspiring Principal I strive to offer a broad variety of insight, not only on career and industry topics, but also technical ones. I have found recently that many engineers think of networking as black magic, and as a consequence tend to avoid understanding it, thinking it’s too complex or too difficult. The unfortunate effects of this avoidance are bad decisions or unfounded assumptions when building systems. In this series I will strive to provide a fundamental review of networking, with particular emphasis on HTTP interactions over TCP/IP (i.e., Internet-like) networks.
Three Layers, and an Analogy
While it is tempting to begin this article with a history lesson, I recognize that many people won’t find the history of the Internet as fascinating as I do. Suffice it to say that the concept of networking computers dates back to the very early days of computing, and the roots of our modern networking are embedded in the original military applications for failure-resistant systems.
It is also useful to note that many of the core functional components of the modern Internet have not changed substantially from those early days. This is both a testament to the robust and flexible nature of those early decisions, and the immense inertia created by the global Internet — very simply, changing anything, even a thing that is technically limiting, is incredibly difficult.
It is also tempting to start this overview with the usual OSI model, protocol layers, and symmetric networking concepts. This is the usual course for networking education; however I believe that it is part of the cause of the “networking is hard” mantra that is so prevalent. While a future article may discuss those topics, I am going to try to explain networking fundamentals in a different way.
At the most basic level, networking is about sharing information. The goal of a network of computers is to allow those computers to share information with each other. Doing that, it turns out, is somewhat difficult since information has to conform to agreed-upon standards in order to be understood. While the earliest methods of sharing data between systems were all point-to-point, another early realization was that the ability to share information was more valuable when you didn’t have to create dedicated connections for each pair of machines. In other words, when you can create a network, and provide a set of standards so that any system on that network can talk to any other, you have a more flexible solution.
In order to accomplish the goal of a set of interconnected machines, each of which can communicate with the others as required, there are a number of obstacles to overcome. One way to understand how the Internet works is to walk through the set of problems that the early inventors of the Internet had to solve. The first problem is one of physical interconnection. After all, if you are trying to share bits between machines, there has to be some way to convey those bits. Early solutions used a variety of technologies and techniques. Modern systems do as well, though the modern solutions are significantly more advanced than the original communication networks.
Technologies like Ethernet, DSL, SONET, WiFi, DOCIS, and others provide this physical and most primitive layer of interconnectivity. Understanding these is not necessary for most software engineers today, although it can be helpful for anyone who is working with mobile networks (the particulars of cellular networks, for example, can impact customer experience) or any engineer who is focused on very high performance solutions. We will reserve detailed discussion on these topics for a future article.
Once a set of machines are connected, and there is a standard way to get bits from one to another, the next set of problems involves a standard way of packaging data, initiating conversations, and handling errors or problems that may occur. At this point, an analogy is useful. Consider the physical postal service. In the postal system, the physical interconnection is represented by the set of mail carriers, logistics systems, and pickup and delivery points throughout the world. This lowest level of capability provides the bare means of moving information around, but does not mandate or dictate much in the way of how that information is formed, packaged, or interpreted.
The next layer, then, is analogous to words written on paper and placed in an envelope. This layer, which is (for the sake of this discussion) comparable to TCP/IP, includes the ways of packaging information, limits on how much information may be included in a single package, and methods for addressing that package to a recipient. The underlying physical systems don’t need to know anything about the content of the package, just the addressing, and the content creator doesn’t need to know how the underlying physical system works, so long as they conform to the constraints imposed (package size, in this case).
If TCP/IP is our envelope, then we can move one more level up to HTTP by extending the analogy to the language and grammar used in the letter I write. If I wish to communicate something to a friend, I will use a language and grammatical structure that the friend understands, such as English. If this is instead a formal interaction with someone I don’t know, I may also include information such that they can respond to me in a way I will understand. HTTP is one of many protocols that specifies the language and grammar of communications between two computer systems. It does not dictate the actual contents of the message, but rather the way in which that information is conveyed.
In summary, then, we have the lowest level (such as Ethernet, WiFi, etc.), which is how the information is physically moved, a middle layer (TCP/IP), which defines how the information is packaged and addressed, and a higher layer (HTTP), which defines how the information is structured and should be interpreted. These are analogous to a postal system, envelopes with addresses, and a common language and grammar, respectively. We will tackle more details on each of these in the next post.
Hopefully this introduction has already helped you feel less apprehensive towards networking, and as we dive deeper, we will continue to extend the analogy to help provide a mental framework for modern networking.
Justin, of The Aspiring Principal