OSI Model — The 7 Layers, Deep Dive

What is the OSI Model (and why does it survive)?

The OSI model is the most-taught and least-used reference framework in computing. It's in every networking textbook, asked in every interview, and yet nothing actually implements it. Real networks run TCP/IP, which collapses several OSI layers into one. So why bother?

Because the OSI model gives us shared vocabulary. When a senior engineer says "this is a Layer 7 problem", everyone instantly knows the issue is in the application — not in the cabling or the routing. It's the mental tool that turns "the website is down" into a structured diagnosis: "the TCP connection is up (L4), TLS handshake completes (L6), but the HTTP response is 500 (L7) — let's check the app logs."

Where it came from

The International Organization for Standardization (ISO) proposed OSI in 1984 — at a time when networking was being invented in many places at once and standards were a mess. OSI was supposed to be THE network stack of the future. It lost. TCP/IP, the messier, simpler, free Pentagon-funded protocol, took over.

But OSI's teaching value survived. Anyone explaining networking still falls back on the 7-layer cake.

The 7 layers, top to bottom

Mnemonics to remember the order

The 7 layers — quick tour

Watch the whole stack light up layer by layer:

Why the layered approach matters

Top to bottom — each layer in detail

We'll go through each layer top-to-bottom — the way the data actually flows from your app to the wire.

L7 — Application

The closest layer to you, the human. This is where browsers, web servers, mail clients, SSH clients, DNS resolvers — all the things you actually interact with — live.

L6 — Presentation

How data is REPRESENTED. Character encoding (UTF-8, ASCII), compression (gzip, brotli), encryption (TLS — debatable which layer, depends who you ask), media formats (JPEG, MPEG). Translates between app data and "bytes for the network".

L5 — Session

The most-debated layer. Originally meant: managing the conversation between two endpoints — dialog control, session checkpointing, restart after disconnect. In modern TCP/IP, most 'session' work happens in applications (cookies, JWTs, app-level reconnect logic) or in TLS.

L4 — Transport

Where TCP and UDP live. Adds the concept of ports — multiple processes on the same machine multiplex over one IP. Adds reliability (TCP) or doesn't (UDP). Adds flow + congestion control (TCP only).

L3 — Network

IP and routing. Takes a data chunk and figures out how to deliver it to any host on the planet by destination IP. Hops through routers. Best-effort: no reliability, may drop / dup / reorder.

# See L3 in action — show a packet's journey
traceroute google.com
# Each line = one router hop = one L3 forwarding decision

L2 — Data Link

Single-hop delivery between physically-connected devices on the same network. Uses MAC addresses (48-bit unique-per-NIC identifiers). Switches do their work here. Wi-Fi, Ethernet, PPP, MPLS — all L2 protocols.

L1 — Physical

Bits as actual signals — electrical pulses on copper, photons in fibre, radio waves through the air. Defines voltage levels, timing, connector pinouts, modulation schemes. The hardware layer.

Encapsulation — how data gets layered

This is THE concept you have to internalise. When data leaves your application, every layer wraps it in its own header (and sometimes a trailer). On the receiving side, every layer strips its header off before passing the payload up.

What's actually on the wire

On the wire (for an HTTPS GET):

|--Ethernet Header--|--IP Header--|--TCP Header--|--TLS Record--|--HTTP Request--|--Ethernet FCS--|
   14 bytes            20 bytes      20 bytes      5+ bytes        body            4 bytes

# Bandwidth overhead:
# - Ethernet: 14 + 4 = 18 bytes per frame
# - IPv4:    20 bytes (or 40+ for IPv6)
# - TCP:     20 bytes
# - TLS:     5 bytes minimum
# = at least ~67 bytes of overhead before your HTTP byte 1

Every layer adds bytes. For tiny HTTP requests (a 50-byte GET), the overhead is bigger than the payload. This is why HTTP/2 compresses headers and HTTP/3 / QUIC consolidates layers.

PDU naming — small but useful

Which devices live at which layer

Different network devices "live" at different layers — they only look at the headers up to that layer. Knowing this is critical for designing networks and debugging.

OSI vs TCP/IP — head to head

The OSI model is theoretical. TCP/IP is what actually runs. Here's how they map.

Why TCP/IP "wins" in reality

TCP/IP was already widely deployed when OSI was finalised. It was free, well-documented, and ran on every Unix. OSI was complex, slow to standardise, and required licensed implementations. By the time OSI was finished, TCP/IP had already won the internet.

Today, you'll see real-world reference material use a 4 or 5-layer model: Application / Transport / Network / Link [/ Physical]. The OSI 7-layer model survives mostly in textbooks and certifications.

Where do TLS and others fit?

Strict OSI would put TLS at L6 (presentation). Pragmatic engineers call it L4.5, or "between Transport and Application". Doesn't matter for day-to-day work — you just need to know that TLS wraps TCP and is wrapped by application data.

Attacks at every layer

Every layer has its famous attacks. Learning them in layer order is how every networking-security course is structured — and it's a great map of the whole offensive landscape.

Why this mapping matters

When you're investigating an incident or designing defences, knowing which layer the attack operates at tells you which controls can stop it. Anti-XSS rules at the firewall (L3/L4) are useless — XSS lives at L7. A VLAN segmentation strategy (L2) does nothing against an attacker who's already on the same VLAN spoofing ARP.

Match the defence layer to the attack layer.

Troubleshooting — layer-by-layer diagnosis

When things break — and they always break — having a layered model lets you eliminate layers one at a time, starting from the bottom. This is the troubleshooting muscle that separates senior engineers from juniors.

The bottom-up checklist

Tools by layer

Quick Reference Cheat Sheet

References that come up daily.

Layer → PDU → Device cheat sheet

Headers / overhead summary

Famous protocols → layer mapping

Mnemonic refresher

Top-down (L7 → L1):     A P S T N D P
                        All People Seem To Need Data Processing

Bottom-up (L1 → L7):    P D N T S P A
                        Please Do Not Throw Sausage Pizza Away

Closing Thoughts

Here's the truth about the OSI model: nobody implements it, but everyone uses it as a mental map. Once you can think in layers, every network problem becomes diagnosable. Every attack has a defence at the same layer. Every load balancer / firewall / proxy slots into a place on the cake.

Memorise the seven layers. Burn the mnemonic. Practise narrating problems in layer terms — 'this is an L4 issue', 'wait, that's actually L7'. The first time someone in a meeting describes a bug and you instinctively know which layer to investigate, you'll feel why this 40-year-old theoretical model refuses to die.

Then go run tcpdump on your own laptop. Watch the Ethernet frames containing IP packets containing TCP segments containing TLS records containing HTTP. The cake is real.