The Layered Model — OSI and TCP/IP
Networking is built in layers so that each one solves a single problem and trusts the layer beneath it to have solved its own. The application worries about meaning; the transport worries about reliable delivery to a process; the internet layer worries about getting a packet across networks; the link layer worries about one hop of wire. None of them needs to understand the others — a web browser does not care whether the bytes travel over fiber or Wi-Fi, and Ethernet does not care whether it is carrying HTTP or a video call.
Two models describe these layers, and engineers use both at once. The seven-layer OSI model is the shared vocabulary — when someone says "that's a layer 7 problem" they mean OSI. The four-layer TCP/IP model is what actually runs on every machine. Knowing how the two line up, and where the tidy diagram stops matching reality, is what lets you place any protocol and any failure at the right layer.
The Seven OSI Layers
The OSI reference model numbers seven layers from the wire up. Layer 1, physical, is signals on a medium — voltages, light, radio. Layer 2, data link, frames those bits and addresses one hop with MAC addresses; switches live here. Layer 3, network, addresses and routes packets across networks with IP; routers live here. Layer 4, transport, delivers to a specific process and adds reliability — TCP and UDP.
The top three are fuzzier in practice. Layer 5, session, and layer 6, presentation, cover dialog control and data representation — concerns that real stacks fold into the application or into libraries like TLS. Layer 7, application, is the protocol that carries meaning: HTTP, DNS, SMTP. In day-to-day work engineers really only invoke four of the seven numbers — 2, 3, 4, and 7 — and treat 5 and 6 as historical.
The Practical Four-Layer TCP/IP Model
The model that matches what runs on the host collapses OSI into four layers. The link layer (OSI 1–2) moves frames over one hop. The internet layer (OSI 3) is IP, getting a packet from any host to any other across networks. The transport layer (OSI 4) is TCP or UDP, delivering to a process with or without reliability. The application layer (OSI 5–7) is everything the program speaks.
This four-layer view is not a simplification for beginners — it is the architecture the protocols were actually designed around, and the OSI seven-layer model was a parallel standardization effort that the TCP/IP stack outlived. When the two disagree, the TCP/IP grouping is the one that reflects how the code is organized.
Why Layering, and the Narrow Waist
Layering buys independent evolution. Wi-Fi 7 replaced Wi-Fi 6 at the link layer without touching IP; HTTP/2 replaced HTTP/1.1 at the application layer while still riding the same TCP transport beneath it. Each layer presents a stable interface, so the layers above and below can change underneath it. This is why the internet could absorb forty years of new physical media and new applications without a redesign.
The keystone is that the model is wide at the top and bottom but pinched to a single protocol in the middle — the narrow waist of IP. Hundreds of applications and dozens of link technologies all meet at one internet layer: everything runs over IP, and IP runs over everything. That one mandatory common layer is what makes any application reachable over any medium, and it is the single most important structural fact about the internet.
Where the Model Leaks
The clean diagram stops matching reality at the edges, and pretending otherwise causes confusion. TLS sits awkwardly between transport and application — people call it "layer 6," or "layer 4.5," and neither is quite right; it is encryption bolted onto the transport that the application drives. Tunneling breaks the layering outright: a VPN carries IP packets inside other IP packets, so layer 3 ends up nested inside layer 3.
Middleboxes leak the model in the other direction. A layer-7 load balancer reads HTTP — an application-layer concern — to make a forwarding decision, reaching up several layers from where a forwarder "should" operate. The model is a map, not the territory: use it to locate a protocol or a fault quickly, then expect the real stack to have seams the diagram does not show.
OSI is the seven-layer reference vocabulary (physical, data link, network, transport, session, presentation, application). Use it for naming and discussion — "that's an L7 rule," "the problem is at L2." Its session and presentation layers have no clean counterpart in real stacks.
TCP/IP is the four-layer model the protocols were built around (link, internet, transport, application). Use it as the mental model for how the code is actually organized. When the two disagree, trust this one.
- Treating the OSI model as an implementation rather than a reference. No mainstream stack has discrete session and presentation layers; insisting code map onto all seven leads nowhere.
- Arguing about which single layer TLS "is." It spans the seam between transport and application by design; the useful statement is what it does, not which number to assign it.
- Expecting clean layer boundaries on the wire. Tunnels nest layer 3 inside layer 3 and L7 load balancers read application data to forward — real paths cross layers the diagram keeps separate.
- Confusing a switch and a router because both "move packets." A switch forwards frames at layer 2 by MAC; a router forwards packets at layer 3 by IP — different layers, different scope, different failure modes.
- Forgetting the narrow waist. Assuming an application needs to know its link medium misses the whole point: it speaks to IP, and IP hides whether the hop is fiber, copper, or radio.
- Locate a fault by layer first: is the link up (L2), does it have a route (L3), is the port answering (L4), is the application responding (L7)? Naming the layer narrows the tools to reach for.
- Use the four-layer TCP/IP model to reason about how a packet is built and the seven-layer OSI model to communicate, since the rest of the industry speaks in OSI numbers.
- Describe what a protocol does instead of forcing it onto one layer when it straddles a seam, as TLS and QUIC do. The behavior is unambiguous even when the layer number is contested.
- Remember the narrow waist when integrating anything: if it speaks IP it can ride any medium, and if it does not, it will need a gateway to translate before it reaches the internet layer.
- Treat middleboxes as deliberate layer violations and account for them — an L7 proxy or a NAT changes assumptions that a strict layered reading would say are invariant.
Knowledge Check
What is the "narrow waist" of the internet model, and why does it matter?
- IP as the single common internet-layer protocol that every application and every link technology meets at
- TCP as the one transport protocol that every connection on the internet must use
- The physical layer, because all traffic ultimately becomes the same electrical signal on the wire regardless of its origin
- HTTP, because nearly all modern application traffic is carried inside it
An engineer says a load balancer is doing "L7 routing." What does that tell you about how it makes decisions?
- It reads application-layer data such as the HTTP path or headers to decide where to forward
- It forwards purely by destination IP and port without ever inspecting the contents of the request
- It switches frames by MAC address on the local segment
- It selects which physical cable to send the signal down
Why do session and presentation (OSI layers 5 and 6) rarely appear as distinct layers in a real stack?
- Real stacks follow the four-layer TCP/IP model, which folds those concerns into the application layer and libraries
- Routers transparently implement both of them on every hop
- Modern security standards prohibit using them for safety reasons
- The transport layer already provides full session and presentation services as a built-in part of every TCP connection
You got correct