Primers › Networking

The OSI model

Networking people describe almost everything by layer. A Network Load Balancer is “layer 4,” an Application Load Balancer is “layer 7,” a router is “layer 3,” and a problem gets narrowed down by asking which layer it’s at. Those numbers come from the OSI model (Open Systems Interconnection), a reference model that splits the job of getting data from one program to another into seven layers [1]. Every other primer in this topic uses its vocabulary, so it’s the place to start.

Why layers

Getting a web page from a server to your browser involves a lot of separate problems: turning bits into electrical or radio signals, getting data to the next device on the same network, finding a path across many networks, getting it to the right program on the far end without losing anything, and finally what the data actually means. Layering gives each problem to one layer:

• Each layer uses the layer below it without caring how that layer works.
• Each layer serves the layer above it without caring what that layer is doing.

So your browser doesn’t care whether you’re on Wi-Fi or a cable, and the cable doesn’t care whether it’s carrying a web page or a video call. You can swap out one layer (move from Wi-Fi to Ethernet, or from HTTP/1.1 to HTTP/2) without touching the others.

The seven layers

Layers are numbered from the bottom up, starting with the physical signal. Each one has its own kind of address and its own name for a chunk of data:

If you need a way to remember the order from layer 1 up, the classic mnemonic is “Please Do Not Throw Sausage Pizza Away” (Physical, Data link, Network, Transport, Session, Presentation, Application).

Addresses at layers 2, 3, and 4

Three of those layers have their own kind of address, and each one narrows things down further:

• A MAC address (layer 2) identifies a network interface on the local network, like 00:00:5e:00:53:01 [2]. It only matters for the next device the data is handed to.
• An IP address (layer 3) identifies a machine anywhere on the internet, like 203.0.113.10. It stays on the data the whole trip (IP addresses and CIDR).
• A port (layer 4) is a number that picks out one program on that machine. The IP address gets data to the right building, and the port is the apartment number inside it. Servers listen on well-known ports, like 443 for HTTPS, 22 for SSH, and 53 for DNS [3]. Clients pick a random high port for their end of each connection, called an ephemeral port.

The model the internet actually uses

The OSI model is a way of describing networking, not how the internet’s protocols were actually designed. The internet’s own model, usually called the TCP/IP model, has four layers [4]:

Layers 5 and 6 never really became separate pieces in practice. Applications and libraries do that work themselves. So in day-to-day use, the numbers people actually say are 1, 2, 3, 4, and 7, and the OSI numbering survives mostly as shared vocabulary. When a product says it works “at layer 7,” it means it understands the application protocol, and “layer 4” means it only sees connections and ports.

TLS isn’t the transport layer, despite its name

Real protocols don’t always fit the model neatly (the internet’s own standards call strict layering “an imperfect model” [4]), and TLS is the usual example. It sits on top of TCP and underneath HTTP, encrypting everything above it, so it gets described as layer 6, layer 4.5, or “part of the application,” depending on who you ask. The model is a map, and maps simplify.

Its name makes it more confusing. TLS stands for Transport Layer Security, which makes it sound like it belongs at layer 4 or replaced something there. It didn’t. TLS replaced SSL, an older encryption protocol (TLS 1.0 was built from SSL 3.0 [5]), which is why people still say “SSL certificate” for what’s now a TLS certificate. It never replaced TCP. TLS runs on top of TCP, and the transport layer is still TCP and UDP.

QUIC blurs the line more. It’s a newer transport protocol that runs on top of UDP and has TLS 1.3 built into it [6], [7], and HTTP/3 uses it instead of TCP [8]. So the two stacks for a web request look like this:

One request, from start to finish

Here’s a laptop on a home network loading https://www.example.com, which lives on a server at 203.0.113.10.

Before the first byte of the page

Loading a page takes more than one request. Here’s everything that happens, in order, the first time:

1. Join the network. When the laptop connects, DHCP gives it an address (192.168.1.20), the home router’s address as its default gateway (192.168.1.1), and a DNS server to use.
2. Find the router. To send anything off the local network, the laptop needs the router’s MAC address, so it asks with ARP. The answer gets cached and reused for everything after.
3. Look up the name. The laptop asks DNS for www.example.com and gets 203.0.113.10 (How DNS resolution works covers that lookup step by step).
4. Open a connection. TCP sets up a connection with the server in a three-way handshake: the laptop sends a SYN (“let’s talk”), the server answers SYN-ACK (“okay”), and the laptop sends an ACK (“okay, starting”) [9].
5. Agree on encryption. TLS does its own handshake over that connection. The server shows its certificate, the laptop checks it, and they agree on keys [10].
6. Send the request. Now the browser can finally send GET /, which is what the next section follows down the stack.

Steps 1 and 2 happen once and get reused. Steps 3 through 5 happen for each new server, which is part of why the first visit to a site feels slower than the second.

Down the stack: encapsulation

On the way down, each layer wraps the data from the layer above in its own envelope, with its own addresses on the outside. That’s called encapsulation:

1. Layer 7: the browser writes an HTTP request: GET / for host www.example.com [11].
2. TLS encrypts it, so nothing below it can read the request.
3. Layer 4: TCP puts the encrypted data in a segment from the laptop’s ephemeral port (say 51544) to port 443 on the server. TCP numbers what it sends and resends anything that doesn’t get acknowledged [9].
4. Layer 3: IP puts the segment in a packet from 192.168.1.20 to 203.0.113.10 [12].
5. Layer 2: Wi-Fi puts the packet in a frame addressed to the home router’s MAC address, not the server’s, because layer 2 only ever reaches the next device on the local network.
6. Layer 1: the frame goes out as radio signals.

Read the result from the outside in, and each layer’s header only holds what that layer needs:

Each layer wraps the one above it. A router only opens the outer two boxes, a load balancer at layer 4 opens three, and only the server (or something terminating TLS) can see the request itself.

Across the internet: hop by hop

A hop is one trip between two devices on the same local network, like the laptop to the home router, or one router to the next. At each router, only the bottom layers get unwrapped: the router strips off the layer 2 frame, reads the layer 3 destination address, looks it up in its route table to pick the next hop, and wraps the packet in a fresh layer 2 frame addressed to that next device. That’s the same idea as a route table’s target being the next hop: the packet carries its final destination, and each router just picks the next step.

So the layer 2 addresses change on every hop, and the layer 3 addresses stay the same, with one exception: the home router does NAT (network address translation). Private addresses like 192.168.1.20 can’t be used on the internet, so as the packet leaves the home network, the router swaps the private source address (and usually the port) for the home’s one public address and remembers the swap so it can undo it on the reply [13].

The reply makes the same trip backwards, from 203.0.113.10 to 198.51.100.7, and the home router swaps the destination back to 192.168.1.20 before handing it to the laptop.

Back up the stack at the server

At the server it goes back up: layer 2 checks the frame was for it, layer 3 checks the packet was for its address, layer 4 hands the data to whatever program is listening on port 443, TLS decrypts it, and the web server reads the HTTP request. The response goes through the same process in reverse.

ARP: from an IP address to a MAC address

A frame needs a MAC address and a packet needs an IP address, and something has to connect the two. That something is ARP, the Address Resolution Protocol [14]. It answers one question on the local network: “which MAC address has this IP address?” It’s a lot like DNS, just lower down: DNS turns a name into an IP address, and ARP turns an IP address into a MAC address.

Here’s step 2 of the timeline above, the first time the laptop needs to send something off the local network:

1. The laptop decides who’s next. 203.0.113.10 isn’t in the laptop’s own subnet, 192.168.1.0/24 (what a subnet is), so the packet has to go through the default gateway, the home router at 192.168.1.1, which DHCP told it about.
2. It checks its ARP cache for 192.168.1.1. If it’s there from a recent conversation, it’s done.
3. If not, it broadcasts an ARP request, sent to the special broadcast address ff:ff:ff:ff:ff:ff so every device on the local network hears it: “Who has 192.168.1.1? Tell 192.168.1.20.”
4. The router replies directly to the laptop: “192.168.1.1 is at 00:00:5e:00:53:01.”
5. The laptop caches the answer and addresses its frames to that MAC address.

A few things follow from how that works:

• The laptop never ARPs for the server. It only needs the MAC address of the next device, and the server isn’t on its network. If the destination were in the same subnet (a printer at 192.168.1.40, say), the laptop would ARP for the printer directly and skip the router.
• ARP stops at the router. Broadcasts don’t cross routers, so each router along the path does its own ARP on its own network to find the next hop’s MAC address.
• You can see the cache. arp -a on macOS and Windows, or ip neigh on Linux, lists the IP-to-MAC pairs the machine currently knows.
• IPv6 doesn’t use ARP. It does the same job with Neighbor Discovery [15].

DHCP: how a device gets its settings

A device joining a network needs a few settings before it can do anything: its own IP address, the size of the subnet it’s on, the default gateway’s address, and which DNS servers to use. Typing those in by hand on every phone and laptop would be miserable, so almost every network hands them out automatically with DHCP, the Dynamic Host Configuration Protocol [16]. On a home network the router is usually the DHCP server too.

When the laptop joins, it has no address yet, so the exchange starts with a broadcast [16]:

1. Discover. The laptop broadcasts “is there a DHCP server out there?”
2. Offer. The router offers an address (192.168.1.20) along with the other settings.
3. Request. The laptop asks to use that offer. (This step exists because more than one server might have answered.)
4. Acknowledge. The router confirms, and the laptop configures itself.

The other settings travel as numbered DHCP options: one for the subnet mask, one for the default gateway (DHCP calls it the “router” option), one for the DNS servers, and so on [17]. That’s also how the laptop knows which recursive resolver to ask.

The address is a lease, not a permanent assignment. The laptop has to renew it before it runs out, and if it leaves the network the address eventually goes back into the pool. That’s why a device’s IP address on a home network can change from one day to the next, and why servers usually get a fixed address or a reservation instead.

Where the things in the other primers sit

The higher a device works, the more of the envelope it opens, so the more it can see and the smarter its decisions can be. It also has to understand the protocol, which is why a layer 7 load balancer can route by URL path but only for HTTP, and a layer 4 one can carry anything but can’t look inside.

Using the layers to troubleshoot

When something can’t connect, working through the same order as the timeline keeps you from guessing. Each step has its own check:

Two catches:

• ping failing doesn’t mean the host is down. Ping uses ICMP [21], which a lot of firewalls and security groups don’t allow, so a host can block ping and still serve web traffic fine. Check the port directly with nc before concluding anything.
• A timeout and a refusal are different layers. “Connection timed out” usually means nothing came back at all, so a firewall dropped the traffic or there’s no route (layers 3–4). “Connection refused” means the machine answered and said nothing is listening on that port, so the network is fine and the problem is the service.

UDP gets less of this help, since it has no connection to set up and no delivery checks [22]. A UDP request that gets no answer looks the same whether it was blocked, lost, or ignored.

References

Every source cited across the primers is collected on one page.