The Layered Network Model — OSI, TCP/IP, and L4 vs L7

Why a layered model?

Networking is hard because a single request crosses many concerns at once: physical signalling, addressing, reliable delivery, encryption, and application semantics. The industry tames this with layering — each layer solves one problem and hands a clean abstraction to the layer above. You will not memorise the OSI model to build systems, but the vocabulary it gives you ("that's an L4 load balancer", "TLS sits at the session/presentation boundary", "this is an L7 routing rule") is how engineers talk about where a behaviour lives.

The OSI seven layers

OSI is the conceptual reference. Read it bottom-up — bits become frames, frames become packets, packets become reliable streams, streams carry application messages:

1. Physical — raw bits over a medium (copper, fibre, radio).
2. Data link — framing and MAC addressing on a local segment (Ethernet, Wi-Fi).
3. Network — logical addressing and routing across networks (IP).
4. Transport — end-to-end delivery, ports, reliability (TCP, UDP).
5. Session — establishing, managing, and tearing down connections.
6. Presentation — encoding, serialization, encryption (where TLS conceptually lives).
7. Application — the protocol your software speaks (HTTP, gRPC, SMTP, DNS).

TCP/IP — the model the internet actually runs on

The OSI model is a teaching tool; the internet is built on the leaner TCP/IP stack, which collapses OSI's top three layers into a single Application layer: Link → Internet (IP) → Transport (TCP/UDP) → Application. When people say "the network stack", this is usually what they mean.

TCP vs UDP — the transport choice that matters most

At the transport layer you pick reliability or speed. TCP is connection-oriented: a three-way handshake, ordered delivery, retransmission, and flow/congestion control. It is the right default for anything where correctness beats latency — web pages, APIs, file transfer.

UDP is connectionless: fire-and-forget datagrams with no handshake, no ordering, and no retransmission. You trade guarantees for the lowest possible latency, which is why it underpins DNS lookups, real-time voice/video, and gaming — and why QUIC (the basis of HTTP/3) is built on UDP while re-implementing reliability in user space.

L4 vs L7 — the distinction you will use constantly

"Layer 4" and "Layer 7" are shorthand for how much of the request a piece of infrastructure understands:

This is exactly why your load balancer can operate at L4 or L7, and why an API gateway is an L7 device — it has to read paths and headers to route. TLS termination happening "at the edge" means the L7 proxy decrypts so it can see the application data underneath.

Takeaways

• Layering = one concern per layer; the value is a shared vocabulary for where behaviour lives.
• The internet runs on TCP/IP; OSI is the conceptual map laid over it.
• TCP = reliable/ordered (default); UDP = fast/lossy (real-time, DNS, QUIC).
• L4 routes by address+port; L7 routes by request content. Memorise this one.

What breaks at each layer

Layering is not magic; every layer has its own failure mode. Physical links can corrupt bits; Ethernet at the data-link layer drops frames that fail a CRC check. IP is best-effort, so packets can be lost, duplicated, or reordered. TCP hides most of that by retransmitting, but recovery takes time (duplicate ACKs or a retransmission timeout), so the application can still see stalls. TLS handshake failures, DNS resolution timeouts, and application-level request timeouts all happen on top of a working stack. The lesson: reliability at one layer does not remove the need for timeouts and retries at the next.

Selection & trade-offs: when not to use each choice

• Don't use UDP when you need exactly-once delivery or large-file reliability unless you build that logic in the application (QUIC does this). Use UDP when a late packet is worse than a lost one — real-time voice/video, gaming, DNS.
• Don't use TCP for latency-sensitive broadcast or for protocols that cannot tolerate head-of-line blocking without adding their own stream multiplexing.
• Don't use an L4 load balancer when you need path-based routing, TLS termination, WAF, or per-request observability at the edge.
• Don't use an L7 proxy when you only need high-throughput packet forwarding, when every microsecond of proxy latency matters, or when the return traffic is huge and would make the proxy the bottleneck.

Trace an HTTPS request through the stack

When your browser requests https://example.com/index.html from 192.168.1.10 to server 93.184.216.34:

At the receiver each layer strips its header and hands the payload up. The same layering that makes the request easy to reason about also makes failures local: a bad cable, a full NAT table, or a lost IP packet only affects the layers that must recover from it.

Failure-mode table per layer

A dated entry you will still hear in this table's slot: "MAC collisions." Collisions only existed on shared half-duplex Ethernet (CSMA/CD); on today's switched full-duplex links the analogous failure is a duplex mismatch — one side believes the link is half-duplex and reports late collisions and CRC errors while the other side sees mysterious slowness.

L4 vs L7 decision matrix

Interviewer traps

Four follow-ups that separate "memorised the table" from "understands the stack":

• "Which layer is TLS?" OSI says session/presentation; practitioners say "between L4 and L7." The defensible answer: the OSI slots are conceptual — operationally TLS rides on TCP and wraps the application bytes, which is exactly why terminating it requires an L7-aware device. Say that, and the question is closed.
• "Why exactly can't an L4 LB route on a URL?" Trace the visible bytes: an L4 device sees only the IP header (source/destination IP, protocol, TTL) and the TCP header (source/destination port, flags, sequence numbers). The URL lives inside the payload — usually TLS-encrypted payload — which an L4 device never parses. That single fact answers every "can L4 do X?" question: if X requires reading past the TCP header, L4 cannot do it.
• "What does layering cost per packet?" A 1,500-byte Ethernet MTU frame spends 20 bytes on the IP header and 20 on the TCP header, leaving ~1,460 bytes of payload — about 97% efficiency. Send tiny 50-byte messages instead and the same 40 header bytes make the ratio terrible (50 / 90 ≈ 56%) — one reason chatty protocols batch or coalesce small writes.
• "Where did the client IP go?" Trace the three hops: client 203.0.113.7 → L7 proxy (terminates the TCP connection, opens a new one) → backend. The backend's TCP connection is with the proxy, so the source IP it sees is the proxy's, not the client's. Two fixes: at L7 the proxy appends X-Forwarded-For: 203.0.113.7 to the HTTP headers; at L4 — where there are no HTTP headers to append to — the PROXY protocol prefixes the original 4-tuple as a preamble on the backend connection. That is the story behind the last row of the decision matrix above.

Re-authored for this guide, with concepts and diagrams adapted from Karan Pratap Singh’s System Design (course, MIT licence) and the System Design Primer (CC BY 4.0). Diagrams © their respective authors.