What Actually Happens When You Hit Enter: TCP/IP, DNS, and HTTP From First Principles

You type reddit.com into your browser and press Enter. Half a second later, a page appears. Inside that half second, your computer asked a global, decentralized phone book for an address, negotiated a reliable connection with a machine it had never talked to before, and then held a very structured, very terse conversation with it — all before a single pixel of that page existed on your screen.

Most developers can name these layers — DNS, TCP/IP, HTTP — without being able to explain why they're built the way they are. That's the gap this post is for. The implementation details (which cipher suite, which HTTP version, which cloud provider's resolver) will change. The problems these protocols solve, and the trade-offs baked into their solutions, will not. That's what makes this genuinely evergreen: you're not learning trivia, you're learning the shape of every networked system you'll ever debug.

The Shortest Possible Version

Three layers, three different jobs:

DNS    → "What's the address for this name?"
TCP/IP → "Get these bytes there reliably, in order."
HTTP   → "Here's the actual request/response conversation."

Each one exists because the layer below it refused to solve a problem, on purpose. Let's go layer by layer.

Layer 1: DNS — The Internet Doesn't Know What "reddit.com" Means

Computers route traffic using IP addresses (151.101.65.140), not names. reddit.com is a convenience for humans that has to be translated before anything else can happen. DNS is that translation system — and it's designed less like a lookup table and more like a chain of increasingly specific referrals.

Here's the actual chain of custody for a name your machine has never resolved before (assume the local machine and OS caches both miss):

sequenceDiagram
    participant B as Browser
    participant R as Recursive Resolver
    participant Root as Root Nameserver
    participant TLD as .com TLD Nameserver
    participant Auth as reddit.com Authoritative NS

    B->>R: Where is reddit.com?
    R->>Root: Where is reddit.com?
    Root-->>R: No idea — ask the .com servers
    R->>TLD: Where is reddit.com?
    TLD-->>R: No idea — ask reddit.com's own NS
    R->>Auth: Where is reddit.com?
    Auth-->>R: 151.101.65.140 (TTL 300s)
    R-->>B: 151.101.65.140
    Note over R,B: Cached at the resolver (and often the browser) for 300s

This is a deliberately hierarchical, distributed system — no single server holds the whole internet's address book, and no single failure takes it down. That design choice is the entire point: it trades a few extra round trips (mitigated heavily by caching) for a system that has never had a global outage in 40 years.

A few record types you'll actually encounter:

Every record ships with a TTL (time to live) — the resolver caches the answer for that many seconds so it doesn't have to repeat the whole chain next time. This is why DNS changes ("I updated my DNS and it's not working!") take time to propagate: some resolver, somewhere, is still trusting a cached answer.

Try it yourself: dig +trace reddit.com will show you this exact chain of referrals happening live.

Layer 2: TCP/IP — Turning "Best Effort" Into "Reliable"

Now your browser has an IP address. It needs to get bytes there and back. This is where IP and TCP split responsibilities in a way that's worth understanding precisely, because the split explains almost every "why is the network slow/flaky" question you'll ever debug.

IP (Internet Protocol) does exactly one job: address packets and route them, hop by hop, toward a destination. It makes zero promises. Packets can arrive out of order, get duplicated, or vanish entirely, and IP will not tell you. It's deliberately "dumb" — that simplicity is why the internet scales; routers don't have to track connection state, they just forward packets and move on.

TCP exists entirely to paper over that unreliability for applications that need it. It adds:

• Ordering — every byte gets a sequence number, so the receiver can reassemble things correctly even if packets arrive out of order.

• Reliability — the receiver ACKs what it got; unacknowledged data gets retransmitted.

• Flow control — the receiver advertises how much buffer it has, so the sender doesn't drown it.

• Congestion control — the sender starts slow and ramps up (“slow start”), backing off when it detects packet loss, so one connection doesn't monopolize a shared link. The exact backoff math is pluggable — older stacks used Reno, most Linux systems default to CUBIC today, and BBR (used heavily by Google and increasingly elsewhere) takes a different approach based on measured bandwidth and latency rather than reacting to loss.

Before any of your data moves, though, TCP has to set up shop. That's the three-way handshake:

sequenceDiagram
    participant C as Client
    participant S as Server

    C->>S: SYN (seq=X)
    S-->>C: SYN-ACK (seq=Y, ack=X+1)
    C->>S: ACK (ack=Y+1)
    Note over C,S: Connection established — 1 full RTT spent, zero app data sent yet

Notice: zero application data has moved yet. This is a full round trip spent just agreeing to talk. If the connection is also encrypted (HTTPS), a TLS handshake stacks on top of this — another 1–2 round trips before your first meaningful byte. This is the single biggest reason "just add HTTPS" or "just hit a new host" feels slow on high-latency connections: you're paying round-trip cost for setup, not data transfer.

(A real edge case worth knowing about: TCP Fast Open lets a client send data alongside the initial SYN on repeat connections to a host it's talked to before, shaving off that first empty round trip. It's not universally deployed, so treat it as an optimization you might see, not something to assume.)

And this is all wrapped in layers, quite literally — every HTTP message you send gets stuffed inside a TCP segment, which gets stuffed inside an IP packet, which gets stuffed inside an Ethernet (or Wi-Fi) frame:

graph TD
    subgraph Frame["Ethernet Frame (adds MAC addresses)"]
        subgraph Packet["IP Packet (adds source/dest IP)"]
            subgraph Segment["TCP Segment (adds ports, seq/ack numbers)"]
                HTTPMsg["HTTP Message — your actual request/response"]
            end
        end
    end

Each layer only cares about its own header and treats everything inside it as opaque payload — a router reading the IP header doesn't parse the HTTP inside, and a switch reading the Ethernet header doesn't parse the IP inside. That separation of concerns is why the stack is layered in the first place: each layer can evolve independently as long as it honors the interface to the one above and below it.

Try it yourself: run tcpdump or open Wireshark during any request and you'll see the SYN / SYN-ACK / ACK handshake happen before you see any HTTP at all.

Layer 3: HTTP — Finally, the Actual Conversation

With a reliable pipe established, HTTP is refreshingly simple: a plain-text (or binary-framed, in newer versions) request/response exchange. A real request looks like this:

GET /r/programming HTTP/1.1
Host: reddit.com
User-Agent: Mozilla/5.0
Accept: text/html

And the response:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 48213

<!DOCTYPE html>...

The method (GET, POST, PUT, DELETE, …) states intent. The status code states outcome, and the categories are worth knowing cold:

The detail that trips people up most: HTTP is stateless by design. The protocol has no concept of "this request is from the same person as the last one." Every request stands alone. Cookies and session tokens aren't part of HTTP's core model — they're an application-layer workaround, bolted on so servers can pretend there's continuity. Every "why did I get logged out," "why is my session weird across tabs" bug traces back to this one design decision.

HTTP has evolved mainly to attack one problem: doing more over the connection TCP already paid to set up.

• HTTP/1.1 introduced keep-alive — reuse one TCP connection for multiple requests instead of a fresh handshake each time. Still, requests on that connection are answered one at a time.

• HTTP/2 multiplexes many requests over a single connection simultaneously (binary framing, interleaved streams), plus header compression. The catch: it still rides on one TCP connection, so if a single packet gets lost, every stream on that connection stalls waiting for it — head-of-line blocking has just moved down a layer instead of disappearing.

• HTTP/3 (standardized in 2022 as RFC 9114, running over the QUIC transport defined in RFC 9000) replaces TCP with QUIC, which sits on top of UDP instead. Each stream is now independent at the transport level, so one lost packet only stalls its own stream. QUIC also folds the TLS handshake in natively, and supports resuming a previous session with 0-RTT, shaving off round trips during connection setup rather than just adding a separate one on top of TCP's.

Try it yourself: curl -v https://reddit.com prints the entire handshake and request/response conversation, headers and all.

Putting It Together: Where the Time Actually Goes

Here's every layer from this post, in order, as one timeline — the thing that actually matters for perceived speed is how many of these round trips stack up before your server even sees the request:

Add those up honestly and you get two very different numbers depending on whether this is a first visit or a repeat one — conflating them into one range is a common way this kind of explainer gets sloppy, so worth being precise:

• Cold — first-ever visit: DNS (1 RTT) + TCP handshake (1 RTT) + TLS handshake (1 RTT on TLS 1.3, 2 on TLS 1.2) + HTTP request/response (1 RTT) = 4–5 RTTs before the first byte of content arrives.

• Warm — repeat visit: DNS is cached (0), the TCP connection is often kept alive or fast-opened, and TLS can resume the previous session with 0-RTT data — collapsing the whole setup cost down to as little as 1 RTT, just the HTTP exchange itself.

On a connection with 150ms latency (a fairly normal mobile RTT), that's the difference between roughly 150ms and 600–750ms spent on setup alone. This single fact is why CDNs, connection reuse, DNS prefetching, TLS session resumption, and HTTP/3 all exist — they're all, in different ways, attacks on that round-trip count.

Why This Is Worth Actually Knowing

Frameworks and cloud providers will keep changing. This won't:

• Debugging — "is it DNS, is it the connection, or is it the app?" is answerable in minutes with dig, curl -v, and a packet capture, once you know what each layer is supposed to look like.

• Performance intuition — you'll recognize latency problems as round-trip problems, not mysteries.

• System design — every distributed system you build faces DNS's problem (find the right node), TCP's problem (make an unreliable channel reliable), and HTTP's problem (agree on a conversation format). You're not learning three protocols; you're learning three patterns you'll re-encounter under different names for the rest of your career.

That's the actual payoff of "absolute evergreen" knowledge: you write the mental model once, and it keeps paying rent for decades.