Networking · 11 min

Network layers

Build a real packet by hand: 42 bytes of HTTP inside three envelopes, and which boxes on the way open which one.

You call fetch("http://example.com/hello"). Your code hands 42 bytes of text to the operating system, and a moment later a server on another continent reads exactly those 42 bytes.

In between, your Wi-Fi box, a dozen routers owned by different companies and the server’s network card all handle them. Not one of those boxes knows what HTTP is. How does that work?

You have probably heard the answer is “the OSI model”, with its seven numbered layers, and it never stuck. So skip the list. Here you build the packet yourself, one envelope at a time, and each envelope exists because the one before it can’t finish the trip alone.

Why split the trip at all

The request crosses your Wi-Fi, a fibre line and a data centre’s cables. Each runs on different hardware, and new kinds keep arriving. If every box had to understand the whole message, a new Wi-Fi standard would mean updating every browser.

So the work is split into four small jobs, and each job adds its own envelope. A box only opens the envelopes it needs. Your browser code never thinks about Wi-Fi, and a router never thinks about URLs. That split is all “layers” means.

What you start with: 42 bytes

The browser writes this. It is plain text, three lines long:

GET /hello HTTP/1.1\r\n
Host: example.com\r\n
\r\n

This is the application layer: it says what you want. It says nothing about how to get there. Assume your laptop already knows the server’s address, 93.184.216.34 (looking that up is DNS’s job).

Envelope one, TCP: which program, in what order

A server runs many programs at once. You know this from localhost:3000 versus localhost:5432: the number after the colon picks the program. That number is a port. Web servers listen on port 80 for plain HTTP and port 443 for HTTPS.

So TCP wraps the 42 bytes in a 20-byte header. It holds the destination port, 80, and a source port, 52114, that your laptop picked for this one connection, so the reply comes back to it and not to another connection your laptop has open.

It also holds a sequence number, 1001. Long messages are cut into many packets that can arrive out of order or not at all, so TCP numbers every byte it sends. The header carries only the number of the first byte in this packet: your request’s bytes are 1001, 1002, 1003 and so on. (Numbering starts from a value picked when the connection opened, not from 1.) The numbers let the other side put the pieces back in order and ask for missing ones again.

Envelope two, IP: which machine

TCP knows the program but not the machine. So IP wraps everything in another 20-byte header with two addresses: from 192.168.1.20 (your laptop) to 93.184.216.34 (the server).

This is the only envelope routers care about. A router is a box that reads the destination address and passes the packet one step closer to it.

The IP header also carries a checksum of itself, so a router can spot a damaged header. TTL changes at every router, so that checksum is recalculated every time too.

Envelope three, Ethernet: just the next box

Here is the part that surprises people. The IP address says where the packet ends up, but a cable or Wi-Fi signal only reaches devices on the same local network. Your laptop can’t hand anything to a server in another country. It can only hand it to your home router.

So the outer envelope is addressed from your laptop’s MAC to your home router’s MAC, 3c:22:fb:0a:00:01. It has a 14-byte header at the front and a 4-byte checksum at the back that lets the receiver spot damaged bits (the demo calls it “Frame check (CRC-32)”). A packet in its Ethernet envelope is called a frame.

The numbers here are for a laptop plugged in by cable, which is what the demo builds. On Wi-Fi the outer envelope is a few dozen bytes bigger, but it does the same job: reach the next box, nothing further.

The trip: who opens what

Every router does the same three things: open the Ethernet envelope, read the destination IP, then lower TTL by one and put the packet in a fresh Ethernet envelope addressed to the next router. Each step from one box to the next is called a hop, and a real trip has 10 to 20 of them.

So the outer envelope is replaced at every hop, while the IP envelope inside travels the whole way. That is the difference between “the next box” and “the final machine”.

Your home router has two network cards, each with its own MAC: one facing your home (…:01) and one facing your internet provider (…:02). That is why its outgoing envelope is sent from …:02.

At the server, each layer removes its own envelope in reverse order (steps 7 to 10). Your server code then reads the same 42 bytes the browser wrote. It never sees a MAC address, a TTL or a sequence number. The reply makes the same trip in the other direction.

So where did the seven OSI layers go?

The OSI model is a textbook picture with seven layers, numbered from the cable up. The internet actually runs the four you just built. The numbers survived, which is why engineers still say them:

• L1, physical: the electrical or radio signal itself. No envelope, so the demo leaves it out.
• L2, link: Ethernet or Wi-Fi.
• L3, network: IP.
• L4, transport: TCP.
• L5 and L6, session and presentation: on the internet these have no envelope of their own. Their work, such as HTTPS encryption, happens inside the application. HTTPS is not an extra envelope: it scrambles what is inside the HTTP envelope, while the TCP, IP and Ethernet envelopes stay readable.
• L7, application: HTTP.

So when someone says “an L4 load balancer” or “L7 routing”, the number tells you the innermost envelope that box opens.

Picking a box that opens the right envelope

Now you can read any network device by asking one question: which envelopes does it open? The demo’s “Who reads which layer?” buttons light up each answer.

Suppose you want /api to go to one group of servers and /images to another. The path lives inside the HTTP envelope, so an L4 balancer never sees it. You need L7, and you pay for it in CPU per request.

The byte count matters too. Every packet carries at least those 58 bytes of headers. For a 42-byte request that is more than half of what you send. That is why chatty systems batch small messages, so many of them share one set of headers. They also keep one connection open for many requests, as HTTP/2 and gRPC do, so they don’t wait a full round trip for a new handshake before every request.