Networking is how machines find each other and exchange data. It is built in layers, each one relying on the one below and hiding its details from the one above. As an application developer you mostly work at the top, but knowing what happens underneath explains a lot of system design: why handshakes cost latency, why connection reuse matters, and why some load balancers are faster than others.
The OSI model#
The OSI model splits networking into seven layers. In practice you only need to reason about three of them: network (3), transport (4) and application (7).
| Layer | Name | What it does | Examples |
|---|---|---|---|
| 7 | Application | Where your code lives. Defines what the messages mean. | HTTP, DNS, SMTP, FTP |
| 6 | Presentation | Formatting and encryption of data. | TLS, JSON, ASCII |
| 5 | Session | Managing conversations between applications. | Sockets |
| 4 | Transport | How data is delivered between two programs. | TCP (reliable), UDP (fast) |
| 3 | Network | Addressing and routing packets across networks. | IP, routers |
| 2 | Data link | Moving frames between machines on the same local network. | Ethernet, MAC addresses, switches |
| 1 | Physical | The actual signal. | Fibre, copper, Wi-Fi radio |
TLS is often listed at layer 6, but in day-to-day engineering people usually talk about it as sitting between TCP and HTTP. Don't worry about the exact layer number. What matters is that HTTPS is HTTP running over TLS running over TCP.
Layer 3: network#
Gets a packet from one machine to another, possibly across many networks. Every device has an IP address, and routers read that address to choose the next hop. See Network Layer Protocol.
Layer 4: transport#
Decides how the packets are delivered between two programs:
- TCP – every byte arrives, in order, with no duplicates. It sets up a connection first.
- UDP – packets may arrive out of order or not at all, but there is no setup and less overhead.
See Transport Layer Protocols.
Layer 7: application#
Turns your intent ("fetch this user's profile") into a protocol message, such as an HTTP request, that the lower layers know how to carry. See Application Layer Protocols.
Each layer wraps the one above#
When you send an HTTP request, each layer adds its own header around the data it received from above. The receiver unwraps them in reverse order. This is called encapsulation.
Example: loading a web page#
What happens when you type a URL and press Enter? Here is the sequence for a plain HTTP request over TCP.
- DNS resolution. The browser asks a DNS resolver to turn the domain name (for example
example.com) into an IP address. - TCP handshake. The client opens a connection with three messages:
- SYN – client: "I'd like to connect."
- SYN-ACK – server: "Got it, I'm ready too."
- ACK – client: "Great, we're connected."
- HTTP request. The client sends
GET /over the connection. - Server processing. The server runs your code, maybe queries a database, and builds a response. This is usually the only part of the latency most engineers think about.
- HTTP response. The server sends back a status code, headers and the page.
- TCP teardown. The connection is closed with four messages: client FIN, server ACK, server FIN, client ACK.
With HTTPS, a TLS handshake also happens after the TCP handshake and before the HTTP request, adding more round trips.
Why this matters for system design#
Three ideas from the lower layers shape everyday design decisions.
TCP hides a lot of work#
You can usually treat the network as a black box. TCP takes care of reliability, ordering and retransmission for you. You only drop down to UDP when speed matters more than getting every packet, as in live video, voice calls or games.
One request is many packets#
A single layer 7 request turns into many layer 4 and layer 3 packets, plus handshakes. The more of the message a component has to understand, the more work it does. This is why an L4 load balancer (looks only at IP and port) is cheaper per request than an L7 load balancer (parses the HTTP request). See Protocols: Layer 4 and 7.
Connections are expensive, so reuse them#
The TCP handshake (and the TLS handshake on top) costs round trips before any useful data moves. Doing that for every small request is wasteful. Common fixes:
- Keep-alive: reuse one connection for many requests.
- Multiplexing (HTTP/2): send many requests over one connection at the same time.
- Persistent connections (WebSockets, SSE): for real-time updates, keep one connection open instead of reconnecting every second.
Key takeaways#
- For system design, focus on three layers: network (IP), transport (TCP/UDP) and application (HTTP and friends).
- Each layer wraps the data from the layer above with its own header.
- Loading a page means DNS lookup, TCP handshake, (TLS handshake), request, response and teardown, so latency is more than your server's processing time.
- TCP is the reliable default. UDP trades reliability for lower latency.
- Opening connections costs round trips, so reuse them with keep-alive, HTTP/2 or persistent connections.