The OSI Model & TCP/IP

A Backend Developer’s Guide to the Internet.

Introduction:

In my life I always had a huge problem understanding how networking works, the OSI model was kind of blackbox for me. At some point I started asking if my more experienced colleagues understands those topics and I was surprised how many of them don’t understand this concept at all.

Table of Contents

1. For who is this article?
2. What is OSI and TCP/IP?
3. Why do we need it?
4. OSI & TCP/IP Architecture
5. The Postal Service Analogy
6. AWS Networking in Practice

For who is this article?

This particular series of articles are directed mainly to backend and frontend developers, but not only for them. If you are beginner DevOps Engineer, Product Owner, Manager, Scrum master or you are just curious how networking works — This article is also for you.

What can u expect?

Technical definitions are told to us on universities, bootcamps, networking courses and sometimes even in high schools (I went to one that tried to convince me that i really need that knowledge). I understand this “old school” approach, and i think it’s unavoidable to talk about such low level concepts without bringing in a tough technical definition, but in later part of this article I’ll try to clarify everything and make it as simple as possible by using postal service analogy.

What is OSI and TCP/IP model?

Those are standardised frameworks that defines the specific steps data must take to travel between devices. While OSI is a detailed 7-layer theoretical map used for troubleshooting, TCP/IP is the streamlined 4-layer reality that actually powers the modern internet.

Why do we need that?

Paragraph above is just a nice and very high level definition. It’s simple if you understand this concept — otherwise you just have to believe that it’s true. I don’t know how about you, but I hate when someone tells me “It just works like this” and expect me to just believe him. I think really crucial here is to understand why do we need OSI model. To really get into this we need to understand that on some level networking is just sending bits (1 an 0) to another device for example another computer through many routers switches and another networking devices. So let’s imagine that you would like to send some bits that contains your data to another device a friends computer for example. There is a lot of questions that could pop up in this scenario:

• How those bits could be transported?
• How would i know that i am sending it to my friend?
• How could i be sure that my bits will not be captured by anyone else in transit?
• If destination device is different than my, how would it know how to understand those bits?
• And so on..

All of this questions at the same time in some way are also answer for “Why do we need that?”. Someone had to ask those any many more questions to himself to create set of rules and standards so devices that are built based on them could understand and deliver ones and zeros in same way. One of those standards principals are the OSI and TCP/IP models.

OSI and TCP/IP models architecture:

This models are created based on idea of “layers”. Layer is an abstract representation of specific networking component that enables changes to be applied on only one exact layer, so it provides flexibility to upgrading how this model exactly work (to improve).

OSI Layers:

Layer 7 (Application) — The Sender generates a request via network-aware applications (like a browser or API client) by producing protocol-specific headers and payloads — for instance, an HTTP GET request with specific JSON-encoded body parameters. The Receiver parses these high-level instructions to trigger server-side logic, such as querying a database or executing a script, and then packages the resulting data into a response. This layer serves as the interface between the software application and the network stack, handling resource identification, user authentication, and determining the availability of communication partners.

Protocols: HTTP, DNS, SMTP, FTP

Layer 6 (Presentation) — Sender This layer takes the data from the Application and formats it. It handles Encryption (like turning that JSON into unreadable TLS ciphertext), Compression, and Serialization (converting a complex code object into a standard byte stream like UTF-8). Receiver reverses the process — decrypting the data and “un-formatting” it so the Application Layer can actually read the JSON or display the image correctly.

Protocols: SSL, TLS

Layer 5 (Session) — The Sender establishes a unique session ID to manage the dialogue state and place checkpoints in the data stream, which the Receiver uses to keep separate conversations organized and to resume the transfer from the last known good point if the connection is lost.

Protocols: RPC, NetBIOS, SOCKS

Layer 4 (Transport) — The Sender breaks the data into Segments and adds source and destination port numbers to ensure the data reaches the correct application (like Port 80 for web). This layer is responsible for error recovery (retransmission) and flow control to ensure that if a segment is lost, it is resent. The Receiver uses these sequence and port numbers to reassemble the data in the correct order and direct it to the right service.

Protocols: TCP, UDP

Layer 3 (Network) — The Sender encapsulates segments into Packets by adding source and destination IP addresses for global routing across different networks; the Receiver checks the IP address to see if the packet has arrived at the correct destination network.

Protocols: IP (IPv4/IPv6), ICMP

Layer 2 (Data Link) — The Sender packs packets into Frames and adds the source and destination MAC addresses for “hop-to-hop” delivery between physical devices on the same local network; the Receiver checks the MAC address to confirm that its specific hardware is the intended recipient of that frame.

Protocols: ARP (worth to notice is a fact that ARP may be considered as layer 2 and 3 protocol because it maps MAC address to IP address which is layer 3 protocol)

Layer 1 (Physical) — The Sender converts the frames into raw bits (1s and 0s) and transmits them as electrical, light, or radio signals across a physical medium; the Receiver detects these signals and converts them back into digital bits for the higher layers.

Protocols: Bluetooth, DSL (not at all protocols, but those are standards/technologies that are used by devices working on this layer)

TCP/IP Layers:

While OSI Model is very specific we have TCP/IP model that simplifies that and it has only 4 Layers.

Layer 4: Application (The Software Logic)

• Role: This layer collapses OSI Layers 5, 6, and 7 into a single space. For a backend dev, this is where your code lives. The Sender prepares the application data (like a JSON payload), handles its own encryption (via TLS/SSL libraries), and initiates the request. The Receiver parses the application-specific protocol to execute logic.
• Why it matters: Unlike the OSI model, TCP/IP doesn’t care how you format or encrypt your data; it treats everything from the HTTP header to the JSON body as “Application Data.”
• Protocols: HTTP/2, gRPC, WebSocket, TLS/SSL, DNS, SMTP.

Layer 3: Transport (The Reliability Engine)

• Role: Identical to OSI Layer 4. The Sender handles host-to-host communication, using ports to multiplex multiple services on a single IP. It manages the “Three-way Handshake” (SYN, SYN-ACK, ACK) in TCP to establish a virtual circuit. The Receiver tracks sequence numbers to ensure no data is missing or out of order.
• Why it matters: This is where you deal with timeouts, connection pooling, and “Head-of-Line blocking.”
• Protocols: TCP, UDP, QUIC.

Layer 2: Internet (The Global Router)

• Role: Equivalent to OSI Layer 3. The Sender handles logical addressing by wrapping segments into packets with source/destination IP addresses. The Receiver (often a router) uses routing tables to decide the “next hop” to get the packet closer to its destination.
• Why it matters: Understanding this layer is key for configuring VPCs, Subnets, and Load Balancers in cloud environments.
• Protocols: IPv4, IPv6, ICMP, BGP.

Layer 1: Network Access (The Physical Link)

• Role: Combines OSI Layers 1 and 2. The Sender manages the hardware-level details, mapping IP addresses to physical MAC addresses and converting data into bits for the physical medium (copper, fiber, or air). The Receiver strips away the hardware framing to pass the packet up to the Internet layer.
• Why it matters: While backend devs rarely touch the “wire,” this layer governs the raw latency and bandwidth limits of your infrastructure.
• Protocols: Ethernet, Wi-Fi (802.11), ARP.

Let’s simplify that now:

Right analogy to make this simple would be an international postal service:

• Layer 1 (Physical) is way of transporting letters it means layer one defines that our latter will be delivered using cars and vans and planes or ships etc. in general — different transport types.
• Layer 2 (Data link) would define a specific person that should get this message — for example first, last name with social security number or anything that is unique for this specific person (MAC Address).
• Layer 3 (Network) in this case is a ZipCode/Country/Address basically anything that can be used to specify right area where receiver should be (IP Address).
• Layer 4 (Transport) puts the letter in an envelope. If the letter is too long, you split it into two envelopes and label them “1 of 2” and “2 of 2” (segmentation). You also decide if it needs a “Return Receipt” (TCP) or just “Standard Mail” (UDP).
• Layer 5 (Session) is tricky i would say that it’s The “Office Receptionist.” They open the folder for a specific client, keep track of which documents have been processed so far, and close the folder only when the entire business transaction is finished. If the mailman (Layer 4) loses a letter, the Receptionist is the one who realizes the “Order” is incomplete and keeps the “Session” open until it’s fixed.
• Layer 6 (Presentation) defines that our letter is written on specific piece of paper in language that receiver could understand or easily translate to it’s own language (Takes message and translate it to 1 and 0).
• Layer 7 (Application) writes input of this letter. The message that you want receiver to get and process.

The distinction between these two models isn’t just academic; it reflects a fundamental divide between theoretical perfection and engineering pragmatism. As a backend developer, you use the OSI Model as a mental diagnostic map to isolate failures, while you build on the TCP/IP Model as the actual functional architecture of your stack.

In easy words — Think of the OSI Model like a detailed medical anatomy chart — you use it to point to exactly where it hurts when something breaks. Think of the TCP/IP Model like the actual circulatory system — it’s the functional, streamlined reality that keeps the body moving every day.

How networks are built? — AWS Cloud Engineer perspective

Now that we know how the OSI and TCP/IP models work, we can start using the benefits of existing solutions. As a DevOps / Cloud Engineer or Solutions Architect, you’re not going to consciously use any of these concepts in real life or… you just don’t know that you’re using them right now. I’d even jump into conclusion that you could be a very successful Cloud Engineer without understanding the difference between Layer 2 and Layer 3. But understanding these models, and then how UDP, TCP and other protocols actually work, is what makes you a quality engineer — one who can build networking solutions with full awareness of every detail in his work.

In this part I’d like to show you an example of a networking architecture built with AWS services, with each service explained in terms of TCP/IP model layers.

How traffic flows in example AWS networking architecture

A client wants to reach our EC2 over HTTPS. It first asks Route 53 for the IP, then sends the request across the internet to our VPC. The Internet Gateway translates the public IP to the instance’s private IP and drops the packet into the VPC. The VPC router reads the destination, consults the route table, and forwards the packet toward the correct subnet. The NACL filters it at the subnet boundary, the security group filters it at the instance’s ENI, and finally the EC2 instance completes the TCP handshake and the application serves the response. The response travels back the same path in reverse.

AWS Services to layer correlation

• Layer 7 — Application → Route 53, application on EC2. Route 53 is DNS, which is an application-layer protocol despite riding on UDP. The app on EC2 (nginx, your service) parses HTTPS, handles TLS, and produces the response.
• Layer 4 — Transport → Security Group, TCP stack on EC2. The security group is stateful and filters on protocol + port + source — pure transport-layer policy. The EC2’s kernel TCP stack handles the 3-way handshake, sequencing, and reliable delivery.
• Layers 3 and 4 — Network + Transport → Network ACL. The NACL is stateless and filters on both IP CIDR (L3) and port range (L4), which is why it straddles two layers.
• Layer 3 — Network → Internet Gateway, VPC Router, Route Table. The IGW does NAT between public and private IPs. The router reads the destination IP from each packet. The route table is the lookup structure that tells the router where to send it. Together they are the entire Layer 3 logic of the VPC.
• Layer 2 — Link → ENI. The ENI carries the MAC address and handles Ethernet framing inside the host. AWS hides the rest of Layer 2 (no ARP visibility, no switching access) — it’s the only place this layer surfaces.
• Layer 1 and most of 2 are abstracted away by AWS. You never touch physical cabling or switching fabric. This is the trade-off of the cloud — you give up visibility at the bottom of the stack in exchange for not having to manage it.

Final Thoughts

Networking is one of those topics that feels intimidating from the outside but clicks surprisingly fast once you see it as a series of simple, layered responsibilities. The OSI model gives you the vocabulary to diagnose problems, TCP/IP gives you the reality you build on every day, and AWS gives you managed abstractions over most of it — whether you realize it or not. You don’t need to memorize every protocol at every layer, but knowing why the layers exist and what problem each one solves will make you a sharper developer, a better debugger, and someone who can have an actual conversation when the network is the problem. In the next article, we’ll go deeper into TCP and UDP — how the handshake actually works, when you’d choose one over the other, and what happens when things go wrong at the transport layer.