The TCP/IP Stack Explained
September 22, 2026 • 8 min read
Table of contents
Part of the series:Networks Explained
The OSI post ended with a promise: the model is a map, but there is a machine actually making the journey. That machine is TCP/IP, and it is a strange piece of history: the seven-floor design that lost became the most successful networking architecture ever built, because the four-floor design that won shipped first. This post opens the real stack: the four layers your bytes travel through, how layers point at each other, the idea of an internet as a network of independent networks, and the two decisions that explain everything else.
The stack that actually runs
Where the previous post had seven floors, TCP/IP has four. The two OSI floors that turned out to be unnecessary are gone, and the rest are renamed after what they actually do.
4 Application your program's language HTTP, DNS, TLS, QUIC
3 Transport deliver to the right program TCP, UDP
2 Internet address and route across IP, ICMP, routers
1 Link address and deliver nearby Ethernet, Wi-Fi, ARPMapping the two models onto each other explains most of the disagreements you will hear about:
OSI TCP/IP
Application 7 ┐
Session 5 ├─ Application 4 (HTTP, DNS, plus
Presentation 6 ┘ │ TLS and QUIC)
Transport 4 ─────────────── 3 (TCP, UDP)
Network 3 ─────────────── 2 (IP, ICMP)
Data link 2 ─────────────── 1 (Ethernet, Wi-Fi)
Physical 1 ─────────────── 1 (folded into the link layer)Session and presentation disappeared because nobody could agree on what belonged in them, and every real implementation ended up doing the same job somewhere else. Encoding, compression, and encryption live inside libraries and protocols now, not in a layer of their own.
Physical folded into the link layer because on any real machine, the driver that talks to the network card handles both. You do not choose a “physical layer” separately from the driver that programs the card. Layer 1 is the wire; layer 2 is the code that puts frames on it.
QUIC complicates the picture. HTTP/3 runs its own reliability on top of UDP inside what looks like the transport layer, which is why some diagrams draw five layers. This series keeps the four-floor picture and treats QUIC as what it is: an exception that proves the rule.
How layers point at each other
The encapsulation post showed headers being added, but not how a receiver knows which header to read. Each layer tags its data with an identifier so the layer below can tell what is inside. There are three of these identifiers, and they are why everything interoperates.
- EtherType1: a number in the Ethernet header saying “the payload is IPv4”, “IPv6”, or “ARP”.
- Protocol number2: a byte in the IP header saying “the payload is TCP”, “UDP”, or “ICMP”.
- Port number3: a 16-bit number in the transport header saying “this belongs to the web server, 443”.
frame → EtherType 0x0800 → IP
packet → protocol 6 → TCP
segment→ port 443 → the web serverEvery packet carries the whole chain, because the receiving host receives one layer at a time, unwraps, and needs to know what to unwrap next. A host can read a header, recognize what is inside, and only then decide which of its own modules should handle it. This is why you can add a new protocol on the application layer and old machines still deliver your packets correctly: they read “TCP” in the IP header, deliver to TCP, and let TCP deliver to your new port.
An internet, not a network
The word matters. A network connects machines under one owner. An internet connects networks, each owned by someone else, and promises only to cooperate.
your laptop ── home network ── ISP network ── IXP ── Google network ── server
(owned by you) (owned by (a (owned by (owned by
your ISP) switch) Google) Google)No machine in this drawing is in charge. Routers do not know the whole path to your destination, and they do not need to: each router only needs to know which next hop is closer to the destination than it is. That is called hop-by-hop forwarding, and it is the difference between a network that needs a map and an internet that needs a neighbor.
The internet does not know where anything is. Every router knows only which road to take next. The route emerges from millions of partial answers.
This also means the internet has no natural owner, no address of record, and no place where a message “arrives at the internet”. There is no such machine. There are only cooperating networks, each making a locally reasonable forwarding decision, exactly the way the operating system makes locally reasonable scheduling decisions about a hundred processes.
Rules that let strangers cooperate
For networks owned by strangers to interoperate, the rules cannot be invented per network. They are written down, publicly, and numbered. That is the request for comments (RFC)4 system: documents that begin as proposals, gather review from anyone, and become the standards that everyone implements. The internet’s rules live in the RFC series, and a famous early one, RFC 791, defines IP.
The culture around those documents became famous too, from the rules of RFC 8175 for writing them: it required a section on consistency with other RFCs and documentation of the rationale, and in the same spirit of practicality, its authors declared that “no kings, no presidents, no voting” and that trivial objections should be dismissed with “we reject: your reasoning is bad”. Standards get written by the people who have to implement them.
Real-time systems have standards written by vendors. The internet has standards written by users. That difference is not trivia; it is why the internet won.
The end-to-end principle
The second decision that explains everything is a rule about where functions live, usually called the end-to-end principle6: put a function at the ends of the network whenever you can, and keep the middle dumb.
The argument: the middle of the network only knows how to move packets. It cannot know whether those packets carry a video, a bank transfer, or a text message, and any function placed there can only be correct for some applications and wrong for the rest. So the middle moves bytes, and the meaning lives in software at the endpoints, which both ends control.
This is why the web needed almost nothing from the network. The network delivers unreliable packets; HTTP and TCP at the ends turn that into a page. It is also why a new service can be invented, like video calls, without asking anyone’s permission: the network did not change at all.
It also predicts where new ideas land. Peer-to-peer file sharing needed a hole puncher in the middle and the logic at the ends. Encrypted traffic needed the endpoints to agree on keys and little help from the middle. Every time the ends can solve it, the solution goes in the ends.
Why TCP/IP won
OSI was, by its own designers’ account, a better design: it separated concerns more finely and defined interfaces more precisely. TCP/IP was cruder: four layers, session and presentation dropped, and the “interface” between layers left to each operating system to implement as it saw fit.
TCP/IP still won, for reasons that have little to do with elegance:
- It shipped first. Real implementations existed while the OSI debate was still running.
- It was minimal and permissive. A host that ignored a layer could still interoperate, which is unusual generosity for a standard.
- The end-to-end rule made it extensible. New applications needed no network changes, so the stack stayed put while everything above it exploded.
- Adoption followed use. Everyone implemented it because everyone was implementing it, and the internet reached critical mass decades before a competing stack could.
The OSI model survives as vocabulary, which is the best ending a losing design can get.
The big picture
TCP/IP is four layers: application, transport, internet, link. Ethernet types, protocol numbers, and port numbers let each layer hand off to the next, so new protocols can be added without touching the ones below. An internet is a network of independently owned networks connected by routers that know only the next hop, which is why nobody needs a map of the whole world. RFCs write the rules that strangers follow, and the end-to-end principle keeps the middle dumb and the meaning at the ends.
your program
↓ application: HTTP, DNS, TLS
↓ transport: TCP, UDP (reliability, ports)
↓ internet: IP (addresses, hop-by-hop routing)
↓ link: Ethernet, Wi-Fi (neighbors, frames)
↓ the wireEverything above is a promise about what happens after the bits are gone. The next post drops to layer one: what a bit actually is on a copper pair, a fiber strand, or a radio wave, and why moving a bit is harder than it sounds.
Footnotes
/sponsor
Enjoyed this post? You can sponsor me and this site.