# The TCP/IP Model Without the Acronym Soup

> The layered model, finally intuitive: each layer does one job and trusts the layer below, like nesting envelopes - Link, Internet, Transport, Application, plus TCP vs UDP and a packet's round trip.


---

# The TCP/IP Model Without the Acronym Soup

You already know the pieces. You know IP addresses identify machines, DNS turns names into those addresses, and HTTP is the language browsers and servers speak. What nobody drew for you is how these fit together - and so "the TCP/IP model" arrives as a wall of acronyms in four mysterious layers, memorized for an interview and forgotten by Friday.

Here's the relief this guide gives you: the layers aren't a list to memorize, they're an *idea*. Each layer does exactly one job and trusts the layer below it to do its own - the same trick the postal system uses, the same trick that lets you write a letter without knowing how trucks are routed. Once that clicks, the whole stack becomes something you can reason about instead of recite.

## How to read this
- **Need the mental model fast?** Read [Phase 1: Why Layers?](01-why-layers.md) - it installs the one idea everything else hangs on.
- **Want it to finally make sense?** Read in order. Phase 1 gives you the idea, Phase 2 names the four layers, Phase 3 traces a real packet down and back up the stack.

## The phases
1. **[Why Layers?](01-why-layers.md)** - the core idea: each layer does one job and trusts the layer below, like nesting envelopes. Meet *encapsulation*.
2. **[The Four Layers](02-the-four-layers.md)** - Link, Internet, Transport, Application: what each one adds, mapped onto a real web request.
3. **[TCP vs UDP & a Packet's Round Trip](03-tcp-udp-and-the-round-trip.md)** - reliable-and-ordered vs fast-and-forgetful, then one packet traced down the stack on send and up on receive. (And the OSI-7-vs-TCP/IP-4 confusion, cleared up.)

> This guide is about the *model* - the shape of the stack and why it's shaped that way. Wire-level packet captures, the TCP congestion-control algorithms, and tuning kernel network buffers are deeper material for a follow-up guide.


---

# Why Layers?

When people first meet the TCP/IP model, the layers look like an arbitrary filing system - four boxes someone drew on a whiteboard, with your job being to remember which acronym goes in which box. That framing makes it forgettable, because it hides the only thing worth knowing: *why the boxes exist at all.*

The secret is this. The internet is staggeringly complicated - fiber optics, Wi-Fi radios, routers in a thousand cities, programs in a hundred languages. No single piece of software could handle all of that and stay sane. So the design splits the problem into a stack of layers, where **each layer does exactly one job and trusts the layer below it to handle everything underneath.** That's the whole idea. Once you see it, the four layers stop being trivia and start being obvious.

## One job, and trust below

**What it actually is.** A layer is a worker with one narrow responsibility. It does its job, hands the result down to the layer beneath it, and refuses to think about what happens next. The layer below makes the same promise to the one below *it*. Trust flows downward; nobody reaches across.

The cleanest analogy is the postal system, so let's use it the whole way through.

You want to send a birthday card to a friend in another city. You write the card. You do **not** think about which highway the mail truck takes, whether it flies or drives, or how the sorting machine reads barcodes. You write words; that's your one job. You hand the card to the postal system and trust it.

```mermaid
flowchart TD
  you[YOU<br/>write words] -->|hand off, trust below| mailroom[MAILROOM<br/>put it in an addressed envelope]
  mailroom -->|hand off, trust below| post[POST OFFICE<br/>sort by region, route it]
  post -->|hand off, trust below| trucks[TRUCKS & PLANES<br/>physically move it]
```

Each level cares about one thing and ignores the rest. The truck driver never reads your card. You never plan the route. That separation is what makes the whole thing *possible* - and it's exactly how a network is built.

📝 **Terminology.** This idea - "do one job, hide the messy details, expose a simple promise to whoever's above you" - is called **abstraction**. Layers are abstraction applied top to bottom. It's the same reason you can drive a car without understanding combustion.

**Why this saves you later.** When something breaks, layering tells you *where to look*. "The page won't load" could be any layer - but the layers let you ask one question at a time, from the bottom up: Is the machine on the network at all (Link)? Can it reach the other machine's address (Internet)? Did the connection to the right program get made (Transport)? Did the program answer correctly (Application)? You debug a layered system layer by layer, instead of staring at the whole mess at once.

## Encapsulation: each layer wraps the one above

**What it actually is.** When your data travels *down* the stack, each layer doesn't rewrite what it received - it **wraps** it. The layer adds its own bit of information (a header, sometimes a trailer) around the package handed down from above, like sealing a letter inside a bigger envelope. This wrapping is called **encapsulation**, and it is the single most important word in this guide.

Back to the post office. Your card goes through nesting containers:

```text
   ┌─────────────────────────────────────────────┐
   │ MAIL TRUCK MANIFEST  (which truck, what route)│   ← outermost
   │  ┌────────────────────────────────────────┐  │
   │  │ SORTING LABEL  (region, post office)    │  │
   │  │  ┌──────────────────────────────────┐   │  │
   │  │  │ ENVELOPE  (street address, stamp) │   │  │
   │  │  │   ┌──────────────────────────┐    │   │  │
   │  │  │   │  YOUR CARD  ("Happy bday")│    │   │  │  ← innermost: the real message
   │  │  │   └──────────────────────────┘    │   │  │
   │  │  └──────────────────────────────────┘   │  │
   │  └────────────────────────────────────────┘  │
   └─────────────────────────────────────────────┘
```

The card never changes. Each layer just adds a wrapper that the *matching* layer on the other end knows how to read and strip off. The envelope is for the mail carrier; the sorting label is for the sorting facility; the manifest is for the truck dispatcher. Each wrapper is a private note from one layer to its twin at the destination.

**Why people get this wrong.** The common wrong picture is that the layers *transform* your data - that HTTP "becomes" TCP which "becomes" IP, like a translation chain where the original is lost. It isn't. Your actual data sits untouched at the center the entire trip. Everything else is wrapping added on the way down and peeled off on the way up. Hold onto "wrapping, not transforming" and encapsulation stops being mysterious.

**What it does in real life.** Every time your browser sends a request, this nesting happens in milliseconds. Your HTTP request gets wrapped by the Transport layer, that gets wrapped by the Internet layer, that gets wrapped by the Link layer - four envelopes, sealed in order, sent out on the wire. We'll name each of those layers in [Phase 2](02-the-four-layers.md) and watch the wrapping happen for real in [Phase 3](03-tcp-udp-and-the-round-trip.md).

⚠️ **Gotcha.** Each wrapper is read **only** by its counterpart on the receiving end - Transport's wrapper is for the receiver's Transport layer, never for the Link layer in between. Routers along the way peek at the *outer* wrappers they're responsible for and leave the inner ones sealed. A router moving your packet doesn't open your HTTP request any more than a mail truck reads your card. This is why one layer can change (swap Wi-Fi for Ethernet) without disturbing the layers inside it.

## Recap

1. **The internet is too complex for one program**, so it's split into a stack of layers.
2. **Each layer does one job and trusts the layer below it.** Trust flows downward; nobody reaches sideways.
3. **The postal system is the same idea:** the writer ignores the trucks, the trucks ignore the words.
4. **Encapsulation = wrapping, not transforming.** Going down the stack, each layer seals the package from above inside its own envelope.
5. **Each wrapper is read only by the matching layer at the destination** - which is why layers can be swapped independently, and why you can debug them one at a time.

You've got the idea. Now let's put names on the four envelopes - and see what each one is actually for.


---

# The Four Layers

Now that you know *why* there are layers - one job each, trust below, wrapping on the way down - the four names have somewhere to land. The TCP/IP model has four, stacking from the wire up to your app:

```mermaid
flowchart TD
  app["APPLICATION - what you actually use (HTTP, DNS)<br/>top: closest to you"]
  transport["TRANSPORT - deliver to the right program (TCP/UDP)"]
  internet["INTERNET - address & route across networks (IP)"]
  link["LINK - get to the next hop (Wi-Fi/Ethernet)<br/>bottom: the wire"]
  app --> transport --> internet --> link
```

Read it as a journey getting *more abstract* as you go up - the bottom layer thinks about voltage and radio, the top layer thinks about web pages. Take them from the bottom, the order your data is wrapped on the way out.

## Link: get it to the next hop

The Link layer is your machine's connection to the *one* device immediately next to it - your Wi-Fi router, the switch under your desk, the cable in the wall. Its entire world is a single hop: "get this from here to the thing right next to me." It speaks the language of physical networks - Ethernet, Wi-Fi - and deals in **MAC addresses**, the hardware ID burned into each network card.

📝 **Terminology.** A *hop* is one step between two directly-connected devices. Laptop to router is one hop; router to ISP is the next. A packet crossing the internet takes many hops; the Link layer only ever cares about the *next* one.

Your network card takes the package handed down from above, wraps it for the local network, and puts it on the wire (or into the air) addressed to the next device - usually your router. That's it; the Link layer has no idea where the data is *ultimately* going. It's the mail carrier who knows the route to the local post office and nothing beyond.

People assume their machine "connects to the website." It doesn't, not directly - your machine connects to the *next hop*, which connects to *its* next hop, and so on. The Link layer is deliberately short-sighted, which is what lets the same laptop work on Wi-Fi at home and Ethernet at the office: swap the Link layer, everything above it is untouched.

## Internet: address & route across networks

The Internet layer is where **IP** lives - the layer that gives every machine an address and figures out the path across the whole tangle of networks between you and the destination. If Link knows the next hop, the Internet layer knows the *whole route*, hop after hop, across networks it has never seen before.

📝 **Terminology.** *IP* (Internet Protocol) does two jobs: **addressing** (every machine gets an IP address, like `93.184.216.34`) and **routing** (each router along the way reads the destination IP and forwards the packet one hop closer). The unit it works with is the **packet**.

The Internet layer stamps your data with a source IP (you) and a destination IP (the server) and hands it to the Link layer for the first hop. At every router along the way, the router reads that destination IP, consults its routing table, and sends the packet out the next hop toward the target - this is the layer that makes "the internet" a single network instead of millions of isolated ones.

⚠️ **Gotcha.** IP makes **no promises**. It will *try* to deliver each packet, but doesn't guarantee arrival, doesn't guarantee order, and won't tell you if a packet vanished. This is *best-effort* delivery - a deliberate choice that keeps routers simple and fast. Fixing lost or out-of-order packets belongs to the layer above; it's the entire reason TCP exists, in [Phase 3](03-tcp-udp-and-the-round-trip.md).

## Transport: deliver to the right program

The Internet layer gets data to the right *machine*. But your machine runs dozens of programs at once - browser, email client, a music stream, three terminal tabs. The Transport layer's job is delivering data to the right *program*, using **ports**.

📝 **Terminology.** A *port* is a number that identifies one program's "mailbox" on a machine. The IP address gets you to the building; the port number gets you to the right apartment. A web server listens on port `443` (HTTPS) or `80` (HTTP); your browser opens a temporary port for the reply. (See [/guides/ip-dns-and-ports](/guides/ip-dns-and-ports) if ports are still fuzzy.)

Transport tags the data with a source port and a destination port so both ends know which program the bytes belong to. It's also the layer that decides *how careful* to be about delivery - the big fork in the road, with two main protocols:

- **TCP** - careful: sets up a connection, makes sure every byte arrives, puts everything back in order.
- **UDP** - quick: fires the data off with no connection and no guarantees.

Which one a program picks shapes everything about how it behaves - important enough to get [Phase 3](03-tcp-udp-and-the-round-trip.md) all to itself.

When you see `Connection refused` versus `Connection timed out`, that's the Transport layer talking. "Refused" means the machine answered but nothing was listening on that port (right building, no one home in that apartment). "Timed out" means nothing answered at all (you couldn't even reach the building - look lower, at Internet or Link).

## Application: what you actually use

The Application layer is the top - the protocols you name out loud: **HTTP** for the web, **DNS** for name lookups, SMTP for email, SSH for remote shells. This is where your data *means something*: a request for a page, a query for an address, a chunk of video. Everything below exists to carry these messages faithfully.

Your browser builds an HTTP request - "GET me this page" - and hands it down. From the Application layer's point of view, it's writing a letter and dropping it in the mailbox, trusting the three layers below to handle envelopes, addresses, and trucks. It never thinks about IP addresses, ports, or Wi-Fi. (How HTTP itself is shaped: [/guides/http-explained](/guides/http-explained).)

Because HTTP and DNS are the layer you touch, it's tempting to think they *are* networking. They're the visible tip. The reason a developer can write `fetch('https://example.com')` and ignore routing tables and radio frequencies is that the three layers underneath quietly do their one job each - exactly the payoff layering promised in [Phase 1](01-why-layers.md).

## One real request, mapped onto all four

Here's a single web request - your browser loading `https://example.com` - placed on the stack so you can see each layer's contribution:

```mermaid
flowchart TD
  app["APPLICATION: GET / HTTP/1.1  Host: example.com<br/>the actual request"]
  transport["TRANSPORT: TCP, to port 443, ordered & guaranteed<br/>which program, how careful"]
  internet["INTERNET: to IP 93.184.216.34, routed hop by hop<br/>which machine, what path"]
  link["LINK: over Wi-Fi to your router (first hop)<br/>onto the wire"]
  app --> transport --> internet --> link
```
*What just happened:* (an illustrative breakdown, not a packet capture) top to bottom, each layer added the one thing it's responsible for. Application wrote the request. Transport said "send it to the program on port 443, and be careful - it's TCP." Internet said "that's IP `93.184.216.34`, here's the route." Link said "first hop: my router, over Wi-Fi." Four jobs, four wrappers, one request on its way.

## Recap

1. **Link** - gets data to the *next hop* over Wi-Fi/Ethernet, using MAC addresses. Short-sighted on purpose.
2. **Internet (IP)** - *addresses* every machine and *routes* packets across networks. Best-effort: no delivery guarantee.
3. **Transport (TCP/UDP)** - delivers to the right *program* via ports, and decides how careful to be about delivery.
4. **Application (HTTP/DNS/…)** - the protocols you actually use, where the data *means* something.
5. **A real request touches all four**, each adding exactly its own piece on the way down.

You've met the four layers and seen them carry a request. The one question we kept deferring - *careful TCP or quick UDP?* - is next, along with a frame-by-frame trip of a single packet down the stack and back up.


---

# TCP vs UDP & a Packet's Round Trip

We've deferred one question twice: at the Transport layer, your data rides on **TCP** or **UDP**. They solve the same surface problem - get bytes to the right program - in opposite ways, and the difference shapes how everything from video calls to web pages behaves. Once you understand the trade-off, you'll know *why* a glitchy video call recovers and a glitchy file download doesn't.

Then the satisfying part: take one packet and watch it travel all the way down your stack on the way out, and back up on the way in - encapsulation from [Phase 1](01-why-layers.md) and the four layers from [Phase 2](02-the-four-layers.md), finally in motion.

## TCP: reliable, ordered, connected

TCP (Transmission Control Protocol) is the careful courier. Before sending a single byte, it establishes a *connection* with the other end, then guarantees three things: every byte arrives, in order, and anything missing gets re-sent. IP underneath makes no such promises (Phase 2) - TCP is the layer that *builds* reliability on top of unreliable IP.

**The connection starts with a handshake.** TCP can't just start talking; both sides first agree to. This is the **three-way handshake** - three short messages before any real data flows:

```mermaid
sequenceDiagram
  participant You
  participant Server
  You->>Server: SYN
  Server-->>You: SYN-ACK
  You->>Server: ACK
  Note over You,Server: data flows
```

📝 **Terminology.** *SYN* = "synchronize" (let's start, here's my sequence number). *ACK* = "acknowledge" (I received yours). Every chunk TCP sends gets acknowledged; if an ACK doesn't come back in time, TCP assumes the chunk was lost and re-sends it - that ACK-and-retransmit loop is the whole reliability machine.

Loading a web page, downloading a file, sending an email - all TCP. These are cases where a single wrong or missing byte ruins everything: a half-downloaded program won't run, a corrupted page won't render. You want *correct* more than *instant*.

⚠️ **Gotcha.** All that care has a cost: the handshake adds a round trip *before* your data even starts, and waiting to re-send lost pieces adds delay. Fine for a file download. For a live video call, that same "stop and re-send the missing piece" behavior would make the call stutter and lag - exactly where UDP comes in.

## UDP: fast, fire-and-forget

UDP (User Datagram Protocol) is the opposite philosophy: no handshake, no connection, no guarantees. It takes your data, stamps on the ports, and throws it at the destination. If a packet gets lost, UDP neither knows nor cares - a postcard with no tracking versus TCP's signature-required parcel.

This sounds reckless until you meet the cases it's *perfect* for: live video and voice calls, online games, DNS lookups. In a video call, a packet that arrives late is *worthless* - the moment it describes already passed. You'd rather drop it and show the next frame than freeze the picture waiting for a re-send. That's the UDP bargain: speed and freshness over completeness.

💡 **Key point.** The choice isn't "TCP good, UDP bad." It's a trade-off matched to the job. *Does a late or missing piece ruin the result (file, page) or is it just stale (a video frame, a game position)?* Ruined → TCP. Merely stale → UDP.

Here's the plain side-by-side:

```text
                    TCP                         UDP
   Connection?      yes - handshake first       no - just send
   Lost packets?    detected and re-sent        ignored
   Order?           guaranteed in order         may arrive out of order
   Speed/overhead?  slower, more overhead       fast, minimal overhead
   Best for         web, downloads, email       video/voice, games, DNS
   The bargain      correctness over speed      freshness over completeness
```

📝 **Terminology.** TCP's unit is called a *segment*; UDP's is called a *datagram*. Both get wrapped by IP into a *packet* for the trip - different names for "the chunk this layer is handling."

## A packet's round trip: down on send, up on receive

This is where every idea in the guide comes together. Watch a single request go **down** your stack as it leaves, and the reply come **up** the other machine's stack as it arrives. Encapsulation on the way down; the reverse - *de*-encapsulation - on the way up.

### On send: wrapping, top to bottom

```mermaid
flowchart LR
  app[Application] -->|+ HTTP msg| transport[Transport] -->|+ TCP ports| internet[Internet] -->|+ IP addrs| link[Link] -->|+ frame| wire((wire))
```
*What just happened:* your HTTP request started as plain text at the top and picked up one wrapper per layer on the way down - TCP's ports, IP's addresses, the Link layer's next-hop info - the nested-envelopes picture from [Phase 1](01-why-layers.md). Your original request sits untouched at the center the whole time. The fully-wrapped bundle goes out as a *frame* on the wire.

### Across the middle: routers peek, don't unwrap

The packet hops across the internet. Each router along the path strips and rebuilds *only the Link-layer wrapper* (each hop is a different physical link), reads the IP header to decide the next hop, and forwards it. The TCP segment and your HTTP request inside stay sealed - no router opens them. The outer envelope changes at each hop; the inner letter never does.

### On receive: unwrapping, bottom to top

```mermaid
flowchart LR
  card((arrives)) --> link[Link] -->|− frame| internet[Internet] -->|− IP| transport[Transport] -->|− TCP| app[Application]
```
*What just happened:* the receiving machine peeled the envelopes in exact reverse order - Link first, Application last - each layer reading the wrapper meant *for it* and handing the rest up. The server's Application layer receives the identical request your browser wrote, then builds a response and sends it down its own stack, wrapping it all over again for the trip home. That's the full round trip: down, across, up - and back.

## ⚠️ The OSI-7-vs-TCP/IP-4 confusion, settled

If you've read other material, you've seen a **seven**-layer model called **OSI**, not four. Here's the short version:

- The **TCP/IP model (4 layers)** describes how the internet *actually* works - the practical one, and what this guide taught.
- The **OSI model (7 layers)** is an older, more academic reference framework. It splits the work into finer slices - its bottom two map to TCP/IP's Link layer, and its top three (Session, Presentation, Application) fold into TCP/IP's single Application layer.

| OSI (7 layers, reference) | TCP/IP (4 layers, real) |
|---|---|
| Application · Presentation · Session | Application |
| Transport | Transport |
| Network | Internet |
| Data Link · Physical | Link |

💡 **Key point.** They describe the *same reality* at different resolutions - OSI just has more lines on the diagram. You'll hear engineers say "that's a layer 7 problem" (the application) or "a layer 3 issue" (IP/routing) - those numbers are OSI's. The mapping above lets you translate on the fly.

## Recap

1. **TCP** sets up a connection (the three-way handshake), then guarantees every byte arrives, in order, re-sending losses. Use it when a missing piece *ruins* the result: web, downloads, email.
2. **UDP** is fire-and-forget - no connection, no guarantees, minimal overhead. Use it when a missing piece is merely *stale*: video, voice, games, DNS.
3. **The choice is a trade-off:** correctness vs. freshness, matched to the job.
4. **On send, data is wrapped top-to-bottom (encapsulation); on receive, unwrapped bottom-to-top.** Routers in the middle touch only the outer Link wrapper and leave the rest sealed.
5. **OSI's 7 layers and TCP/IP's 4 describe the same reality** at different resolutions - OSI's numbers are the ones engineers quote ("layer 7", "layer 3").

That's the model, end to end: why layers exist, what the four are, and how a packet actually travels. The next time "TCP/IP" comes up, it won't be acronym soup - it'll be a picture you can reason from.

Walk the three-way handshake one packet at a time:

```playground-tcp
```

## Watch latency happen

Round-trip time isn't a fixed number - it wobbles, and on a bad connection packets get dropped outright. Watch a live connection and turn the dials:

```explainer-latency
```

Watch it animated: [the TCP handshake](/explainers/TCPHandshake.dc.html)

**Related guides:** [How the Internet Works](/guides/how-the-internet-works) · [IP, DNS, and Ports](/guides/ip-dns-and-ports) · [HTTP Explained](/guides/http-explained)