OSI vs TCP/IP model

Why two models at all

The OSI model was published by ISO in 1984 as a vendor-neutral reference. The intent was to standardize a layered architecture that any network could adopt. In parallel, ARPANET and then the broader internet had already been built on the TCP/IP suite, codified in RFC 791 (IP, 1981) and RFC 793 (TCP, 1981). TCP/IP shipped first, ran the actual internet, and won. OSI survived as the vocabulary we use to discuss networks.

Both models share the core idea: a protocol stack is a sequence of layers, each one offering services to the layer above and consuming services from the layer below. Each layer adds its own header (and sometimes trailer) on the way out, and strips it on the way in. This is encapsulation.

The OSI seven layers in production terms

Layer 7 is where your application code lives. HTTP, gRPC, DNS queries, SMTP. When you write fetch('/api/users'), you are operating at L7.

Layer 6 is presentation: TLS encryption, gzip or brotli compression, character encoding. TLS strictly speaking does both L5 (session establishment) and L6 (encryption), which is one reason OSI feels awkward in practice.

Layer 5 is session: managing the lifecycle of a logical connection across multiple transport connections. In the TCP/IP world this layer is mostly invisible. NetBIOS and some RPC frameworks live here.

Layer 4 is transport: TCP gives you reliable, ordered, byte-stream delivery. UDP gives you fire-and-forget datagrams. QUIC gives you TCP-like reliability over UDP with built-in TLS. Ports live here.

Layer 3 is network: IP addresses, routing, fragmentation. ICMP for diagnostics (ping, traceroute). The router cares only about L3.

Layer 2 is data link: framing bits into Ethernet or Wi-Fi frames, MAC addresses, ARP for IP-to-MAC resolution within a LAN. The switch cares only about L2.

Layer 1 is physical: voltage levels, optical signaling, RF modulation. The hub cares only about L1.

The TCP/IP four layers

TCP/IP collapses OSI L5, L6, L7 into a single Application layer. It collapses OSI L1 and L2 into a single Link layer. The middle two layers (Transport and Internet) map one-to-one.

This is not a downgrade. It reflects how the protocols were actually built. There is no clean separation between TLS (encryption) and HTTP (application logic) at the kernel boundary; both run in userspace and talk to TCP via the socket API.

Encapsulation, end to end

When you issue GET /api/users over HTTPS:

1. The browser builds an HTTP request: a request line, headers, optionally a body. This is the L7 payload.
2. TLS encrypts the HTTP bytes into a TLS record. L6 wrap.
3. The kernel's TCP stack puts the TLS bytes into one or more TCP segments, each with source and dest ports, sequence and ack numbers. L4 wrap.
4. The IP stack puts each TCP segment into an IP packet with source and dest IP addresses and a TTL. L3 wrap.
5. The NIC driver puts each IP packet into an Ethernet frame with source and dest MAC addresses. L2 wrap.
6. The NIC turns the frame into voltage or optical signals on the wire. L1.

On the way back, each layer unwraps and hands the payload up. The server's web framework eventually sees a clean Request object with no idea about IP fragmentation, TCP retransmits, or Wi-Fi retries.

Where the abstraction leaks

The model is clean on paper. In production, the layers bleed.

• TCP performance depends on path MTU at L3. If a router fragments your packet, throughput collapses.
• DNS resolution at L7 depends on UDP at L4 and IP routing at L3. A flaky route shows up as "slow website."
• TLS handshake latency at L6 multiplies your perceived L7 latency. Every extra round trip costs 50 ms on a typical mobile link.
• A Wi-Fi retry at L2 looks like a TCP stall at L4 because the segment never made it to the AP.
• eBPF programs in the Linux kernel run at L2/L3/L4 simultaneously. The whole "you only touch one layer" idea evaporates.

Layer-aware load balancers

The biggest practical use of OSI vocabulary in 2026 is load balancer classification.

• L4 load balancer: routes by 5-tuple (src IP, src port, dst IP, dst port, protocol). Fast, protocol-agnostic, no decryption. AWS NLB, HAProxy in TCP mode, IPVS.
• L7 load balancer: terminates TLS, parses HTTP, routes by Host header, path, cookie, or JWT claim. Slower, smarter. nginx, Envoy, AWS ALB, Cloudflare.

You pick L4 when you want raw throughput and the backend handles TLS. You pick L7 when you want path-based routing, sticky sessions, or to apply WAF rules.

QUIC and the model

QUIC (RFC 9000) is interesting because it folds TLS into the transport. From the OSI perspective it merges L4, L5, and L6. From the TCP/IP perspective it replaces TCP entirely. It runs over UDP not because UDP is better but because middleboxes refuse to let new L4 protocols through, so QUIC tunnels itself.

This is the model's biggest leak: the wire format does not care about academic layering. Whatever ships is what wins.

Common interview traps

• "What layer is a switch?" L2. It learns MAC addresses and forwards Ethernet frames.
• "What layer is a router?" L3. It looks at IP destination and consults its routing table.
• "What layer is a firewall?" Depends. A stateful firewall is L4 (tracks TCP connections). A WAF is L7 (parses HTTP).
• "What layer is BGP?" Application layer in TCP/IP terms (runs over TCP port 179), but it advertises L3 routes. The classic "control plane vs data plane" distinction.

Why this still matters

You will not draw the OSI model on a whiteboard at work. You will say "this is an L7 problem, not an L4 problem" when debugging why your load balancer is dropping connections. The model is a shared vocabulary for fast communication. Know the layers, know which protocols sit where, and use the words correctly.