Exploring the TCP/IP stack with an example

The TCP/IP stack is present in your day-to-day life, and you use connected applications extensively – your messaging app, the websites you visit, streaming apps, and more. The question is: what do they have in common?

The answer is simple, but the use can be complex and very sophisticated. They all use one or more communication channels to transfer data and, therefore, implement communication protocols. But how can this be explored in our reality? Let's understand how these techniques let us develop efficient and robust applications.

It all starts with the interconnection of computer networks (yes, your smartphone is also a computer), and because of this, we are able to develop applications that make use of this interconnection so that you can send and receive data, regardless of the medium (metallic cables, optical fiber, or even radio waves – the famous wireless).

We need to understand that for two different entities to exchange information, a series of rules need to be established. These rules range from the specifications of the sequences of bits and bytes that are transmitted, their respective meanings, and the actions that are taken depending on what is sent and received, among other things. We are talking about communication protocols.

Formally, a communication protocol is a set of rules, procedures, formats, and actions that are specified so that two or more entities can exchange information with each other. Of course, for this to happen, we need to ensure that many steps are completed, and therefore, it is necessary to separate responsibilities and ensure that certain parts of this entire process can be interchangeable and replaced.

What am I talking about? Let's think about a simple example.

Imagine a situation where the president of a Russian company wants to talk to the president of a Pakistani company to develop a new product together. How would this communication take place?

If both spoke in their respective local languages, neither of them would understand anything the other said, and so no product would be made.

So, let's think: what if we adopted a "communication protocol" between them? What if we used two translators who could respectively translate from Russian to English and from Urdu to English? Would it be easier? Certainly, translators could transmit the respective messages and translate them back to their interlocutors. Well, through this type of rule, we manage to establish communication between two different entities, as both follow this procedure and can understand what each one means. Furthermore, all communication between two entities takes place through packets. Imagine a conversation between two people: each phrase in this conversation can be considered a packet. One of these people wants to tell several facts to its interlocutor. If the text is too long, it can be sliced into phrases. Each phrase can be (metaphorically) equivalent to a packet. Formally, a packet is the smallest unit of transmission between two entities. An exceedingly long message (a download of a file) is fragmented into several packets so that we can have control over the transmission of each fragment (checking whether the fragment was transmitted and received in full, order of the fragments, confirmation of receipt of a given fragment, among others).

Now that we conceptually understand what a communication protocol is, let's turn to the more technical part of network communication today. Today, all communication is done through a stack of protocols (protocols responsible for rules at different levels). There is a reference model called Open Systems Interconnection (OSI). This is a model created by the International Organization for Standardization (ISO) and defines that communication between two entities is subdivided into seven different layers, each with its own responsibility and manipulating specific rules at each stage of communication.

The OSI model is the main model in the computing field for defining the communication standard between two distinct entities. Even though it is a reference model, it is fundamental to understanding the separation of responsibilities in each layer.

Figure 1.1: The seven layers of the OSI model

Let's understand each of the layers:

• Layer 1: Physical – This layer is responsible for the rules for transmitting digital signals in a physical medium (cable, optical fiber, or waves). Here, the main concern is how a set of bits is transmitted through these transmission media and at what transmission speeds.
• Layer 2: Data Link – In this layer, the concern is to establish data delivery rules between two entities already connected by a physical medium. Among the functionalities of this layer are the identification of the peripheral that connects your entity (your computer's network card or your smartphone's antenna), ensuring that the datasets were transmitted correctly, through parity calculations, among others.
• Layer 3: Network – Here, the protocol deals with issues related to identifying the machine that is connected to this network (it may have several communication peripherals – network cards, for example), its addressing, as well as the interconnection of several networks (the connection between your home's local network and the access provider's network), and which routes will be drawn for the message to leave its origin (your laptop) and reach its destination (the website you want to access, for example).
• Layer 4: Transport – In this layer, the concern is whether the data will arrive consistently or not. Here, we can have two types of treatment: connected and unconnected protocols. In connected protocols, the delivery of the message, any retransmissions if the message has not been delivered, and the order of the messages are of crucial importance (an example of this is a website that needs to deliver all its content so that the browser can display the page on the screen). In non-connected protocols, concerns about possible packet losses (message fragments) are not so crucial. An example of this is streaming or video transmission, where any losses do not compromise the transmission (you just stop seeing or hearing a small part of your media)
• Layer 5: Session – At the session layer, the rules are aimed at coordinating two connected applications. . For example, on a conference call, participants can define their conversation rules, such as: if they can talk at the same time or one of them talks and another one just listens, or if no one says anything for a period, the call finishes automatically. The OSI session layer provides a channel between entities that keeps communication active or capable of working if communication is broken without having to start it over.
• Layer 6: Presentation – In the presentation layer, the main function is to define how the data will be presented or exchanged. For example, we can exchange data between two entities defining a common character encoding standard. In other words, the presentation layer can be a "translator" between data format representations.
• Layer 7: Application – Here, we can find the most popular applications used on the internet, such as HTTP for web browsing, SMTP for email exchange, and FTP for file transfer. The application layer provides functions and interfaces that applications use to communicate over a network.

In this model, it is worth remembering that a given layer uses functions from the layer immediately below when transmitting data, and when receiving data, it delivers them to the layer immediately above. While the perception is that each layer of an entity communicates directly with the corresponding layer of the target entity, communication occurs from the application level to the physical level. Information is transmitted and received at the physical layer of the other entity, then delivered successively until it reaches the application layer, as shown in the following figure.

Figure 1.2: Communication between layers

Now, in real life, this seven-layer model is implemented in a much simpler way, with a more compact model with only four layers, in addition to the application layer (where we can add functionality from the session, presentation, and application layers). The alternative model to OSI is the TCP/IP model, which has become the standard protocol of the internet. TCP/IP has the following layers:

• Media Access layer – Encompassing the physical and data link layers of the OSI model
• Network layer
• Transport layer
• Application layer – Encompassing the application, presentation, and session layers of the OSI model

Each layer's functions are the same as in the OSI model, and the TCP/IP model is currently the most used in connected applications, as it has two protocols in the transport layer. Figure 1.3 depicts the equivalence between the TCP/IP and OSI reference models:

Figure 1.3: Equivalence between the OSI reference model and TCP/IP protocol

Considering the transport layer, TCP/IP has two protocols:

• Transmission Control Protocol (TCP) is a reliable transport protocol that guarantees delivery and ordering of transmitted packets. Because it is reliable, each packet carries a lot of control information, adding additional overhead and impacting the effective payload size. It is widely used in most current applications, especially web applications, which we will discuss throughout this book.
• User Datagram Protocol (UDP) is an unreliable transport protocol. This is a protocol that tolerates transmission failures. Due to this characteristic, little control information is needed in each packet, which means that the same packet compared to the TCP protocol has an increased payload size. This is very useful in real-time applications, such as video calls or Voice Over IP. Some online games use UDP as a protocol, such as Xbox Cloud Gaming and NVIDIA GeForce Now, as well as meeting tools (Zoom, Google Meet, or Microsoft Teams), and so on.

As we can see, protocols in both the seven-layer conceptual model and their implementation in the TCP/IP model are fundamental for building reliable applications. From this point on, we will focus on developing examples using the TCP connection-oriented protocol, as it provides the infrastructure for all communication between web servers and browsers.

It is important to note that this protocol stack is available and integrated into our operating systems. If you must implement an application that communicates with another, any operating system will provide a set of libraries your programming language will use. All this complexity is built in and available behind the scenes. You, as a programmer, do not need to access this entire protocol stack.