The OSI Model (and why TCP/IP won)

Networking is the problem of moving bytes from one program on one machine to another program on a machine possibly on the other side of the planet, over unreliable copper, fibre, and radio. That is far too much to solve in one piece. The OSI model (Open Systems Interconnection — a reference framework published by the ISO standards body in 1984) splits the job into seven layers, each solving one narrow concern and handing the rest to the layer below it.

The point of layering is separation of concerns: the code that decides which Wi-Fi frequency to use should not also know what a URL is, and your web browser should not care whether the packet travels over fibre or 5G. Each layer offers a clean service to the layer above and depends only on the service of the layer below. Swap out any one layer — copper for fibre, IPv4 for IPv6 — and the layers above never notice.

Keep one mental image throughout the day: data travels down the stack on the sending machine (each layer wraps it in its own header), across the wire, then up the stack on the receiving machine (each layer unwraps its header). That wrap/unwrap pattern is called encapsulation, and it is the spine of everything below.

Reading the stack from the bottom up mirrors how a signal actually becomes meaning: raw voltage becomes a frame, becomes a routable packet, becomes a reliable stream, becomes an HTTP response. Each layer adds exactly one capability the layer below lacks.

A one-line gloss of each, so no layer is a black box:

• L1 Physical decides how a 1 and a 0 are represented — a voltage, a light pulse, a radio symbol — and pushes them onto the medium. It has no notion of "message"; it only knows bits.
• L2 Data link groups bits into frames and delivers a frame across one physical link to the next device, addressed by a MAC address (Media Access Control — a 48-bit hardware id burned into each network card). It also detects corrupted frames.
• L3 Network gives every host a global IP address (Internet Protocol — a logical address that identifies a host anywhere on the internet) and figures out the path of hops from source to destination. This is where "routing" lives.
• L4 Transport adds ports (a number identifying which program on the host owns the traffic) and, for TCP, turns the lossy packet service below into a reliable, ordered byte stream.
• L5 Session manages the lifecycle of a conversation — establishing, checkpointing, and tearing it down. In the real internet this rarely exists as its own layer; TCP and TLS absorb its duties.
• L6 Presentation handles how data is represented on the wire: character encoding, compression, and — most importantly today — TLS encryption (Transport Layer Security, which scrambles data so eavesdroppers see noise).
• L7 Application is the protocol your software actually speaks: HTTP for the web, DNS for name lookups, SSH for remote shells, SMTP for mail.

OSI is a teaching model. The internet actually runs on the TCP/IP model (also called the Internet Protocol Suite), which predates OSI's finalization, collapses the seven layers into four, and — crucially — shipped working code first. Engineers standardize on what runs.

TCP/IP won for reasons worth naming, because they recur in every "standard vs. shipping product" fight. Its specifications came with running implementations (BSD Unix) while OSI was still committee paper. It was simpler — four layers, not seven, and no artificial split between session, presentation, and application that real protocols never respected. And it was funded and deployed through ARPANET, so it had a live network the moment it existed. OSI's vocabulary survived as the universal way to talk about networking ("that's a layer 3 problem"), but its protocol stack did not survive contact with production. When you hear "layer 4 load balancer," the number is OSI; the bytes on the wire are TCP/IP.

Nothing makes the layers concrete like following one request. Say your browser fetches https://example.com/. Here is what each layer contributes on the way out, and how the wrapping unwinds on the way back. Assume the DNS lookup already resolved example.com to an IP.

Step by step, top to bottom:

1. L7 builds the HTTP request line and headers: GET / HTTP/1.1, Host: example.com.
2. L6 encrypts that request with the TLS session keys, producing a TLS record — ciphertext that any snooper on the path sees as noise.
3. L4 (TCP) prepends a header with the source port (a random high number like 54321) and destination port 443 (the well-known port for HTTPS), plus sequence numbers so the far end can reassemble and reorder.
4. L3 (IP) prepends the source and destination IP addresses and consults the routing table to pick the next hop toward example.com.
5. L2 wraps the packet in an Ethernet frame addressed to the MAC of the next-hop router, not the final destination — MAC addressing only reaches one link away.
6. L1 turns the frame into signals and pushes them onto the wire.

At each router along the way, the frame is unwrapped to L3, the router reads the destination IP, decides the next next-hop, and rewraps a new L2 frame with a new destination MAC. The IP addresses stay the same end-to-end; the MAC addresses change at every hop. When the frame finally reaches example.com, the server unwraps the whole stack in reverse — strip L2, strip L3, TCP reassembles the stream, TLS decrypts, and the web server reads a clean GET /.

The single mechanism behind that journey is encapsulation — each layer treats everything from the layer above as opaque payload and prepends its own header. The receiver peels the headers off in the exact reverse order. This is why the same byte of your request is, simultaneously, the innermost core of a frame and the outermost intent of an HTTP call.

The names for the wrapped unit change per layer and are worth knowing because tools and error messages use them precisely: at L4 it is a segment (TCP) or datagram (UDP), at L3 a packet, at L2 a frame, at L1 a bit stream. When a colleague says "the frame is malformed" versus "the packet is being dropped," they are pointing at different layers, and therefore different fixes.

The practical payoff of the model is that every piece of network gear operates at a specific layer, and knowing which one tells you what it can and cannot see. A device can only make decisions using headers at or below its layer.

A few of these deserve a sentence because they trip people up:

• A switch connects machines on a local network and forwards each frame only to the port where the destination MAC lives. It is pure L2 — it has no idea what an IP address is.
• A router connects different networks and forwards by IP, choosing the next hop toward a global destination. This is the box that makes the internet an inter-net.
• A load balancer spreads traffic across many backend servers, and the layer it works at is the whole game. An L4 load balancer balances by IP and port — fast and protocol-agnostic, but blind to what the request asks for. An L7 load balancer terminates the connection, reads the HTTP request, and can route /images to one pool and /api to another, do TLS termination, and inspect cookies for sticky sessions. L7 is smarter and more expensive per request; L4 is faster and cheaper.
• A WAF (Web Application Firewall) is an L7 firewall that inspects the actual HTTP payload to block attacks like SQL injection — something a plain L3/L4 firewall, which only sees IPs and ports, physically cannot do.

The best reason to internalize the layers is debugging: a network problem lives at exactly one layer, and naming it collapses the search space. Work bottom-up — a broken lower layer makes every layer above it look broken too, so the true fault is the lowest thing that is wrong.

A field guide to matching a symptom to its layer:

• No link light, dead cable, Wi-Fi won't associate → L1. Nothing higher can work until bits flow.
• ping <ip> fails but the cable is fine → L3. Routing, a missing route, or a firewall dropping ICMP. If pinging by name fails but by IP works, that is L7 (DNS), not L3.
• ping works but the port refuses (telnet host 443 / nc -vz host 443 fails) → L4. The service isn't listening, crashed, or a firewall blocks that port. Confirm with the classic check:

# L4 reachability: is the port open?
nc -vz example.com 443
# succeeds → transport is fine, look higher
# "Connection refused" → nothing is listening (L4)
# hangs then times out → a firewall is dropping (L3/L4)

• Port is open but you get a TLS error, a 500, or the wrong page → L7 (or L6 for a certificate/TLS handshake failure). The network delivered your bytes fine; the application or its encryption is the problem. Inspect at the top of the stack:

# L7: did the app answer, and how?
curl -v https://example.com/
# TLS handshake errors here are L6; HTTP 4xx/5xx are L7

The discipline: never debug an upper layer until every layer beneath it is proven healthy. A "the website is down" report can be a chewed cable (L1), a routing change (L3), a crashed process (L4/L7), or an expired certificate (L6) — and the layered ping/port/curl ladder tells you which in under a minute.

• OSI splits networking into seven layers so each solves one concern; data goes down the stack (wrapping headers) on send and up (unwrapping) on receive — that is encapsulation.
• Bottom-up, each layer adds exactly one thing: L1 signals, L2 framing + MAC delivery on one hop, L3 IP addressing + routing, L4 ports + reliability, L6 TLS/encoding, L7 the app protocol.
• TCP/IP's four layers, not OSI's seven, run the real internet — it won by shipping running code first, being simpler, and being deployed on a live network while OSI was still committee paper.
• In a packet's journey, IP addresses stay fixed end-to-end while MAC addresses change at every hop; routers rewrap a new L2 frame per hop.
• Devices act at a fixed layer: switch = L2 (MAC), router = L3 (IP), L4 LB = IP+port, L7 LB/WAF = URL + payload. A device can only decide using headers at or below its layer.
• Debug bottom-up: link (L1) → ping (L3) → port (L4) → curl (L7). The true fault is the lowest layer that is wrong.

• [ ] I can name what each of the seven layers adds over the layer below it.
• [ ] I can map any OSI layer to its TCP/IP layer and explain why the four-layer model won.
• [ ] I can trace one HTTPS request down the sending stack and up the receiving stack.
• [ ] I know that IP addresses are end-to-end while MAC addresses are per-hop.
• [ ] I can place a switch, router, L4 LB, L7 LB, firewall, and WAF at their correct layer.
• [ ] Given an outage, I can run the ping/port/curl ladder to localize the failing layer.