OSI Model: Explanation & Insights

A seven-layer teaching map of how networks work — not how the internet is actually built.

What It Is

The OSI model (Open Systems Interconnection) is a way of slicing "how do two computers talk" into seven stacked layers, each responsible for one job and trusting the layer below to have done its own. From the bottom: Physical, Data Link, Network, Transport, Session, Presentation, Application — wires at the bottom, your web browser at the top, and a tidy progression of responsibility in between. It was standardised by the ISO in 1984 as a grand blueprint for how all networking should be built.

Here is the thing nearly every tutorial leaves muddy, and the thing this page exists to make permanently clear: the OSI model is a teaching map, not the territory. The internet does not run on OSI. It was never built on OSI. The protocols you actually use every day — IP, TCP, UDP, HTTP — come from a different, older, simpler family that predates the OSI standard and beat it in the market: the TCP/IP model, with just four layers. OSI's grand seven-layer design lost the war; its top three layers (Session, Presentation, Application) collapse into one in the real world, and almost nobody runs the protocols ISO designed for them.

So why does every networking course, certification, and interview still drill the seven layers? Because OSI won a different prize: it became the shared vocabulary. When an engineer says "that's a layer-3 problem" or "the bug is at layer 7," everyone in the room instantly knows whether they mean routing or the application, regardless of which protocols are actually in play. OSI failed as a blueprint and succeeded as a language. That's the honest framing — learn it as a map for talking and thinking, hold it loosely as a description of reality, and you'll have exactly the right relationship with it.

The Seven Layers, Anchored to Something Real

Layers are abstract until you tie each one to something you can touch. So for every layer, here's the job and a concrete thing on your server that lives there. Read top-down (the way data flows out of an app) or bottom-up (the way you debug) — both are useful.

Layer 7 — Application. The protocol your software actually speaks: HTTP for the web, DNS for name lookups, SSH for remote login, SMTP for mail. This is the layer you write code against and the layer a curl command lives in. When a page loads but shows an error, or a DNS name won't resolve, you're looking at a layer-7 problem.

Layer 6 — Presentation. Data representation: encryption, compression, character encoding — turning the application's data into bytes on the wire and back. In the real TCP/IP world this isn't a separate layer at all; TLS (the encryption behind HTTPS) is the textbook "layer 6" thing, but it actually sits awkwardly between layers and nobody loses sleep over where exactly.

Layer 5 — Session. Establishing, maintaining, and tearing down a conversation between two applications. The classic example is hard to point at on a modern Linux box because TCP/IP folds session management into the transport and application layers — which is the first big clue that the top three OSI layers are more theory than practice.

Layer 4 — Transport. Getting a stream or a datagram between two programs (not just two machines), identified by port number. This is TCP (reliable, ordered, acknowledged) and UDP (fast, connectionless, best-effort). "Connection refused" and "connection reset" are layer-4 events. When you ask which program gets the packet on a machine that's running a hundred of them, port numbers — and therefore layer 4 — are the answer.

Layer 3 — Network. Getting a packet from one machine to another across networks, by logical address. This is IP — the addresses like 10.0.0.5 and 192.168.1.1, the routing tables, the traceroute hops, and NAT rewriting addresses at your router's edge. The diagnostic protocol ICMP, behind ping, lives here too. "No route to host" and "network unreachable" are layer-3 problems.

Layer 2 — Data Link. Getting a frame between two devices on the same physical segment, addressed by MAC address — the hardware ID burned into your network card. Ethernet and Wi-Fi are layer-2 technologies. ARP (which maps a layer-3 IP to a layer-2 MAC) and your switch both work here. When two machines on the same LAN can't see each other but the cable's plugged in, you're often hunting at layer 2.

Layer 1 — Physical. The actual electrons, photons, and radio waves — the cable, the fibre, the Wi-Fi signal, the port on the back of the NIC. Layer 1 is "is it plugged in and is the wire intact?" — unglamorous, and the answer to a startling fraction of "the network is down" tickets. A NIC reporting packet errors or a link that won't come up is a layer-1 story.

7  Application   HTTP, DNS, SSH, SMTP        <- your software speaks this
6  Presentation  TLS, compression, encoding  } in practice these three
5  Session        connection management       } collapse into "Application"
4  Transport     TCP, UDP, port numbers      <- which program gets it
3  Network        IP, ICMP, routing, NAT      <- which machine, across networks
2  Data Link      Ethernet, MAC, ARP, switch  <- which device, same segment
1  Physical       cable, fibre, Wi-Fi, NIC    <- electrons and photons

OSI vs The Model The Internet Actually Uses

The internet runs the TCP/IP model, which is the same idea with fewer layers because the real protocols never needed seven. Here's the translation table — keep it handy, because half of networking conversations are someone silently doing this mapping in their head:

TCP/IP (real)	OSI layers it covers	What lives there	What breaks
Application	7, 6, 5	HTTP, HTTPS, DNS, SSH, TLS	bad response, cert expired, name won't resolve
Transport	4	TCP, UDP, ports	connection refused / reset / timed out
Internet	3	IP, ICMP, NAT, routing	no route, unreachable, dropped packets
Link	2, 1	Ethernet, MAC, NIC, cable, Wi-Fi	link down, packet errors, cable out

Notice what happened: OSI's top three layers fused into one "Application" layer (because real apps just do their own encoding and session handling), and the bottom two fused into one "Link" layer (because the cable and the framing are sold together as one Ethernet card). The four-layer model is what the protocols were designed around; the seven-layer model is the academic ideal they were compared against. Both are useful — but if someone tells you the internet "is built on the OSI model," they've politely got it backwards.

Note

The mismatch is why people argue about which layer TLS is on (5? 6? 7?) or where NAT belongs. The honest answer is that OSI's neat boundaries don't perfectly fit the messy real protocols — so don't waste energy forcing them. The numbers are a communication tool, not a law of physics.

How to Actually Use It

The layer model earns its keep as a debugging discipline, not a quiz answer. When something networked breaks, walk up the stack — each layer you confirm working eliminates everything below it as the cause:

ip link show              # L1/L2: is the NIC up, is the link present?
ip addr show              # L3: does the machine have an IP address?
ping 192.168.1.1          # L3: can ICMP reach the gateway / a host?
traceroute example.com    # L3: where along the path do packets die?
dig example.com           # L7/DNS: does the name resolve to an address?
curl -v https://example.com   # L4+L7: open TCP, do TLS, send HTTP, read status

That sequence is the seven layers turned into muscle memory. Link up? IP assigned? Gateway reachable? Path clear? Name resolves? Connection opens, handshake completes, server answers? The first step that fails names the layer, and the layer names the fix. A failing ping with a working dig tells a very different story than the reverse — and you can read that story precisely because you put each tool on a layer.

This is also why monitoring is layered. Checking that a server is "up" can mean layer 3 (does it answer ping?), layer 4 (does the port accept a TCP connection?), or layer 7 (does HTTP return 200 OK with the right content?). A box can be perfectly reachable at layer 3 while its web app is throwing 500s at layer 7 — "up" at one layer, "down" at another. Naming the layer is naming the question.

Be Opinionated About It

Two honest opinions, because the neutral version of this page would do you a disservice.

First: learn the layer numbers, because everyone debugs and argues by them. "Is it a layer-1 problem or a layer-2 problem?" is a real, useful question your colleagues and your vendor's support desk will ask you, and you want to answer it without translating. The numbers are dense, shared shorthand — knowing them is the difference between describing a symptom for ten minutes and saying "layer 3, no route" and being understood instantly. (Yes, there's the old joke about "layer 8" being the user, and "layer 9" being politics and budget. It survives because it's true: an awful lot of "network problems" live above layer 7. Worth a smile, and worth remembering when the cables all check out.)

Second: don't treat OSI as gospel. It's a 1984 committee design for a networking future that didn't happen, and its seven crisp layers describe the internet about as well as a museum diorama describes a living city. The protocols you run came from somewhere else and don't respect the boundaries — TLS smears across "layers" 5–7, NAT reaches up from layer 3 to peek at layer-4 ports, and "session" as a distinct layer barely exists. Use OSI the way a sailor uses a star chart: indispensable for orientation and conversation, but you steer by the actual coastline. Learn the map, then learn that the territory is messier — that pairing is what separates someone who's memorised seven words from someone who can actually fix a network.