OSI Model

Definition: The Open Systems Interconnection (OSI) model is a conceptual 7-layer framework, published by ISO in 1984, that standardizes the functions a network communication system must perform, independent of the underlying technology.

How It Works

Each layer provides services to the layer above it and relies on services from the layer below, communicating only with its counterpart layer on the remote system (a peer relationship), never directly with other layers.

Layer	Name	Function	Example protocols/tech
7	Application	User-facing protocols	HTTP, FTP, SMTP, DNS
6	Presentation	Data formatting, encryption, compression	TLS, JPEG, ASCII/Unicode encoding
5	Session	Establishes, manages, tears down sessions	NetBIOS, RPC, sockets session state
4	Transport	End-to-end delivery, segmentation, reliability	TCP, UDP
3	Network	Logical addressing, routing between networks	IP, ICMP, BGP, OSPF
2	Data Link	Physical addressing, framing on a single link	Ethernet, Wi-Fi (802.11), MAC/ARP
1	Physical	Raw bitstream transmission	Copper, fiber, radio, voltages

Data passed down the stack gets encapsulated at each layer: the transport layer wraps application data in a segment (adding port numbers), the network layer wraps that in a packet (adding IP addresses), the data link layer wraps that in a frame (adding MAC addresses), and the physical layer converts it to actual signal. Each layer only reads and acts on its own header, it treats everything above (the payload) as opaque.

Under the Hood

The mnemonic “All People Seem To Need Data Processing” (layers 7 down to 1) or “Please Do Not Throw Sausage Pizza Away” (1 up to 7) is the standard memory aid, useful mainly for interviews.

In practice, real-world protocol stacks blur or skip OSI layers rather than implementing all seven distinctly:

TLS spans presentation-layer concerns (encryption, formatting) but in practice sits as a library between the transport and application layers, not as a distinct wire-level layer.
HTTP/2 and HTTP/3 do multiplexing and stream management that OSI would file under session layer, but there’s no separate “session layer” protocol in the actual internet stack.
Ethernet switches operate at Layer 2 (MAC address forwarding); a “Layer 3 switch” blurs the line by also doing IP routing in hardware.
Layer 1 vs Layer 2 boundary: a hub is purely Layer 1 (repeats electrical signal, no awareness of frames), a switch is Layer 2 (reads MAC addresses to decide which port to forward to).

The OSI model was originally meant to be a full protocol suite, not just a reference model, ISO intended OSI protocols to replace TCP/IP entirely. That effort lost to TCP/IP’s earlier deployment and simplicity, so today OSI survives purely as the vocabulary and mental model used to describe the actual TCP/IP-based internet, not as a suite anyone deploys. That’s the source of most confusion around it (see Common Pitfalls).

Troubleshooting by layer is the model’s most practical daily use: “can I ping the gateway?” (Layer 3), “does arp -a show the right MAC?” (Layer 2), “is the cable link light on?” (Layer 1), “does curl -v get a TLS handshake?” (Layer 4/6), “does the API return the right JSON?” (Layer 7). Working bottom-up through the stack isolates where a failure actually lives.

Layer-by-Layer Troubleshooting

A practical way the model earns its keep, working the stack bottom-up when something’s broken:

Layer 1: Is the cable plugged in? Is the link light on? Is Wi-Fi actually associated?
Layer 2: Does arp -a show a sane MAC for the gateway? Any duplex mismatches or switch port errors?
Layer 3: Can you ping the gateway? Is the IP/subnet mask correct? Does traceroute show routing progressing normally?
Layer 4: Does telnet host port or nc -zv host port open a TCP connection? Is a firewall dropping the specific port?
Layer 6/7: Does the TLS handshake succeed (openssl s_client)? Does the application return the expected response (curl -v)?

Each layer’s failure produces a distinctive symptom, which is why “what layer is this” is usually the first real diagnostic question in network troubleshooting.

History: OSI vs TCP/IP

ISO began developing OSI in the late 1970s as a deliberately vendor-neutral, top-down-designed standard, meant to be implemented as an actual protocol suite (with real OSI-layer protocols like X.400 for email and X.500 for directories), not just a reference diagram. TCP/IP, meanwhile, had already been running on ARPANET since the 1970s and became the NSFNET backbone standard in 1985.

By the time the full OSI protocol suite was finalized in the mid-to-late 1980s, TCP/IP was already deployed at scale and worked well enough that migrating to OSI’s protocols offered little practical benefit for a large, growing cost. Some government and telecom bodies mandated OSI compliance through the early 1990s (the US GOSIP initiative among them), but the market had effectively already chosen TCP/IP. OSI’s 7-layer model survived this loss as pure documentation and pedagogy, arguably more influential as a diagram than the actual OSI protocols ever were as running code.

Why It Matters

OSI gives engineers a shared vocabulary for problems that would otherwise be hard to describe precisely. Saying “this is a Layer 3 issue” instantly narrows a networking problem to routing/addressing rather than cabling or application code. It also shapes how vendors describe products (Layer 4 vs Layer 7 load balancers behave very differently) and how firewalls are categorized (packet filters operate at Layer 3/4, web application firewalls at Layer 7).

Common Pitfalls

Treating OSI as what’s actually implemented on the wire. The real internet runs on the 4-layer TCP/IP model; OSI is a teaching and diagnostic reference, not a literal implementation.
Trying to force real protocols into exactly one layer. TLS, for instance, doesn’t map cleanly to “Presentation” the way textbooks suggest, it handles session-like concerns too (session resumption, tickets).
Confusing “Layer 7 load balancer” (routes based on HTTP content, host header, path) with “Layer 4 load balancer” (routes based on IP/port only, blind to application content), a common terminology trap in infrastructure interviews.
Assuming every layer must be present in every stack. Point-to-point links can be nearly layer-less; a raw socket application can skip session/presentation entirely.
Believing layers strictly nest without any layer skipping information to another, in practice things like ICMP (Layer 3) carry information used by upper layers (e.g. Path MTU Discovery feeds back into TCP’s segment sizing decisions).
Memorizing the layer numbers without being able to say what problem each layer actually solves, the number is a index into the model, not the substance of it, and interviewers can usually tell the difference quickly.
Assuming a “Layer 2 problem” and a “Layer 3 problem” require the same tools, ARP tables and switch port statistics diagnose Layer 2; routing tables and traceroute diagnose Layer 3, using the wrong toolkit wastes time before the right layer is even identified.

Comparison

	OSI Model	TCP/IP Model
Layers	7	4
Origin	ISO standard, 1984	Emerged from ARPANET/DARPA work, formalized later
Status	Reference/teaching model	What’s actually implemented
Session & Presentation	Explicit separate layers	Folded into Application
Adoption	Universal as a diagnostic vocabulary	Universal as the deployed protocol suite

Devices and Attacks by Layer

Mapping common network hardware, and common attack types, onto the layers they operate at makes the model concrete rather than abstract:

Layer	Typical device/tool	Example attack targeting this layer
7 Application	Web server, WAF, API gateway	SQL injection, XSS, credential stuffing
4 Transport	Load balancer (L4 mode), firewall	SYN flood, port scanning
3 Network	Router, L3 switch	IP spoofing, BGP hijacking
2 Data Link	Switch, access point	ARP spoofing, MAC flooding
1 Physical	Cable, hub, transceiver	Wiretapping, signal jamming

This is also why defense in depth means placing controls at multiple layers rather than trusting one: a Layer 3/4 firewall blocking bad IPs and ports does nothing to stop a Layer 7 SQL injection riding on an allowed, legitimate-looking HTTPS connection.

Example

Loading https://example.com touches every layer: DNS resolves the name (Layer 7), TLS negotiates encryption (Layer 6-ish, in practice sits above Layer 4), TCP opens a reliable connection on port 443 (Layer 4), IP routes packets to the server (Layer 3), Ethernet/Wi-Fi frames carry them across the local link (Layer 2), and the physical medium, cable or radio, actually moves the bits (Layer 1).

FAQ

Is the OSI model actually used anywhere in production systems? Not as literal running protocols, its value today is entirely as shared vocabulary for diagnostics, documentation, and product categorization (e.g. “Layer 7 firewall”).

Why do interviewers ask about OSI so much if nobody implements it? Because it’s the fastest way to test whether a candidate has a structured mental model of networking, rather than a flat, undifferentiated idea of “the internet.”

What layer does a VPN operate at? Depends on the VPN type, IPsec tunnel mode operates around Layer 3, while an SSL/TLS VPN (like OpenVPN in TLS mode) rides on top of Layer 4, tunneling other layers’ traffic inside it.

Where do WebSockets fit in the model? They start as an HTTP request (Layer 7) that upgrades the underlying TCP connection (Layer 4) into a persistent bidirectional channel, still technically an application-layer protocol, just one that keeps the transport connection open rather than closing after each exchange.

Referenced by

Dig deeper

Spot an error in this note?