If you’ve ever sat in a tech meeting and nodded along while another engineer threw around terms like "Layer 7 load balancing" or "L4 routing," you aren't alone.
We talk about networking a lot in software development, but there’s a funny quirk in our industry: the model we learn in textbooks isn't exactly the model that runs the internet.
In our last deep dive, we talked about the OSI model a beautiful, theoretical 7-layer philosophy. But out in the wild? The entire world runs on the TCP/IP model.
Today, let's bridge the gap between theory and reality, figure out how data actually moves across the internet, and look at the only layers you actually need to care about as a software engineer.
The Reality Check: 7 Layers vs. 5 Layers
The OSI model breaks networking down into 7 distinct layers. But the TCP/IP model, which is what actually powers the internet today, condenses things down to just 5 layers:
- Application Layer
- Transport Layer
- Network Layer
- Data Link Layer
- Physical Layer
Wait, what happened to the Presentation and Session layers from the OSI model?
In the real world, they didn't disappear; they just got absorbed. When you are building a modern web app say, a Nuxt.js frontend communicating with a Laravel backend your browser and framework handle everything at once.
When you type "Hello" in a chat app, the Application Layer formats that text into JSON (what the Presentation layer used to do), compresses it, converts it to binary, and even checks if the other person is online with that little green dot (what the Session layer used to do). Because the Application Layer handles all of this heavy lifting, the TCP/IP model just groups them together.
A Crucial Developer Rule: Even though the TCP/IP model condensed the top layers, we still use OSI numbering in our everyday developer conversations! We still call the Application Layer L7. We call the Transport layer L4, Network is L3, and Data Link is L2. If you ever call the Application layer "L5," other engineers will look at you funny. Always stick to the L7 terminology!
Layer 4: The Transport Layer (TCP vs. UDP)
Once your application has prepped the data, it hits the Transport Layer. This is where we decide how the data is going to travel, and you have two main choices: TCP or UDP.
TCP (Transmission Control Protocol)
Think of TCP as the highly reliable, slightly slower courier who requires a signature on delivery. It is 100% controlled.
Imagine you are sending a text message that says "I LOVE YOU." If the data gets scrambled and arrives as "O I V E U Y," you're going to have a bad time. For text, JSON payloads, important API requests, or critical database transactions, we use TCP. It ensures every single piece of data arrives in the exact right order. When using TCP, your data is broken down into chunks called Segments.
UDP (User Datagram Protocol)
UDP is the fast, reckless delivery driver throwing newspapers onto your porch without stopping. It doesn't care if a few get lost in the bushes.
We use UDP for things like live video streaming. If a stream contains 10 million frames and a couple of them drop out, your screen might glitch for a fraction of a second, but the video keeps playing. You wouldn't want the whole live stream to pause just to retrieve one missing frame. When using UDP, your data is broken down into chunks called Datagrams.
Moving Down the Stack: L3 to L1
After the Transport Layer, the data keeps moving down the chain:
- Network Layer (L3): This is where IP addresses come in. Your data (the Segment or Datagram) gets tagged with the Sender's IP and the Receiver's IP. Once those are attached, the whole package is now called a Packet.
- Data Link Layer (L2): Here, we attach MAC addresses to figure out the physical hardware hops the packet needs to take.
- Physical Layer (L1): Finally, everything is converted into 1s and 0s raw electrical signals or light pulses shooting through cables.
A quick note for my fellow software engineers: You really only need to master L7, L4, L3, and L2. Unless you have a burning desire to become an electrical engineer, you can safely let the hardware folks worry about the Physical Layer!
A Quick Trip Back to 1969
You might be wondering: if OSI is the standard, why is TCP/IP so different?
It actually comes down to the Cold War. In 1969, the US Defense Department created an organization called ARPANET. They needed a decentralized network where data could survive even if computers or physical locations were destroyed in a war. Over the next decade, they actively developed the TCP/IP model.
It was messy, organic, and random. In fact, TCP was being used to send data long before IP addresses were even a standard! The beautifully organized, perfectly logical OSI model didn't actually come along until 1984 to try and make sense of it all. We teach OSI first because it's fundamentally easier to understand, but TCP/IP is the battle-tested system that won the internet.
Top comments (3)
Good side-by-side explainer on the OSI model and how it maps to real networking: ibm.com/think/topics/osi-model
For anyone who wants the official TCP spec, this is the current RFC: datatracker.ietf.org/doc/rfc9293/
Some comments may only be visible to logged-in visitors. Sign in to view all comments.