Skip to content
FollowtheDamnCode

OSI Model

The 7-layer mental model for where a networking problem actually lives.

Big idea

The OSI model breaks networking into seven layers, each wrapping the one above it, and its real value is as a debugging map: naming the failing layer keeps you from debugging at the wrong layer.

The idea

When your browser sends a request, it doesn't just launch bytes at the internet — it hands data down through a stack of layers, each one wrapping it with a bit more information, until it's an electrical signal on a wire. The receiving machine unwraps it back up through the same stack. The OSI model is the standard 7-layer description of that process.

You won't implement all seven layers by hand, but the model is genuinely useful as a mental map: when something breaks, "which layer is this actually a problem at?" is one of the fastest ways to narrow down a networking bug — a DNS failure, a TCP connection refused, and a malformed JSON body are three completely different layers, with three completely different fixes.

Think of it like

Sending a birthday gift, you wrap the present, put it in a padded box, seal the box with a shipping label, and hand it to a courier who loads it onto a truck with hundreds of other parcels. At the other end, every step is undone in reverse: the parcel comes off the truck, the label is checked, the box is opened, the paper comes off. If the gift never shows up, you ask whether the label, the truck route, or the box was the problem. The OSI model is that stack of packaging, with each network layer adding and later removing its own wrapper.

The seven layers, top to bottom

  1. Application — the protocols your code actually calls: HTTP, gRPC, WebSocket. This is where "what does this request mean" lives.
  2. Presentation — data formatting and translation: encryption (TLS), compression, character encoding. Making sure both ends agree on how the bytes are structured.
  3. Session — establishing, managing, and tearing down a conversation between two machines.
  4. Transport — end-to-end delivery between processes, via TCP or UDP. This is where "reliable and ordered" vs. "fast and best-effort" gets decided.
  5. Network — routing packets between different networks, via IP. This is where an IP address matters.
  6. Data Link — delivery between two directly-connected devices on the same physical network (Ethernet, Wi-Fi), addressed by MAC address rather than IP.
  7. Physical — the actual electrical, radio, or optical signal on the wire or through the air.

Why it matters in practice

Most day-to-day web work lives almost entirely at layer 7 (application) and layer 4 (transport) — an HTTP request over a TCP connection. But the model earns its keep the moment something's actually broken: "DNS won't resolve" is a layer 7 problem, "connection refused" is usually layer 4, and "nothing on this network can reach anything" is very often layer 1 or 2 — a bad cable, a misconfigured switch, or an interface that never came up. Knowing which layer you're debugging tells you which tool to reach for.

Encapsulation, briefly

Each layer on the sending side wraps the layer above it in its own header (and sometimes a footer) — an HTTP request gets wrapped in a TCP segment, which gets wrapped in an IP packet, which gets wrapped in an Ethernet frame. The receiving side does the exact reverse, peeling off one header per layer as the data climbs back up the stack. That's why a single HTTP request is, by the time it's actually on the wire, several layers of headers deep.

One HTTP request, wrapped layer by layer

By the numbers

Every layer adds a header. For one full-size packet on the wire:

LayerHeaderRunning total
Ethernet (2)14 bytes + 4-byte checksum18
IPv4 (3)20 bytes38
TCP (4)20 bytes (32 with timestamps)58
Payloadup to ~1,460 bytes1,518

For a full 1,500-byte packet, headers are ~4% overhead. For a 100-byte message — a chat message, a metric, a small API call — the same ~58 bytes of headers are over a third of what's sent. That's why systems that send many tiny messages batch them, and why protocols like gRPC multiplex many requests over one connection.

The layer also sets what a middlebox can see: a layer-4 load balancer reads 58 bytes of headers and forwards; a layer-7 one must reassemble and parse the HTTP request — more CPU per request, but it can route by URL or cookie.

Put these layers in order from the top (closest to your code) to the bottom.

curl reports "connection refused" right away. Which layer is the problem most likely at?

Key terms

  • OSI model — A standard seven-layer description of how data travels from an application down to a physical signal and back.
  • Encapsulation — Each layer wrapping the data from the layer above in its own header before passing it down.
  • Application layer — The top layer where protocols like HTTP define what a request means.
  • Transport layer — The layer where TCP or UDP handles end-to-end delivery between processes.
  • Network layer — The layer where IP addresses are used to route packets between networks.