The Nine Protocols Behind Every System Design

How the Protocols Fit Together

Part 0 · The map

Every system you design has the same job at its base: move bytes between machines across networks that nobody fully controls. No single protocol does the whole job. Instead, each protocol solves one slice of it and hands the rest to the layer above. The nine protocols in this guide are that division of labor.

flowchart TB
  A["HTTP + Methods<br/>give the bytes meaning"] --> B["TLS (formerly SSL)<br/>make them secret and proven"]
  B --> C["TCP / UDP / QUIC<br/>deliver them reliably — or fast"]
  C --> D["IP<br/>route them to the right machine"]
  E["DNS<br/>find the machine's address first"] -.-> C
  style A fill:#FFD84D,stroke:#111111
  style E fill:#FFFFFF,stroke:#111111
          

Keep two ideas in hand while you read. First, layering: a protocol trusts the layer below it and hides its own work from the layer above. HTTP never thinks about lost packets, because TCP handles them; TCP never thinks about routes, because IP handles them. Second, the round trip time (RTT): the time for a message to reach the other machine and for the reply to come back. Between distant cities — say Tokyo and Dubai — one RTT is roughly 150–200 milliseconds. Every protocol that needs a setup conversation charges at least one RTT before real data moves, so RTTs are the currency this guide counts in.

IP — Addresses and Packets

Part 1 · The routing layer

What it is. The Internet Protocol (IP) is the base layer of the internet. It moves small blocks of data between machines by address, and it promises nothing else.^[1]

How it works. IP gives every machine an IP address — a numeric label such as 203.0.113.10 that identifies it across all connected networks.^[1] Data does not travel in one piece. IP cuts it into packets, and each packet carries its destination address and crosses the internet alone. Every router on the path reads only that address and passes the packet one hop closer. No router knows the full path, and no router remembers the packet afterward.

What it costs. This design is called best-effort delivery: routers try, and nothing is guaranteed.^[1] A busy router may drop your packet. Two packets may take different paths and arrive in the wrong order. A packet may even arrive twice. And an IP address names a machine, not a program on it — so IP alone cannot say which service should receive the data.

TCP — The Reliable Connection

Part 2 · Transport, option one

What it is. The Transmission Control Protocol (TCP) runs on top of IP and turns unreliable packets into a connection: a two-way byte stream that arrives complete, in order, and without duplicates.^[3] It is the default transport for most of the internet — databases, queues, APIs, the classic web.

How it works. TCP numbers every byte with a sequence number, and the receiver answers with acknowledgments (ACKs) meaning "I have everything up to N". From those numbers, everything follows: a gap means loss, so the sender retransmits; out-of-order packets are re-sorted; duplicates are recognized and dropped.^[3] TCP also adds ports — numbers that name a program on a machine — so 203.0.113.10:443 means "the web service on that server". A connection starts with the three-way handshake:

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: SYN — "I want to connect"
  S->>C: SYN-ACK — "Accepted"
  C->>S: ACK — "Agreed" (data can now flow)
  Note over C,S: 1 RTT before the first byte of real data
          

Two built-in behaviors are worth knowing by name. Flow control stops a fast sender from drowning a slow receiver. Congestion control protects the network: TCP starts slowly, speeds up while packets survive, and slows down sharply when loss appears.^[3] That is why transfers "ramp up".

Inside a TCP segment. TCP wraps each piece of data in a segment: the data plus a header of at least 20 bytes.^[3] The header is worth one look, because every mechanism above lives in one of its fields — the header is the protocol:

The core TCP header fields ^[3]. The handshake in the diagram above is simply segments with the SYN and ACK flags set.

The problems of TCP. TCP's guarantees are real, and so are their prices. Four of them shape modern protocol and system design:

1. Setup latency. The handshake spends one RTT before any data moves — and encryption adds its own round trip on top (see TLS), so a fresh secure connection costs two RTTs of silence.
2. Head-of-line (HOL) blocking. TCP promises one ordered stream. So when a single packet is lost, every byte behind it must wait for the retransmission — even bytes that belong to unrelated files sharing the connection.^[12][13] The problem grows worse exactly where networks are worst: lossy mobile links.
3. The connection is glued to the addresses. A TCP connection is identified by the two IP addresses and ports at its ends. When a phone walks from Wi-Fi to 5G, its IP address changes — and every TCP connection it held dies and must be rebuilt.
4. TCP is nearly impossible to change. TCP lives inside operating-system kernels and is inspected by millions of routers and firewalls that drop anything unfamiliar. Improving it takes decades. This ossification is why engineers who wanted a better transport did not fix TCP — they built a new one on top of UDP instead (Part 4).

flowchart LR
  subgraph TCP ["One TCP stream"]
    a1["pkt 1 ✓"] --> a2["pkt 2 ✗ lost"] --> a3["pkt 3 ✓ waits"] --> a4["pkt 4 ✓ waits"]
  end
  style a2 fill:#FF5B3E,stroke:#111111,color:#FFFFFF
          

UDP — Speed Without Promises

Part 3 · Transport, option two

What it is. The User Datagram Protocol (UDP) is the minimal transport: it adds ports and a checksum to IP, and deliberately nothing else.^[2] Its specification is three pages long.

How it works. A UDP message is one packet with a destination port, so it reaches the right program on the right machine.^[2] There is no connection and no handshake: the first packet you send already carries data, so UDP costs zero RTTs of setup. Loss, reordering, and duplication pass straight through from IP — they are your application's problem now.

Inside a UDP datagram. The entire UDP header is four fields in 8 bytes: source port, destination port, length, and checksum.^[2] Put that beside TCP's 20+ byte header and the philosophy is visible in the numbers — every field TCP has and UDP lacks (sequence numbers, acknowledgment numbers, flags, window) is a promise UDP chose not to make. No sequence numbers means no ordering; no acknowledgments means no retransmission; no flags means no connection to open or close.

What it costs. The guarantees you did not buy. If delivery matters, you must detect loss and retry yourself. That sounds like a defect, until you meet the workloads where the guarantees themselves are the defect:

• Live media and games. A video frame from 200 ms ago is worthless. Retransmitting it would delay every frame after it. Dropping it is the correct behavior — TCP would forbid it.
• Tiny request-reply exchanges. When the whole conversation is one small question and one small answer, a handshake costs more than simply asking again. DNS runs this way (Part 7).
• Building new transports. Because UDP is thin and passes through nearly all networks, you can build a smarter transport on top of it in ordinary software. QUIC is exactly that (next section).

So: TCP or UDP? The choice is not "reliable vs unreliable" — it is a question about the data's relationship with time. Ask three questions of the workload:

1. Is late data still useful? A database row is as valuable a second late as on time → TCP. A live video frame from 200 ms ago is garbage → UDP.
2. Must the receiver see the bytes complete and in order? File transfer, payments, queues, anything you will store → TCP. Independent small messages where each one stands alone (metrics, position updates, DNS answers) → UDP.
3. How big is the conversation? Long exchanges amortize TCP's handshake to nothing → TCP. One tiny question and answer make the handshake the most expensive part → UDP.

Answer all three and the transport usually names itself. When the answers conflict — you want reliability and fast setup and parallel independent data — neither classic transport wins, and that conflict is precisely the gap QUIC fills.

QUIC — The Modern Transport

Part 4 · Transport, option three

What it is. QUIC is a transport protocol, standardized as RFC 9000 in 2021, that runs on top of UDP and merges the jobs of TCP and TLS into one layer: reliability, multiplexed streams, and encryption together.^[10] It is the transport under HTTP/3 and now carries a large share of web traffic.

How it works. QUIC takes TCP's ideas — connections, acknowledgments, retransmission, congestion control — and rebuilds them with two structural changes:^[10]

1. One handshake, not two. QUIC's connection setup carries the TLS 1.3 handshake inside it (TLS is explained in Part 9). Transport and encryption finish together in one RTT — and for a server the client has spoken to before, 0-RTT lets the first packet already carry the encrypted request.^[10]
2. Independent streams. A QUIC connection holds many streams, and each stream is delivered and retransmitted independently. A lost packet stalls only the stream whose bytes it carried; every other stream keeps flowing. TCP can never do this, because TCP sees one byte stream and cannot know which bytes belong together.^[10][13]

sequenceDiagram
  participant C as Client
  participant S as Server
  Note over C,S: TCP + TLS 1.3 = 2 RTTs before the request
  Note over C,S: QUIC = 1 RTT (0 when resuming)
  C->>S: QUIC Initial (transport + TLS in one flight)
  S->>C: Handshake complete + keys
  C->>S: Encrypted request
          

QUIC adds one more gift for mobile users: connection migration. A TCP connection is identified by the machines' IP addresses, so it dies when a phone moves from Wi-Fi to 5G. A QUIC connection is identified by a connection ID instead, and survives the change.^[10]

What it costs. More CPU than TCP (nearly the whole packet is encrypted), some corporate networks still block UDP and force a fallback, and operators lose familiar TCP-level tooling. Real deployments therefore serve QUIC and keep TCP+TLS behind the same name, and let clients pick.

When to use QUIC. Reach for QUIC when the traffic looks like the modern web:

• User-facing traffic over the public internet — browsers and mobile apps to your edge. Connection setup happens constantly there, so QUIC's saved RTTs are saved on every visit.
• Mobile-heavy users — connection migration keeps sessions alive across Wi-Fi/cellular switches.
• High-latency or lossy paths — long distances make RTTs expensive, and loss makes TCP's HOL blocking bite; QUIC softens both.
• Many resources in parallel — pages and APIs that fetch dozens of things at once benefit most from independent streams.

Stay with TCP+TLS when the traffic looks like a data center: internal service-to-service calls on stable, long-lived connections (the handshake is paid once, then irrelevant), environments where UDP is blocked or throttled, CPU-tight servers, and anywhere your team's operational tooling for TCP is the thing keeping you sane. In practice this is not either/or — the standard pattern is QUIC at the public edge, TCP inside.

HTTP — The Language of the Web

Part 5 · The application layer

What it is. The Hypertext Transfer Protocol (HTTP) is the request-response language that clients and servers speak on top of a transport.^[7] The client asks about a resource — the thing a URL identifies — and the server answers about that resource.

How it works. The format is honest enough to read raw. A request is a method, a path, and headers; a response is a status code, headers, and a body:

GET /notes HTTP/1.1
Host: app.lantern.dev
Accept: text/html

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

<!doctype html> ...

The status code compresses the outcome into three digits, in five families: 2xx success, 3xx redirection, 4xx the client's fault, 5xx the server's fault.^[7]

HTTP has versions, and the differences are transport-level, not semantic. HTTP/1.1 handles requests one at a time per connection. HTTP/2 interleaves many streams over one TCP connection — but one lost packet still stalls all of them, because TCP underneath sees a single byte stream (HOL blocking again).^[12][13] HTTP/3 keeps HTTP's semantics and moves them onto QUIC streams, where that stall disappears.^[11] Same requests, same methods, same status codes — different floor.

What it costs. HTTP itself is cheap; its important "cost" is a discipline: HTTP is stateless. Each request must carry everything the server needs, because the protocol gives the server no memory of previous requests.^[7]

HTTP Methods — Verbs With Contracts

Part 6 · The retry contracts

What they are. Every HTTP request carries a method: the verb stating what the client wants done with the resource. The verbs are simple; the value is in two contracts attached to them.

Method properties as defined by RFC 9110 ^[7][8].

How the contracts work. A method is safe when it changes nothing on the server — so clients may fire it freely, and caches may store its responses.^[7] A method is idempotent when sending it twice leaves the system in the same state as sending it once.^[7] All safe methods are idempotent; the reverse is not true — PUT and DELETE change things, yet repeating them changes nothing further.^[8]

Why retries need the contracts. Networks fail ambiguously. You send a request and no response comes back — was the request lost on the way in, or executed with the response lost on the way back? You cannot know. Your only options are to give up or retry, and retrying is only harmless when the method is idempotent. Retrying a PUT re-applies the same replacement: fine. Retrying a POST /payments may charge the user twice: not fine.

DNS — The Internet's Address Book

Part 7 · Name resolution

What it is. The Domain Name System (DNS) is the global, distributed directory that turns names like app.lantern.dev into IP addresses.^[4] No packet can be sent to a name, so DNS runs before almost every connection on the internet.

How it works. The lookup is a chain of delegation that follows the name's own structure, read right to left. The client asks a recursive resolver — a server, usually run by the ISP or a public service such as 1.1.1.1, that hunts the answer on the client's behalf.^[5][6] The resolver asks a root nameserver (which knows who runs .dev), then the .dev TLD nameserver (which knows who holds lantern.dev), then the authoritative nameserver for the domain, which returns the answer: app.lantern.dev → 203.0.113.10.^[6]

sequenceDiagram
  participant C as Client
  participant R as Recursive resolver
  participant Root as Root NS
  participant TLD as .dev TLD NS
  participant Auth as lantern.dev authoritative NS
  C->>R: app.lantern.dev?
  R->>Root: app.lantern.dev?
  Root-->>R: ask the .dev servers
  R->>TLD: app.lantern.dev?
  TLD-->>R: ask lantern.dev's servers
  R->>Auth: app.lantern.dev?
  Auth-->>R: 203.0.113.10 (TTL 300)
  R-->>C: 203.0.113.10
          

That full walk rarely happens, because DNS runs on caching. Every answer carries a TTL (time to live): how many seconds a resolver may reuse it without asking again.^[5] With a TTL of 300, only the first query in five minutes pays for the walk. One more connective detail: a DNS query is one small question with one small answer, so classic DNS runs over UDP — the "tiny request-reply" workload from Part 3, found at the heart of the internet.^[4]

What it costs. Caching cuts both ways. A long TTL means fast lookups but slow change: move your server to a new IP, and clients keep using the cached old address until the TTL expires.

SSL — The Old Lock

Part 8 · Where transport security came from

What it is. SSL (Secure Sockets Layer) was the first widely deployed protocol for encrypting web traffic, invented at Netscape in the 1990s to make the first online commerce possible. It introduced the ideas the next section still uses: encrypt the connection, and prove the server's identity with a certificate.

What happened to it. SSL's versions were broken by design flaws over the years — SSL 2.0 and 3.0 are formally deprecated and must not be enabled. Stewardship of the protocol passed to the IETF, which fixed and renamed it: the successor is TLS. So the answer to "SSL vs TLS?" is short: the same idea, and only TLS survives.

What remains. The name. The industry still says "SSL certificate", "SSL termination", and "SSL offloading" out of pure habit — every one of those today means TLS. When a load-balancer console offers "SSL settings", it is configuring TLS.

TLS — The Current Lock

Part 9 · Transport security today

What it is. TLS (Transport Layer Security) is the protocol that encrypts and authenticates connections — the successor of SSL, standardized by the IETF. The current version, TLS 1.3, was published as RFC 8446 in 2018.^[9] HTTP carried over TLS is HTTPS: same protocol, locked pipe.

How it works. TLS slides in between the transport and HTTP, and gives the connection three properties:^[9]

• Confidentiality — the bytes are encrypted; machines in the middle see noise.
• Integrity — any tampering in transit is detected.
• Authentication — the server proves its identity with a certificate: a document, signed by a trusted certificate authority (CA), that binds a name like app.lantern.dev to the server's public key. Your browser trusts the CA, the CA vouches for the certificate, and so the browser trusts the server.

Both sides agree on encryption keys in the TLS handshake. The client offers its capabilities and key material; the server answers with its choice, its certificate, and its own key material; both derive the same keys and encrypted traffic begins. TLS 1.2 spent two RTTs on this exchange; TLS 1.3 redesigned it to fit in one:^[9]

sequenceDiagram
  participant C as Client
  participant S as Server
  C->>S: ClientHello (ciphers + key share)
  S->>C: ServerHello + certificate + key share + Finished
  C->>S: Finished + first encrypted request
  Note over C,S: TLS 1.3 — 1 RTT, on top of TCP's 1 RTT
          

What it costs. One RTT of setup on top of TCP's own — so a fresh HTTPS connection pays two round trips before the server hears a single request. That stacking is precisely what QUIC (Part 4) collapses into one. There is also operational cost: certificates expire and must be renewed, which is why automated issuance (Let's Encrypt, ACME) is now standard practice.

Protocols in Action — One Page Load

Part 10 · All nine, one job

Concepts connect best in motion, so here is one concrete job that uses every protocol above. Your product is Lantern, a note-sharing web app whose server runs in Dubai. A user in Tokyo opens her phone and loads https://app.lantern.dev/notes. One RTT on this path is ~180 ms, so every handshake is visible to her.

Walk the load step by step:

1. DNS — the phone asks its recursive resolver for app.lantern.dev. The answer, 203.0.113.10, comes from cache in a few milliseconds; only the first query in each TTL window pays for the full root → TLD → authoritative walk. The query itself rides UDP: one small question, one small answer, no handshake worth paying for.
2. QUIC over UDP over IP — the phone opens a QUIC connection to 203.0.113.10:443. Transport setup and the TLS 1.3 handshake travel together, so after one RTT the connection is reliable, encrypted, and the certificate has proven the server is really Lantern. (On yesterday's phone this was TCP + TLS: two stacked handshakes, two RTTs.)
3. HTTP/3 — the phone sends GET /notes. GET is safe and idempotent, so if the response is lost, the phone retries without fear. The server answers 200 OK with the HTML, then CSS, scripts, and images flow on parallel QUIC streams — a lost packet delays only its own stream, not the page.
4. IP, throughout — every one of those packets was routed hop by hop by address, with no router promising anything. Every guarantee the user experienced was built by the layers above.

sequenceDiagram
  participant U as Phone (Tokyo)
  participant R as DNS resolver
  participant S as Lantern server (Dubai)
  U->>R: app.lantern.dev? (DNS over UDP)
  R-->>U: 203.0.113.10 (cached, ~5 ms)
  U->>S: QUIC handshake (transport + TLS 1.3, 1 RTT)
  S-->>U: keys established, certificate proven
  U->>S: GET /notes (HTTP/3, encrypted)
  S-->>U: 200 OK + HTML, CSS, JS on parallel streams
  Note over U,S: every packet: UDP datagrams routed by IP
          

Then she walks out of Wi-Fi range and her phone switches to 5G. Her IP address changes — which would have killed a TCP connection — but the QUIC connection is identified by its connection ID, so the session survives without a reconnect. The test of this whole guide is one exercise: remove any single layer from the trace and name what breaks. If you can, the stack is yours.

Cheat Sheet and Next Steps

Part 11 · What to carry into the design room

Nine protocols, one line each: IP routes packets by address and promises nothing. TCP buys ordered, reliable streams for one RTT of setup and HOL blocking under loss. UDP buys nothing and costs nothing — right when old data is worthless or exchanges are tiny. QUIC rebuilds TCP+TLS as one layer on UDP: one handshake, independent streams, connection migration. HTTP gives requests meaning and keeps servers stateless. Methods attach retry and cache contracts to every request. DNS resolves names, with TTLs as your failover lever. SSL is the deprecated ancestor whose name survives in menus. TLS is the actual lock: encryption, integrity, and certificate-proven identity for one RTT.

The transport decision, as a table you can defend:

Check yourself against the mission:

• I can explain each protocol in two sentences: the problem it solves and the price it charges.
• Given a workload, I can choose TCP, UDP, or QUIC and defend the choice with RTTs and loss behavior.
• I can trace an HTTPS page load from DNS lookup to rendered response, naming every layer.
• I can say which HTTP methods are safe to retry, why, and how idempotency keys extend retries to POST.
• I know why "SSL certificate" is a habit, not a protocol, and which TLS versions to allow.

Read next, in this order: Cloudflare's Learning Center article on DNS, for the clearest illustrated resolution walkthrough ^[5]; RFC 9110 Section 9 — short, readable, and the primary source on method semantics ^[7]; and RFC 9000's introduction, to see how a modern protocol defines streams and handshakes ^[10].