How networks actually work (without the OSI poster).

The standard introduction to networking is a layered cake – seven of them, in the OSI model – followed by a poster on the wall and a quiz. We will skip the poster. The most useful way to learn what is going on is to trace a single curl request and stop to explain everything that happens to it.

The request

This is what you type:

$ curl -v https://example.com/

From the moment you press Enter to the moment you see HTML, the bytes pass through five conversations. Each one adds something, and at each one an attacker can do something hostile.

1. DNS – turning a name into an address

Your computer does not know what example.com is. It asks a resolver (often your router; the router often asks your ISP). The resolver, in turn, asks one of the root servers, then the .com server, then example.com's own server. The answer is an IP address, typically 4 bytes for IPv4 or 16 bytes for IPv6.

$ dig +short example.com
93.184.216.34

What an attacker can do here: if they sit between you and the resolver, they can lie and send you to their server instead. This is "DNS spoofing". DNS-over-HTTPS (DoH) and DNSSEC exist to make this harder.

2. TCP – opening a reliable pipe

Now your computer has an IP. It opens a TCP connection to port 443 on that IP. TCP is the layer that turns the lossy, out-of-order chaos of the internet into something that feels like a phone line: bytes arrive, in order, exactly once.

The handshake is three packets, often visualised as SYN, SYN-ACK, ACK.

  you → them  SYN     seq=x
them → you   SYN-ACK seq=y ack=x+1
  you → them  ACK     ack=y+1

Once that is done, both sides have a session and can stream bytes.

What an attacker can do here: the classic SYN flood is to send millions of SYNs and never reply, exhausting the server's connection table. On a LAN, ARP spoofing redirects the IP layer below so the TCP connection terminates on the wrong machine: a real "machine in the middle" attack.

3. TLS – making the pipe confidential

You used https://, so TCP alone is not enough. TLS now layers on top, doing three things in roughly one round-trip:

1. Authentication: the server proves it is example.com by presenting a certificate signed by a CA your computer already trusts.
2. Key exchange: the two sides agree on a shared symmetric key, using a public-key handshake (ECDHE). Your computer never sends the key directly: it derives it from a public exchange that an eavesdropper cannot reverse.
3. Cipher selection: they pick a symmetric cipher (AES-GCM or ChaCha20-Poly1305) and start encrypting and authenticating each record.

What an attacker can do here: mostly nothing: that is the point. But if they have tricked you at the DNS layer into resolving to their server, and they have somehow gotten a valid certificate for example.com (rare), they can read everything. This is why certificate transparency logs exist – every publicly trusted certificate gets published to an append-only log, so a mis-issued certificate for example.com becomes visible to the world, not just to whoever is using it. If you want the full mechanics of the trust chain behind that padlock – DV vs OV vs EV, how a CA gets trusted in the first place, how CT logs actually work – that's a deeper piece on its own.

4. HTTP: the application speaks

Inside the encrypted pipe, your computer now sends an HTTP request. The whole thing is text:

GET / HTTP/1.1
Host: example.com
User-Agent: curl/8.0
Accept: */*

The server replies with a status line, headers, a blank line, and the body. HTTP/2 and HTTP/3 frame this differently for performance but the semantics are the same.

What an attacker can do here: almost everything interesting in web security is at this layer. Header injection, smuggling, session fixation, CSRF, the entire OWASP Top 10: they all live in the request and the response, not in TCP or TLS.

5. The reply, all the way back

The response goes back through TLS (encrypted and authenticated), through TCP (split into segments, acknowledged, reassembled), through IP (routed hop by hop), and is finally handed to curl, which prints it.

The mental model

If you keep one diagram in your head, make it this one:

Every attack you will ever read about lives in one of these rows. Once you can place a new attack on the table, you already know half of how to defend against it.

TCP vs UDP: the same dropped packet, two different endings

The whole walkthrough above used TCP, because HTTPS needs a reliable stream. But TCP is not the only way to move bytes across IP – UDP (User Datagram Protocol) is the other major transport, and it makes the opposite trade-off: no handshake, no acknowledgements, no retransmission, no ordering guarantee. It just sends the packet and moves on. The clearest way to understand why that matters is to drop the same packet in both.

Five packets sent, packet 3 lost in transit, in both cases:

TCP:  1  2  [3 lost]  4  5
       receiver sees 1, 2, then a gap - holds 4 and 5 back
       sender gets no ACK for 3, retransmits it after a timeout
       3 arrives late → app receives 1 2 3 4 5, in order, nothing missing

UDP:  1  2  [3 lost]  4  5
       receiver sees 1, 2, then just... 4, 5
       no ACK exists to notice the gap, nothing gets retransmitted
       app receives 1 2 4 5 - packet 3 is simply gone, forever

Neither behaviour is "better": they are optimised for different problems. TCP's retransmission is exactly right for a web page or a file: you would rather wait an extra 100ms than render a page with a missing chunk. UDP's indifference is exactly right for a voice call, a video stream, or a multiplayer game's position updates: a retransmitted packet for a video frame from two seconds ago is worse than useless, because by the time it arrives the moment has passed. This is also why DNS (the very first step of this whole request) defaults to UDP: a query and its answer are small enough to fit in a single packet, and it is faster to just ask again on failure than to pay for a handshake first. DNS only falls back to TCP for large responses, such as zone transfers or answers padded with DNSSEC signatures.

Modern protocols increasingly build their own reliability on top of UDP instead of relying on TCP: QUIC, the transport underneath HTTP/3, does exactly this: it gets UDP's speed and avoids one specific TCP weakness called head-of-line blocking, where a single lost packet stalls every stream multiplexed on that connection, even ones that had nothing to do with the loss.

What an attacker can do with UDP specifically: because there is no handshake to establish first, UDP is the workhorse behind reflection and amplification DDoS attacks. An attacker sends a small query with a forged source IP to an open DNS or NTP server; the server dutifully sends its (much larger) reply not to the attacker, but to whatever address was forged into the source field: the victim. TCP's three-way handshake makes this specific trick far harder, because the SYN-ACK is sent to the address in the SYN and the connection cannot actually proceed until that address replies, leaving no third party to reflect off of in the same way.

The OSI model, since you asked

We promised to skip the poster at the start of this article, and technically we still have – everything above was the four-layer model networking engineers actually build software around. But now that you have watched a real request cross DNS, TCP, TLS, and HTTP, the seven-layer OSI model stops being an abstract diagram and turns into an index of things you already saw happen. It is worth five minutes now, because "layer 3 problem" and "layer 7 firewall" are phrases you will hear used precisely for the rest of your career.

The honest version: almost nothing in the real world implements seven distinct layers. TLS, sessions, and encoding all collapse into "the application" in practice, and Data Link and Physical are usually one network card and one driver. The four-layer TCP/IP model is what your operating system's network stack – and this entire article – actually followed. The seven-layer model earns its keep as shared vocabulary anyway: when a colleague says a problem is "layer 3," they mean routing, not code; "layer 7" means the application is misbehaving, not the network under it. That distinction alone saves entire meetings.

Frequently asked questions