5.1 — Why Networks Are Built in Layers

Here is what actually happens when you type google.com and press Enter.

Your laptop has no idea where Google is. It does not know what a road looks like between here and California. It does not know whether the connection will go over Wi-Fi, a phone's mobile signal, a copper cable in the wall, or a fibre-optic line under the Atlantic Ocean. It does not know that the request will pass through roughly fifteen different machines owned by four different companies, none of whom have ever heard of you.

And yet it works, in about 200 milliseconds, every single time.

That is not luck. It works because of one idea, and this whole Part is built on it: nobody tries to solve the whole problem. The problem is chopped into layers, each layer solves exactly one small thing, and each layer talks only to the layer directly above and below it. The browser does not know about radio waves. The Wi-Fi chip does not know what a web page is. Neither has to.

1. The postal analogy, in full

Suppose you want to send a birthday card to a friend in another country.

You write the card. You do not think about aeroplanes. You put it in an envelope, write the address on the front, and drop it in a postbox. That is the last decision you make.

The postal service picks it up and puts it in a sack with a hundred other letters going roughly the same direction. The sack goes on a van. The van driver has no idea what is inside any envelope — and that is the point, because if the driver had to read every letter to decide where it went, the system would collapse. The driver only knows "take this sack to the sorting office".

At the sorting office the sack is opened, the letters are re-sorted by country, and a new sack is made up. That sack goes on a plane. At the other end, a different postal service opens it, re-sorts by city, then by street, and eventually a person on a bicycle puts it through a letterbox.

Your friend opens the envelope and reads the card. They read exactly what you wrote. Every layer in between wrapped it, moved it, and unwrapped it, and none of them changed a word.

Notice the properties that fall out of this:

• You did not need to know the route. You wrote an address, not directions.
• Each stage only understands its own job. The van driver understands sacks. The sorting machine understands postcodes. The person on the bicycle understands house numbers.
• You can change one stage without touching the others. Replace the van with a train, and the letter still arrives. Nobody has to rewrite how envelopes work.
• The envelope wraps the letter; the sack wraps the envelope; the plane's cargo manifest wraps the sack. Each stage adds its own wrapping on the way out and removes it on the way in.

A computer network is exactly this, and the wrapping has a name: encapsulation. Each layer takes whatever the layer above handed it, treats it as opaque cargo it must never inspect, and adds its own small header on the front saying what it needs to do its job.

2. The four layers that actually exist

There are two ways to name the layers. We will start with the one that is real, because that is the one your computer is running right now: the TCP/IP model, four layers.

The four layers of the TCP/IP model. Read the right-hand column as four different kinds of address, each answering a different question: which program, which machine, and which physical device on this local wire.

Take them one at a time, bottom up, because that is the order the problem gets harder.

Link layer — "get this to the next box on this wire." This is the layer that knows about actual physical things: voltage on copper, light in fibre, radio waves in the air. Its job is tiny and specific: move a chunk of data from this device to another device on the same local network. Your laptop to your Wi-Fi router. That is it. It has no concept of "the internet" and cannot reach anything beyond the wire it is attached to. Chapter 5.2 is this layer.

Internet layer — "get this to that machine, wherever on Earth it is." This is the layer that makes a global network possible. It gives every machine an address — an IP address — and it works out, hop by hop, which direction to send a packet next. Critically, it makes no promises. It does not guarantee the packet arrives, does not guarantee packets arrive in order, and does not tell you if one is lost. It is a best effort. Chapter 5.3 is this layer, and the "no promises" part is why the next layer exists.

Transport layer — "get this to the right program on that machine, and (optionally) make it reliable." A machine runs many programs at once — a browser, a mail client, a game, a database. The IP address gets you to the machine; a port number gets you to the right program. And this is where reliability lives: TCP takes the internet layer's unreliable delivery and builds on top of it a connection that does not lose data, does not deliver it out of order, and does not overwhelm a slow receiver. UDP declines to do any of that and just sends. Chapter 5.4 is this layer.

Application layer — "what does this data actually mean?" HTTP for the web, DNS for looking up names, SMTP for email, SSH for remote login. This is where the bytes stop being bytes and start being a request for a web page. Chapters 5.5 through 5.8 live here.

The essential thing to hold onto: each layer solves a problem the layer below refused to solve.

• The link layer says "I can only reach the next box."
• So the internet layer says "fine, I will chain those hops together into a global route."
• The internet layer says "I might lose your packet."
• So the transport layer says "fine, I will number them and re-send the missing ones."
• The transport layer says "I deliver a stream of bytes, and I have no idea what they mean."
• So the application layer says "fine, I will define what the bytes mean."

Every layer is the answer to the previous layer's limitation. If you remember nothing else from this page, remember that sentence — it is the whole architecture.

3. What encapsulation looks like in actual bytes

When your browser sends GET /index.html HTTP/1.1, here is what leaves your network card:

┌─────────────────────────────────────────────────────────────────────┐
│ Ethernet header │ IP header │ TCP header │  GET /index.html...  │FCS│
│    14 bytes     │  20 bytes │  20 bytes  │      your data       │ 4 │
│                 │           │            │                      │   │
│ dest MAC        │ dest IP   │ dest port  │                      │   │
│ src MAC         │ src IP    │ src port   │                      │   │
│ type = IPv4     │ protocol  │ seq number │                      │   │
│                 │  = TCP    │ flags      │                      │   │
└─────────────────────────────────────────────────────────────────────┘
   ← link layer  → ← internet→ ← transport→ ←   application       →

Read it left to right, and notice the pattern: each header contains a field naming what comes next. The Ethernet header's type field says "an IPv4 packet follows". The IP header's protocol field says "a TCP segment follows". The TCP header's destination port says "port 443, so this is probably HTTPS".

That chain of "what comes next" fields is how the receiving machine unwraps everything without guessing. Its network card reads the Ethernet header, sees type = IPv4, and hands the rest to the IP code. The IP code reads its header, sees protocol = TCP, and hands the rest to the TCP code. The TCP code reads the port, finds which program is listening there, and hands the rest to that program. Four handoffs, no ambiguity, no layer ever inspecting anything but its own header.

There is a real cost here, and it is worth knowing the number. Those headers add up to about 54 bytes on every single packet. For a 1,500-byte packet that is roughly 3.6% overhead. For a packet carrying 10 bytes of data — a keystroke in a terminal session — the headers are five times bigger than the payload. Layering is not free; it is bought with header overhead, and the price is worth it because the alternative is a network nobody could build or change.

Why is it called a "packet"?

The word comes from Donald Davies at the UK's National Physical Laboratory, who in 1965 needed a name for a small parcel of data with an address on it. He chose "packet" deliberately, because it was an ordinary English word that non-specialists would understand — a small package. The idea itself, packet switching, was invented independently by Paul Baran at RAND in the United States and by Davies in Britain, and it is the single most important idea in this Part.

4. Packet switching: why the network does not build you a road

Before computer networks, there were telephone networks, and they worked completely differently. When you made a call, the network physically connected a wire from your phone to theirs, through a chain of switches, and reserved that path for the entire duration of the call. Nobody else could use it. This is circuit switching.

It has one big advantage: once the circuit exists, the quality is constant and predictable. And two crushing disadvantages. First, most of the time nobody is speaking, so a reserved circuit sits idle wasting capacity. Second, if any switch along the reserved path fails, the call drops dead — there is no rerouting, because the route was fixed when the call was set up.

Packet switching throws all of that away. There is no reserved path. Your data is chopped into small packets, each one carrying the full destination address, and each packet is routed independently. Two packets from the same request can take entirely different routes across the world and arrive out of order — and often do.

This sounds worse. It is dramatically better, and for three reasons:

Sharing. A link is only busy when a packet is actually crossing it. Between your packets, ten thousand other people's packets use the same fibre. The capacity is shared moment by moment instead of reserved in advance, which is why a single fibre can carry millions of simultaneous conversations.

Survival. If a router dies, the next packet is simply routed around it. The original 1960s research funding for this came from exactly that concern — building a communication network that keeps working when parts of it are destroyed. (The popular story that the internet was designed to survive a nuclear war is an oversimplification; Paul Baran's RAND work genuinely was about surviving attack, while Davies's parallel work in Britain was about efficiency for computer traffic. Both arrived at packet switching.)

No setup cost. You do not have to negotiate a path before sending. You just send.

The price you pay is that the network makes no promises. Packets may be lost, duplicated, delayed, or delivered out of order. Everything difficult in Chapter 5.4 exists to build reliability on top of a network that deliberately does not provide it.

The design principle that made the internet win

This is called the end-to-end principle, stated by Saltzer, Reed and Clark in 1984. It says: put the smarts at the edges of the network, not in the middle. The middle of the internet — the routers — does one thing, forwards packets, and does it fast and stupidly. All the intelligence lives in the machines at the ends.

The telephone network did the opposite: dumb handsets, intelligent network. And the consequence is stark. To add a new feature to the phone network you had to upgrade the network itself, which took years and required agreement from every operator. To add a new feature to the internet you write a program on two computers, and the network does not need to know or care. The web, email, video calls and streaming were all added without changing a single router. That is why the internet has a web on it and the telephone network never did.

5. The OSI model, and how to talk about it honestly

You will constantly meet a seven-layer model called OSI (Open Systems Interconnection), published by the International Organization for Standardization in 1984. It goes: Physical, Data Link, Network, Transport, Session, Presentation, Application.

Here is the honest situation, which interviewers do probe.

OSI was a competing standard that lost. It was designed by committee, in parallel with TCP/IP, and by the time it was finished TCP/IP was already deployed, already working, and already free. The internet runs on TCP/IP. Nothing you use runs the OSI protocol stack.

But the OSI vocabulary survived anyway, because its layer numbers turned out to be a convenient way for engineers to talk. When someone says "a layer 7 load balancer" or "a layer 4 firewall", they are using OSI numbering, and it is genuinely useful shorthand.

OSI layer	Name	What it maps to	What people mean when they say it
7	Application	TCP/IP Application	reads the actual HTTP request
6	Presentation	(mostly folded into 7)	encoding, encryption
5	Session	(mostly folded into 7)	conversation state
4	Transport	TCP/IP Transport	works on ports, TCP/UDP
3	Network	TCP/IP Internet	works on IP addresses
2	Data Link	TCP/IP Link	works on MAC addresses, a switch
1	Physical	TCP/IP Link	the actual cable or radio

Layers 5 and 6 are the ones that never really happened. In the real stack, session state and encoding are just part of the application protocol — TLS encryption is sometimes called "layer 6-ish" and sometimes "layer 5", which tells you the classification is not doing much work.

The practical numbers to know are 2, 3, 4 and 7, and each corresponds to a different kind of address:

• Layer 2 — MAC address. A switch operates here. It moves frames between devices on one local network.
• Layer 3 — IP address. A router operates here. It moves packets between networks.
• Layer 4 — port. A basic firewall or a simple load balancer operates here: it can say "allow port 443" or "send this connection to server B", but it cannot see what is inside.
• Layer 7 — the actual content. A modern load balancer, an API gateway or a web application firewall operates here: it can read the URL path, the headers and the cookies, and route on them.

The layer-4 versus layer-7 distinction is the single most practically useful thing in this section. It explains why a layer-4 load balancer is faster but cannot route /api to one server and /images to another, and why a layer-7 one can but must decrypt the traffic to do it. Chapter 10.15 developed this for system design; you now know why the numbers are what they are.

6. How anyone agrees on any of this: the standards story

Here is a question worth sitting with. A laptop made in Vietnam, running an operating system written in America, on a Wi-Fi chip designed in Taiwan, connects through a router made in China to a server in Ireland running software written in Finland — and they all agree, byte for byte, on what a packet looks like.

Nobody is in charge. There is no world government of computing. So how does that agreement exist and stay stable for fifty years?

The answer is a specific culture of standard-setting, and it is genuinely unusual.

The RFC, and the deliberately humble name. In 1969, Steve Crocker was a graduate student writing up notes on the first ARPANET protocols. He was worried about seeming to claim authority he did not have, so he called his document a Request for Comments. The name stuck, and every internet standard since has been an RFC — over 9,000 of them. HTTP is RFC 9110. TCP is RFC 9293. IP is RFC 791.

The humility in the name is not decoration. It reflects the actual process: anyone can write an RFC. There is no membership fee, no national delegation, no vote by country. You write a draft, you post it, people argue with it, and if it survives the arguing and gets implemented, it becomes a standard.

"Rough consensus and running code." This is the IETF's (Internet Engineering Task Force) explicit motto, coined by David Clark in 1992, and the full quote is worth having: "We reject: kings, presidents and voting. We believe in: rough consensus and running code."

What it means in practice is that a proposal is not accepted because a committee approved it. It is accepted because two independent implementations were built and they interoperated. This one rule is why internet standards tend to work: you cannot standardise something that does not exist yet, so every specification has been through contact with reality before it is finalised.

Postel's Law, and its complicated legacy. Jon Postel, who edited the RFC series for nearly thirty years, wrote a rule into the TCP specification that became famous: "Be conservative in what you send, be liberal in what you accept."

The intent was good — if everyone is strict about what they emit and forgiving about what they receive, small differences between implementations do not break the network. And it worked; it is a large part of why the early internet grew so fast across so many incompatible systems.

It is now regarded as a mistake, and knowing why is a genuinely senior observation. If receivers accept malformed input, then senders that produce malformed input never find out, so the broken behaviour spreads and eventually becomes the de facto standard. HTML spent two decades in this state — browsers accepted anything, so pages were written badly, so every new browser had to accept anything too. Modern protocol design tends the other way: HTTP/2 and QUIC are deliberately strict, because being strict early is cheaper than being permissive forever.

Who governs what. Four organisations, and the split is worth knowing because people conflate them:

• IETF — protocols. TCP, IP, HTTP, DNS, TLS. Publishes RFCs. Open to anyone.
• IEEE — the physical and link layer. Ethernet is IEEE 802.3, Wi-Fi is IEEE 802.11. That is why Wi-Fi versions have names like 802.11ac.
• ICANN and IANA — names and numbers. Who owns which IP address blocks, which top-level domains exist, which port numbers mean what. This is the closest thing to a central authority, and it is a coordination function rather than a technical one.
• W3C and WHATWG — the web above the network: HTML, CSS, the browser APIs.

Why the standards hold. Not because of enforcement — there is none. They hold because of network effects. A protocol is only useful if others speak it, so the incentive to deviate is almost zero: a router that invents its own packet format can talk to nothing. The standard is enforced by uselessness, not by law, and that turns out to be a stronger mechanism than any regulator.

The place this breaks down is worth naming too. Because deviation is so costly, changing an established protocol is nearly impossible. IPv6 was standardised in 1998 and, more than a quarter of a century later, still has not replaced IPv4 — Chapter 5.3 explains what that has cost. The same rigidity is why HTTP/3 had to be built on UDP rather than fixing TCP: too much equipment in the middle of the network makes assumptions about TCP that could never be updated. Stability and stagnation are the same property viewed from different sides.

7. What the layers cost, and where they leak

The layer model is a simplification, and a good engineer knows the places where it is not true.

Layers get violated constantly, and mostly for good reasons. A NAT box (Chapter 5.3) is a layer-3 device that rewrites layer-4 port numbers. A layer-7 load balancer reads the HTTP host header to decide where to route, which means it is terminating TCP connections it did not originate. A firewall inspecting packet contents is reaching from layer 3 up to layer 7. Every one of these is a layering violation, and every one of them is standard practice.

The cost of those violations is that the middle of the network stops being dumb, which breaks the end-to-end principle and makes protocols hard to change. This is called ossification, and it is the reason QUIC (Chapter 5.4) encrypts almost its entire header — not to hide anything from you, but to stop equipment in the middle from being able to make assumptions that would freeze the protocol in place. Encrypting the header is a design decision aimed at future changeability, not at privacy, which is one of the more elegant ideas in modern networking.

Performance leaks through the layers too. Chapter 5.4 will show that TCP's reliability guarantee causes head-of-line blocking: one lost packet stalls everything behind it, even data that arrived perfectly fine, because TCP promises an ordered byte stream and cannot deliver byte 500 before byte 400. The application layer knows those bytes belong to different images and does not care about the order — but it has no way to say so through the layer boundary. The abstraction is leaking, and HTTP/3 exists specifically to fix it.

What the interviewer will push on

"Explain the OSI model." The tell is whether you say that nothing runs it. The strong answer: seven layers as a reference model, four that are real in TCP/IP, and layer numbers 2, 3, 4 and 7 are the practically useful vocabulary because each names a different address type. The weak answer recites all seven with an example each.

"What is the difference between a layer 4 and a layer 7 load balancer?" Layer 4 sees IP addresses and ports and forwards without looking inside, so it is fast, protocol-agnostic and cannot route on the URL. Layer 7 terminates the connection and reads the HTTP request, so it can route on path, host or cookie, do TLS termination and rewrite headers — at the cost of decrypting and re-encrypting, and of being a real hop that must scale.

"Why is the internet packet-switched rather than circuit-switched?" Sharing (a link is only busy when a packet crosses it), survivability (reroute around a failure with no session teardown), and no setup cost. The price is that the network makes no delivery promises, which is why TCP exists.

"What is the end-to-end principle and why does it matter commercially?" Intelligence at the edges, dumb fast middle. It matters because adding a new application needs no change to the network — which is why the web, video calls and streaming all appeared without upgrading a single router, and why the telephone network could never have grown a web.

"Is Postel's Law good advice?" The strongest answer disagrees with it, with reasons. Being liberal in what you accept means broken senders never learn they are broken, so the breakage spreads and becomes the standard — HTML is the cautionary tale. Modern protocols are deliberately strict for exactly this reason.

"Why has IPv6 taken thirty years?" Because a protocol's value comes from universal adoption, so there is no incentive for any one party to move first, and NAT relieved enough of the pressure to remove the emergency. This question is really testing whether you understand that network standards are governed by incentives rather than by technical merit.

One thing to volunteer: point out that QUIC encrypts its transport header not for privacy but to prevent ossification — to stop middleboxes forming dependencies that would make the protocol impossible to evolve. It shows you understand that protocol design is partly about defending against the network you will have in ten years.

Recall

• Networks are layered so that each layer answers the previous layer's limitation: the link layer reaches only the next box, so IP chains hops; IP makes no delivery promise, so TCP adds reliability; TCP delivers meaningless bytes, so HTTP gives them meaning.
• Encapsulation: each layer wraps the layer above in its own header, and each header names what comes next — which is how the receiver unwraps with no guessing. The cost is ~54 bytes per packet.
• The four real layers are Link · Internet · Transport · Application; OSI's seven are a reference model nothing implements, but its layer numbers 2, 3, 4 and 7 are the working vocabulary, each naming a different address type (MAC · IP · port · content).
• Packet switching beats circuit switching on sharing, survivability and setup cost, and pays for it by making no delivery guarantees.
• The end-to-end principle puts intelligence at the edges and keeps the middle dumb and fast — which is why new applications need no change to the network.
• Standards hold through network effects rather than enforcement: the IETF's rough consensus and running code requires two interoperating implementations before a specification is finalised. The same force makes established protocols nearly impossible to change (ossification), which is why QUIC encrypts its header.

Self-test: Give the four layers and the one question each answers · Why does each header contain a field naming what follows? · What exactly does a layer-7 load balancer do that a layer-4 one cannot, and what does it cost? · Why is Postel's Law now considered a mistake? · Why did HTTP/3 have to be built on UDP rather than by fixing TCP?

Next: 5.2 goes to the bottom of the stack and stays there — how a voltage on a wire becomes a frame with an address on it, what a switch actually learns, and why your laptop shouts a question at the whole network before it can send anything at all.