Interviewers ask about the OSI model not because you'll recite seven layers on the job, but because it's the shared vocabulary for talking about where a problem lives — "that's a layer 3 routing issue" versus "that's a layer 7 application bug." The TCP/IP model is the simplified, real-world version actually implemented on the internet. Knowing both, and knowing exactly where they diverge, is what separates someone who memorized a mnemonic from someone who can debug a production outage over Slack using layer numbers as shorthand.
The OSI model is a seven-layer checklist for everything that has to happen to get data from one computer to another — from raw electrical signals at the bottom, up through addressing and routing, up to the actual application data (like a web page) at the top. It's a teaching and troubleshooting tool, not something any real system builds exactly as written.
The TCP/IP model is the simpler, four-layer version that the real internet actually runs on. It squashes the OSI model's top three layers into one "Application" layer, because in practice things like encryption and session handling are just done by ordinary application code and libraries rather than separate dedicated layers.
Think of mailing a letter through the postal system. You write the actual message (the application data), put it in an envelope with a name on it (like a session), seal it in a mailing envelope with an address (delivery details), and hand it to a mail carrier who only cares about the street address on the outside, not what's written inside. Each layer only deals with its own piece of the packaging and trusts the layer inside it to be correct.
Each OSI layer exists to hide a specific problem from the layer above it. Going top to bottom:
L7 Application HTTP, DNS, SMTP, FTP, gRPC "what data means"
L6 Presentation TLS encryption, gzip, encoding "how data is represented"
L5 Session session establishment/teardown "who's talking to whom"
L4 Transport TCP, UDP "reliable delivery, ports"
L3 Network IP, ICMP, routing "which network, which path"
L2 Data Link Ethernet, Wi-Fi, ARP, MAC addrs "next hop on this wire"
L1 Physical copper, fiber, radio, voltage "bits on the medium"Layers 5 and 6 are the ones people get wrong in interviews because modern protocols don't implement them as distinct wire-level layers. TLS — often cited as "layer 6" — is really implemented as a layer running between TCP and HTTP (technically its own thing, sometimes called "layer 4.5" informally), and "session management" in a modern web app is handled by cookies and application-layer tokens, not a dedicated session-layer protocol. If an interviewer asks "where does TLS live in the OSI model," the strong answer is: "OSI textbooks call it Presentation, but in the real TCP/IP stack, TLS just wraps the payload before the OS hands it to TCP — it's an application-layer concern implemented as a library, not a distinct layer with its own protocol number."
As an HTTP request travels down the stack, each layer wraps the previous layer's output in its own header. This nesting is called encapsulation, and it's the reason a "packet" and a "frame" aren't the same thing:
[ Ethernet Header | IP Header | TCP Header | HTTP Request ]
^ L2 (MAC addrs) ^ L3 (IPs) ^ L4 (ports) ^ L7 (payload)
Ethernet Frame = Ethernet Header + everything inside it
IP Packet = IP Header + everything inside it (TCP Header + HTTP)
TCP Segment = TCP Header + HTTP payload
HTTP Message = just the request/response textA router forwarding your packet reads only up to the IP header (L3) — it never looks at the TCP header or the HTTP payload to make a forwarding decision. A switch on your LAN reads only the Ethernet header (L2) — it doesn't even know an IP address exists. This is precisely why "layer 4 load balancer" (reads TCP/UDP headers, routes on IP:port) and "layer 7 load balancer" (terminates TCP, reads the actual HTTP request — path, headers, cookies — to route) are fundamentally different pieces of infrastructure, not just marketing terms.
# See every layer show up in one command:
curl -v https://example.com
# TLS handshake = "presentation"; HTTP request/response = "application";
# the underlying TCP connect + ACKs happen below what curl prints.
# Watch actual layer 2/3/4 headers on the wire:
sudo tcpdump -i any -nn host example.com and port 443
# Each captured line shows: MAC (L2, if on same segment) -> IP src/dst (L3)
# -> TCP src/dst port + flags (L4). tcpdump never shows you TLS-decrypted L7 data.
# Confirm the L3 path (which routers/hops your packet crosses):
traceroute example.com # or: mtr example.com
# Confirm ARP (L2 address resolution on your local segment):
arp -a
Q: What layer does a load balancer operate at, and why does it matter?
A: Depends on the type. An L4 load balancer only reads the TCP/UDP header — source/destination IP and port — and routes or forwards packets without terminating the connection or looking at HTTP content; it's fast and protocol-agnostic. An L7 load balancer terminates the TCP (and TLS) connection, parses the actual HTTP request, and can route based on path, headers, cookies, or even the request body — more flexible but more expensive per request. This distinction matters in system design because L7 lets you do things like route /api/* to one service and /static/* to another, which an L4 balancer simply cannot see.
Q: Why does the TCP/IP model only have 4 layers instead of OSI's 7?
A: TCP/IP was designed pragmatically, from working protocols upward, not as an abstract teaching model. Session and Presentation concerns (encryption, session state) ended up being handled inside the Application layer by libraries and protocols like TLS, cookies, and JWTs rather than as separate wire-level layers — so the model that actually shipped never needed those as distinct layers.
Q: A user reports "the site is down." How do you use these layers to debug?
A: Work bottom-up or top-down depending on symptoms. Check L1/L2 first if it's a specific machine (cable, NIC, switch port). Check L3 with ping/traceroute to confirm routing. Check L4 with nc -zv host port to confirm the port is even accepting TCP connections. Only then check L7 — is the app returning a 500, a bad payload, or hanging on a slow query? Framing the debug process by layer stops you from guessing and lets you isolate scope fast.
Whenever a system design interview involves "put a load balancer in front of the service," you're expected to say which kind and why. A CDN or API gateway making routing decisions based on URL path or hostname is operating at L7. A simple TCP proxy or a cloud provider's basic Network Load Balancer operating purely on IP:port is L4 — cheaper, faster, but blind to application content. Designing a rate limiter keyed on user ID requires L7 visibility (you need to read a header or JWT), while a DDoS mitigation layer that just drops traffic from an IP exceeding a packet rate can live entirely at L3/L4 without ever parsing HTTP.
The classic interview gotcha is conflating the two models or misplacing a protocol — DNS and HTTP are Application layer (L7), TCP/UDP are Transport (L4), IP is Network (L3), and Ethernet/ARP are Data Link (L2). Another common trap: saying "OSI has 7 layers" without being able to name what problem each layer solves. In practice, engineers use OSI layer numbers as shorthand for scope of failure — a "layer 1 problem" means a physical cable or NIC issue, a "layer 7 problem" means the app returned bad data even though the connection succeeded. Knowing this vocabulary fluently, and being able to place any protocol (QUIC, gRPC, WebSocket) into it on the spot, is a low-cost way to sound senior.