The OSI (Open Systems Interconnection) model is a 7-layer reference framework that describes how data moves across a network, with each layer handling one concern and talking only to the layers directly above and below it. It’s a conceptual model — the real internet runs on the leaner IP stack — but OSI is the shared vocabulary engineers use to locate a problem (“is this a Layer 4 or Layer 7 issue?”) and to reason about where responsibilities belong. Knowing which layer a thing lives at is what makes phrases like “L4 vs L7 load balancer” or “TLS sits at Layer 6-ish” meaningful.

The Seven Layers

From the wire up to the app. Mnemonic (top→down): All People Seem To Need Data Processing.

#LayerConcernUnitExamples
7ApplicationWhat the app actually doesDataHTTP, DNS, SMTP, gRPC, WebSocket
6PresentationEncoding, serialization, encryptionDataTLS, JSON/Protobuf, compression, character sets
5SessionEstablishing/maintaining sessionsDatasession cookies, RPC sessions, TLS session resumption
4TransportEnd-to-end delivery between processesSegment / DatagramTCP, UDP (ports live here)
3NetworkAddressing & routing across networksPacketIP, ICMP, routers, NAT
2Data LinkNode-to-node on one physical linkFrameEthernet, Wi-Fi (802.11), MAC addresses, switches
1PhysicalBits on the mediumBitcopper, fiber, radio, voltage/light signals

As data goes down the stack each layer wraps the payload in its own header (encapsulation); on the way up the receiver strips them off (de-encapsulation) — the same nesting the TCP/IP note describes.

OSI vs the Real TCP/IP Stack

Nobody implements seven discrete layers. The internet uses the 4-layer TCP/IP model, and OSI’s layers 5–7 collapse into one “Application” layer in practice:

OSITCP/IP
7 Application / 6 Presentation / 5 SessionApplication (HTTP, gRPC, TLS, DNS)
4 TransportTransport (TCP, UDP)
3 NetworkInternet (IP)
2 Data Link / 1 PhysicalLink (Ethernet, Wi-Fi)

So in everyday use, “Layer 4” almost always means TCP/UDP and “Layer 7” means HTTP and friends — the two that matter most for the decisions engineers make.

Why the Layer Number Matters

The whole reason to know OSI is that infrastructure operates at a layer, and that determines what it can see:

  • L4 (transport) load balancer — routes by IP/port only; fast, protocol-agnostic, but blind to HTTP. This is exactly why an L4 balancer pins all of a gRPC client’s multiplexed calls to one backend — it can’t see the individual HTTP/2 streams inside the connection.
  • L7 (application) load balancer / proxy — parses HTTP, so it can route by path/host/header, terminate TLS, retry, and balance individual requests/streams (Envoy, NGINX, YARP). More work per request, far more capability.
  • Firewalls — an L3/L4 firewall filters by IP/port; an L7 (application) firewall/WAF inspects HTTP payloads for attacks.
  • TLS spans presentation/session conceptually but is negotiated just above transport — which is why it can protect any L7 protocol uniformly.
  • Troubleshooting — “can’t resolve the name” is L7 (DNS), “connection refused” is L4 (port/TCP), “no route to host” is L3 (IP), “link down” is L1/L2. Naming the layer narrows the search instantly.

Pitfalls

  • Treating OSI as literal implementation. Real stacks don’t have crisp layers 5–7; TLS, for instance, doesn’t map cleanly to one OSI layer. Use OSI as a map, not a spec.
  • Confusing L4 and L7 capabilities. Expecting an L4 load balancer to do path-based routing or per-request balancing (it can’t — it doesn’t parse HTTP) is a common and costly mistake, especially with HTTP/2/gRPC multiplexing.
  • “It’s a layer 8 problem.” Engineers jokingly call user/political/process issues “Layer 8” — a reminder that not every failure is technical.

Questions

References