The OSI model still explains networking well

The OSI model is a seven-layer reference model for how network communication works.

The OSI model is older than the modern internet stack, but it still shapes how engineers talk about networks. The model was published in 1984 as ISO 7498 and ITU-T X.200, and it breaks communication into seven layers: Physical, Data Link, Network, Transport, Session, Presentation, and Application.

That split sounds academic until you debug a packet drop, trace a TLS issue, or explain why a VPN behaves the way it does. The model gives you a shared vocabulary for everything from cables and frames to HTTP and DNS.

Why the OSI model still matters

The internet did not adopt OSI protocols wholesale, but the model itself survived because it is practical. It gives teams a way to isolate problems: is the issue in the wire, the switch, the router, the transport protocol, or the app?

That kind of separation is useful in classrooms, on call rotations, and design reviews. A junior engineer can learn that Ethernet frames live below IP, while a senior engineer can use the same model to explain why a QUIC issue is not the same as a DNS issue.

The Wikipedia article notes that the OSI model became the standard framework for discussing and teaching networking, even though the original OSI protocols did not win broad adoption. That split is the key to understanding its legacy: the model won the argument about language, while TCP/IP won the market.

• ISO 7498 formalized the model in 1984.
• ITU-T X.200 carries the telecom version of the same reference model.
• RFC 1122 and RFC 1123 define the Internet protocol suite that powered the web.
• IETF guided the Internet stack with a less rigid structure than OSI.

How the seven layers break down

Each OSI layer has a narrow job, and that is the whole point. The lower layers move bits and frames, the middle layers route and transport data, and the upper layers deal with user-facing communication.

Here is the practical version:

• Layer 1, Physical: signals, cables, radio, and raw bits.
• Layer 2, Data Link: frames, MAC addresses, and local delivery.
• Layer 3, Network: IP addressing and packet routing.
• Layer 4, Transport: TCP, UDP, QUIC, and end-to-end delivery.
• Layer 5, Session: session setup and coordination.
• Layer 6, Presentation: encoding, compression, and encryption formats.
• Layer 7, Application: HTTP, SMTP, DNS, SSH, and similar user services.

That list is more than a mnemonic. It tells you where to look when something fails. If a cable is bad, layer 1 is the suspect. If a packet never reaches the next hop, layer 3 gets attention. If a browser cannot talk to a site even though ping works, layer 7 or layer 6 may be the problem.

The article also points out that OSI describes communication as peer-to-peer exchange of protocol data units, or PDUs, between matching layers on different hosts. That detail matters because it shows the model is about abstraction, not just a classroom diagram.

“The Open Systems Interconnection model is a seven-layer reference model.” — International Organization for Standardization, ISO 7498

OSI vs TCP/IP, in real numbers

The biggest reason OSI is still discussed is the contrast with TCP/IP. OSI is more formal and more granular. TCP/IP is simpler and closer to what the internet actually used at scale.

That difference shows up in the number of layers, the level of abstraction, and the way each model treats the software stack.

• OSI: 7 layers, with separate Session and Presentation layers.
• TCP/IP: usually described in 4 or 5 layers, depending on the textbook.
• OSI: designed as a reference model first, protocol suite second.
• TCP/IP: deployed as working internet protocols first, model second.

The Wikipedia history section makes the tradeoff clear. OSI emerged from international standardization work in the late 1970s and early 1980s, while TCP/IP spread through real networks and became the foundation of the internet. Engineers did not pick the most elegant model. They picked the one that worked everywhere, fast.

That outcome still affects how people learn networking. OSI is the clean teaching model. TCP/IP is the stack you actually configure, monitor, and secure.

What the model gets right today

OSI is old, but it still maps well to modern troubleshooting. A cloud outage can involve physical links, routing tables, TLS certificates, API gateways, or application code, and the model gives you a disciplined way to separate those layers.

It also helps when protocols blur the boundaries. GRE, for example, can look like a network-layer protocol, but when encapsulation happens only at the endpoint it behaves more like a transport mechanism carrying full frames or packets. That kind of edge case is exactly why the model remains useful: it gives engineers a place to talk about exceptions without losing the structure.

For teams that work across infrastructure and software, the model is still a common map. Network engineers, SREs, security teams, and backend developers can all point to the same layers and mean roughly the same thing.

If you want a practical takeaway, use OSI as a diagnosis tool, not as a religion. When a service breaks, ask which layer owns the failure, then test only that layer first. That habit saves time, and it keeps you from blaming DNS for a bad cable or blaming the app for a routing problem.

For more networking explainers, see our guide to TCP/IP vs OSI and our breakdown of how DNS actually works.

Bottom line for engineers

The OSI model survived because it is useful, not because it won the internet. It gives you a clean way to explain where data lives, where it changes form, and where a failure probably sits.

My bet is that the model will keep its place in documentation, interviews, and incident reviews even as protocols like QUIC and encrypted DNS keep blurring old boundaries. The next time a network problem hits, the best question is still the oldest one: which layer broke first?