Computer Networks Foundations

The OSI Reference Model

Seven layers, what each one is for, why nobody actually deploys all seven, and where the model still helps reasoning.

Concept Foundational
7 min read
osi layered-model fundamentals networking-basics

Summary#

The OSI (Open Systems Interconnection) reference model is a seven-layer abstraction for thinking about networking. It was standardised by ISO in 1984 as the future-proof way to interconnect heterogeneous systems. It lost. The Internet runs on TCP/IP, which is a flatter four-layer model. OSI nonetheless survived as the lingua franca for talking about networks — you’ll hear “this is a Layer 7 problem” or “it’s a Layer 2 loop” in every operations channel of every company.

The model’s value is conceptual: it forces you to identify which layer owns a given concern (addressing, ordering, framing, encryption, presentation), and which peer your code is actually talking to. Once internalised, almost every networking question collapses to “which layer, and what’s the header at that layer.”

Why it matters#

Engineers who can name the layer of a failure debug faster. “DNS is down” is Layer 7. “I can’t ARP my gateway” is Layer 2/3 boundary. “TLS handshake fails” is Layer 6 sitting on Layer 4. The model gives you a vocabulary, and the vocabulary is shared across vendors, RFCs, and incident channels.

It also matters for protocol design and selection. Should you put your reliability at the transport layer (use TCP) or build it in the application (use UDP plus your own ARQ, the QUIC bet)? Should this be solved with a Layer 4 load balancer or a Layer 7 one? Where do you terminate TLS — at the edge proxy (Layer 7 termination) or end-to-end? Each of those is a layer-choice question.

Finally, the OSI numbers leak into product specs and job descriptions. A “Layer 3 switch” is a router with switching ASICs. A “Layer 7 firewall” inspects HTTP headers. A “Layer 4 load balancer” hashes by 5-tuple. Knowing what number maps to what behaviour is table stakes.

How it works#

The seven layers, from the wire up:

Layer 7 — Application   HTTP, DNS, SMTP, SSH, gRPC
Layer 6 — Presentation  TLS, character encoding, MIME, compression
Layer 5 — Session       RPC framing, session resumption, SOCKS
Layer 4 — Transport     TCP, UDP, QUIC, SCTP
Layer 3 — Network       IP, ICMP, IPsec routing
Layer 2 — Data Link     Ethernet, Wi-Fi MAC, PPP, ARP
Layer 1 — Physical      copper, fiber, radio, NRZ encoding

The model is strict about one rule: each layer talks peer-to-peer with the same layer on the other end, and uses the abstraction provided by the layer below. Layer 4 on host A talks to Layer 4 on host B — neither one cares what Layer 3 did to get the segment across. That’s the whole point of layering: each layer hides its mess from its neighbour above.

What each layer actually does#

  • L1 Physical — turn bits into signals on the medium (voltage, light, RF). Encoding, modulation, clock recovery. Cables, transceivers, repeaters.
  • L2 Data Link — frame bits into packets, detect (sometimes correct) errors, arbitrate access to a shared medium. MAC addresses, CRC, switches, Wi-Fi access points.
  • L3 Network — global addressing and forwarding. IP is the canonical L3 protocol — assigns 32-bit (v4) or 128-bit (v6) addresses, routers forward datagrams hop by hop.
  • L4 Transport — end-to-end delivery between processes. Multiplexes via port numbers. TCP adds reliability, ordering, flow and congestion control; UDP is bare multiplexing plus a checksum.
  • L5 Session — open, manage, and close logical sessions. In practice, almost nothing modern lives here on its own — TLS resumption and SOCKS are about the closest.
  • L6 Presentation — serialisation, encryption, compression. TLS lives nominally here; so do character-set conversions and MIME.
  • L7 Application — what users see. HTTP, DNS, gRPC, IMAP, SSH. Everything an app developer writes against.

Encapsulation across layers#

A packet picks up a header at every layer on send and sheds one at every layer on receive. By the time an HTTP GET reaches the wire, it’s wrapped in TCP, then IP, then Ethernet:

+-------------------+-----------------+----------------+----------------+
| Ethernet header   | IP header       | TCP header     | HTTP payload   |  + Ethernet FCS
+-------------------+-----------------+----------------+----------------+

The receiver does the reverse: strip Ethernet, hand the IP datagram to its IP stack; strip IP, hand the segment to TCP; strip TCP, hand the bytes to the HTTP parser. Each layer reads only its own header.

Variants and trade-offs#

OSI (7 layers) — pedagogically clean separation of concerns. Distinguishes session, presentation, application. Used as common vocabulary in incident channels and vendor docs. The reference standard.
TCP/IP (4 layers) — link, internet, transport, application. What the Internet actually runs. Collapses OSI’s L5/L6/L7 into a single application layer because nobody built standalone session or presentation protocols at scale.

The reason OSI lost is historical and pragmatic. ISO’s process was slow and consensus-driven; the IETF shipped TCP/IP first, running on real research networks (ARPANET, NSFNET). By the time OSI’s protocols (TP4, CLNP, X.400) were ready, TCP/IP had won the mindshare and the deployments. ISO’s session and presentation layers turned out to be solved adequately inside application protocols (HTTP headers handle most of L5/L6 concerns).

The model still helps reasoning when you ask “what layer owns this?” Examples:

  • Encryption. Could be L2 (MACsec), L3 (IPsec), L4 (DTLS), L6 (TLS), L7 (app-level). Each has different trust assumptions and operational properties.
  • Reliability. Usually L4 (TCP). But could be L7 (HTTP retries on a UDP-based QUIC) or L2 (Wi-Fi link-level retransmissions before frames even reach IP).
  • Load balancing. L4 LB hashes by 5-tuple (cheap, opaque to payload). L7 LB parses HTTP and can route by path/host/header (smarter, more expensive).
  • Addressing. L2 (MAC) is locally unique on a LAN segment. L3 (IP) is globally unique on the Internet. L4 (port) is per-host. L7 (DNS name) is what humans use.
Where does TLS actually live?

Nominally L6 (presentation). In practice, it runs on top of TCP (L4), implements its own handshake state machine that looks session-y (L5), and is invoked by L7 applications. Real protocols don’t respect the OSI boundaries cleanly — TLS exists somewhere in the L5/L6/L7 cloud. The honest answer in interviews: “it sits between TCP and the application; the OSI bucket is L6 by convention.”

When this is asked in interviews#

Almost always as a warm-up. Expect “name the OSI layers” or “what’s the difference between OSI and TCP/IP” at the start of a networking screen. The trap is treating it as a memorisation question — strong candidates give the layers, then immediately pivot to why the model is useful (vocabulary, boundary-of-concerns) and where it leaks (TLS doesn’t sit cleanly).

Common follow-ups and what answers good ones:

  • “Which layer does TLS live at?” — L6 by convention, but it’s tangled with L4 (sits on TCP) and L5 (session resumption). Honest answer is better than dogmatic one.
  • “Why doesn’t the Internet use OSI?” — IETF shipped first, ISO’s protocol suite (TP4/CLNP) was late and complex, market converged on TCP/IP, OSI’s session and presentation didn’t justify their own layer.
  • “What’s the difference between a Layer 3 switch and a router?” — functionally none; “Layer 3 switch” is a marketing term for a router built on switching ASICs (fast, fixed-function forwarding) rather than CPU-based forwarding.
  • “Where would you put encryption in a system you’re designing?” — depends on threat model. L7 (app-level signing) for end-to-end. L6 (TLS) for in-transit. L3 (IPsec) for site-to-site VPN.

Asked most in infrastructure / SRE / network-engineering loops. Less in pure-product loops, where it’s a quick screening pass.

Search ESC

Keyboard shortcuts

Shortcuts are disabled while typing in inputs.