In the first post in the series, we asked what might be happening between a laptop and a remote API you called. How does the network handle that request and know how to get it to the proper location? What layers does it travel up and down?
The TCP/IP stack is one model to think about these different layers. The OSI model is another option, but we will use the TCP/IP stack for this blog series as it is more straight-forward. The stack defines four layers (from highest to lowest): application, transport, internet and network access or link layer. This is captured in the image below from here
Thinking of our API request, we can start to walk down the layers of the stack. At the application level we would likely be using the http or https protocols to make a request to a REST API. Other protocols such as SSH and DNS also function at the application level. HTTP defines its own headers and payload structure. The mozilla web documentation provides some additional details here as well as the image below.
As we make our way to the next level of the networking stack, transport, we encounter two common protocols: TCP and UDP. TCP is commonly used when it is important to have reliable data delivery. It automatically retransmits if it does not receive acknowledgements. UDP prioritizes speed and is "best effort". UDP is commonly used for things like live streaming or video, where there is less overhead, and some packet loss is expected.
Given HTTPS's focus on reliable delivery of actions against APIs and websites, it leverages TCP. The image below from Loyola's intro to computer networking course found here, outlines the TCP connection and acknowledgement to ensure all data arrives as expected at the destination. UDP on the other hand is connectionless and would not verify that the data had arrived.
At our next stop down the stack we encounter the internet protocol or IP. IP version 4 (IPv4) is the most popular version in use today. IP version 6 also exists, but its adoption has been slow, and you will rarely encounter it on enterprise networks. IPv4 addresses use 32 bits and are made up of four octets. This allows for 256 values in each octet. For example 10.1.1.1 could be the IP address of our API. Similar to a physical envelope, we would add our IP address as the destination so various network devices would know where to send the packet and our laptop address is included as the source. The image below outlines the structure of an IP packet as outlined in the post it was sourced from.
At the lowest stop on the stack (network access), we would encounter wired and wireless protocols. Ethernet and Wi-Fi operate at this level and defines how data can leave your device to communicate with others on the same private network. For our API request and laptop this might mean getting to the access point providing Wi-Fi coverage to your desk.
As your request makes it way down the various layers it uses a technique called encapsulation. When it gets to the HTTPS server on the other side (or any networking devices in between), the necessary layers are de-encapsulated to make sure it gets to the right handler.
Revisiting the image from the beginning of the blog we can see how each layer builds on the others to create a "frame" which is the name of the combined payload at the lowest level. At the internet layer it is known as a packet or datagram, and a segment at the transport layer.
Now that we have a solid understanding of the layers of the TCP/IP stack we will use the next blog post to explore how the various devices you would encounter on an enterprise network would handle these frames/packets after it has left your laptop.