Let’s peel back the layers and talk about the OSI model in a more human, approachable way. Because honestly, the story behind it is rather fascinating—and a little complicated, too.
First off, I’ve often described the OSI model in terms of “responsibilities,” breaking them down neatly by layer—physical stuff like bits being carried, data link hop-by-hop, network routing end-to-end, and so forth. It’s a useful way to teach the basics, especially when you’re just starting out, but it’s not the whole story. That’s because, in reality, the OSI model isn’t exactly how things play out in the real world.
The truth? Back in the 70s when the OSI was born, it was supposed to be the gold standard for understanding networking. But development was bogged down by too many cooks—committee meetings, endless debates, and a lot of waiting. Meanwhile, a simpler, more practical model was emerging: TCP/IP. This was built to work right out of the gate, with fewer stovepipes and more focus on getting things done.
Over time, as industries kept waiting for the OSI to finalize, hardware and software developers started building to TCP/IP standards. Eventually, the industry just kind of gave up hope that the OSI model would ever become a reality. Today, when you configure your Windows IP settings, you’re actually setting up TCP/IP, not OSI.
If you’re curious, the full story of its rise and fall is worth a read. There’s a great article here that dives into it: IEEE Spectrum’s “The OSI—the Internet That Wasn’t”.
So, where does that leave us in 2024? For learners trying to piece everything together, the OSI model isn’t just some ancient relic—it’s stuck around for educational reasons. When taught well, it helps explain where each piece of data and protocol fits into the picture. I’ve gotten plenty of comments from people saying my videos helped make networking click for them—that’s because the model provides a framework, even if it’s not the practical backbone today.
But it’s crucial to understand that not everything fits perfectly into those neat layers. For example, I once talked about HTTP cookies as part of the Session Layer (Layer 5). But think about it: you need the application to interpret those 1s and 0s first—something that belongs to the Presentation Layer (Layer 6). So, responsibilities don’t always stick rigidly to a specific layer.
What’s more important is grasping it as a series of “layers of abstraction.” Something handles routing — the end-to-end delivery of packets and IP addresses. Another component makes sense of incoming data streams. And if you want your services to be flexible across hardware and locations, you need a way to identify sessions independently of MAC addresses or IPs.
Now, if we switch gears and look at the modern TCP/IP model, the same “responsibility-based” teaching still works pretty well. It’s a cleaner, simpler way to understand networks without all the historical complexity. I personally prefer focusing on the TCP/IP approach for teaching because it strips things down, making it easier to see how everything fits together.
