Same idea, two maps
In the previous guide you met the single most powerful idea in the whole subject: layering. Each layer solves one slice of the problem, leans on the (dumber) layer below, and offers a clean service to the (smarter) layer above. A model is just a named list of those layers — a shared vocabulary so two engineers can point at the same spot and mean the same thing. The networking world has two famous models, and the trick is realizing they are two maps of the very same territory, drawn by two different committees.
The first is the OSI model (Open Systems Interconnection), a seven-layer reference cooked up in the late 1970s as a grand, vendor-neutral standard. The second is the TCP/IP model, the four-layer (sometimes five-layer) stack that grew out of the actual ARPANET and won the real world. Here is the honest headline: the OSI model is a teaching reference — its clean seven-layer ladder is wonderful for explaining concepts — while the real Internet you are using right now runs the TCP/IP model. When people say "layer 3" or "layer 7" at work, they borrow OSI's numbers but they are running TCP/IP's protocols.
The seven OSI layers, top to bottom
Walk down the OSI ladder from the application you touch to the wire you do not. Layer 7, the application layer, is where your program lives — HTTP for the Web, SMTP for email. Layer 6, presentation, handles how data is encoded on the wire (think character sets, compression, and historically encryption). Layer 5, session, manages the start, checkpoints, and teardown of a long conversation. Layer 4, transport, turns host-to-host delivery into program-to-program delivery and (if you chose TCP) makes it reliable. Layer 3, network, gets a packet across many hops between networks. Layer 2, data link, gets a frame across one hop. Layer 1, physical, is the actual bits as voltage, light, or radio.
A small mnemonic from the bottom up: "Please Do Not Throw Sausage Pizza Away" — Physical, Data link, Network, Transport, Session, Presentation, Application. Notice that the bottom three layers (1–3) are about getting bits to the right machine, and the top three (5–7) are about what the two programs say to each other. Layer 4, transport, is the hinge in the middle — the transport layer is exactly where "deliver to this computer" becomes "deliver to this program on this computer."
Folding seven into four
Now lay the TCP/IP model over the OSI ladder and watch them snap together. TCP/IP keeps four layers and quietly merges the rest. Its application layer swallows OSI's 5, 6, and 7 into one — your program handles its own sessions and encoding, so HTTP, DNS, and SMTP all just live "at the top." Its transport layer is OSI's layer 4 exactly: this is the home of TCP and UDP. Its internet layer is OSI's layer 3, and it has one star protocol — the Internet Protocol, IP. Its link layer rolls OSI's layers 1 and 2 together: framing plus the physical bits, which on a local network usually means Ethernet or Wi-Fi.
OSI (7 layers) TCP/IP (4 layers) example protocol -------------------- ----------------- ---------------- 7 Application \ 6 Presentation > Application HTTP, DNS, SMTP 5 Session / 4 Transport Transport TCP, UDP 3 Network Internet IP 2 Data link \ Link Ethernet, Wi-Fi 1 Physical /
This shape is famously called the "hourglass." The top is wide — endless application protocols. The bottom is wide too — Ethernet, Wi-Fi, fiber, 5G, satellite. But the waist is narrow: almost everything runs over IP. That single thin layer is what lets a brand-new app run over a brand-new radio without either knowing the other exists, because both only have to speak to IP in the middle. Each box in that table is described by a protocol — a precise agreement on message format, the order of messages, and the actions to take — and the public ones are written down as numbered standards anyone can read.
Encapsulation: nested envelopes for one click
Layering is the idea; encapsulation is the mechanism that makes it work. As your data travels down the stack, each layer wraps what it received from above inside its own envelope — it adds a header (and sometimes a trailer) and treats everything inside as opaque payload it must not peek into. The classic analogy: layering is nested envelopes. Your letter goes in an envelope, that envelope goes in a bigger envelope, and the postal worker reading the outermost address never opens the inner ones.
- At the application layer, your browser produces an HTTP request like "GET /index.html" — just text, the message it wants to send.
- The transport layer wraps that in a TCP segment, prepending a header with source and destination port numbers and a sequence number; now the data has program-to-program addressing.
- The internet layer wraps the segment in an IP packet, adding source and destination IP addresses so it can be routed across many networks.
- The link layer wraps the IP packet in a frame (an Ethernet frame, say) with the MAC addresses of this hop, then the physical layer sends the bits as signals on the wire or in the air.
- At the receiver, the whole thing runs in reverse: each layer reads and strips off its own header, hands the payload up, and the browser finally sees the original "GET /index.html" — unwrapping the envelopes one by one.
Two honest caveats keep this from becoming a fairy tale. First, the layers are not perfectly sealed: a NAT box rewrites the IP and port headers, and a firewall happily inspects layer-4 headers, so the "never peeks inside" rule is a clean ideal with real-world exceptions. Second, encapsulation costs bytes — every header is overhead, which is why tiny messages can be inefficient and why the transport layer worries about how much real payload it can fit, the goodput-versus-throughput trade-off we met earlier in this rung.
Which model should you actually carry?
Carry both, for different jobs. Reach for OSI's seven layers and its numbers when you talk, teach, or buy gear — "this is a layer-3 problem," "that's a layer-7 load balancer." Reach for the TCP/IP four-layer stack when you actually build, debug, or trace something, because those four boxes are the protocols on the wire. The two are not rivals; OSI is the ruler you measure with, TCP/IP is the thing you measure. A great early habit: when anything breaks, ask "which layer?" Can't reach the IP at all? Suspect layers 1–3. Connected but the program misbehaves? Look at layer 4 and up.
Two misconceptions worth puncturing before you climb on. First, do not assume the model implies anything about safety: TCP gives you a reliable byte stream, but it is not secure and encrypts nothing by itself — privacy is a separate layer, TLS, bolted on top. Second, UDP is not a broken or lesser TCP; it is a deliberate choice that throws away reliability in exchange for speed, which is exactly what a live voice call or game wants. The model tells you where each protocol sits, not whether it is the right one for your job — that judgment is what the rest of this ladder will teach you.