Cookie preferences

Essential cookies keep this site working. Optional Google Analytics cookies help us understand page visits and improve the site. You can change your choice anytime. Cookie policy

Skip to content
ForCSGuy System Design Atlas home

Library / Documentation

RFC 9000: QUIC

The standard for QUIC, the UDP-based transport under HTTP/3.

AdvancedHTTP and QUIC

By IETF · IETF · Added 2026-10-12

Open the docs

All content belongs to IETF. We only link to it and give credit. Report a problem

Learn this doc

About 30 min left. Your work is saved as you go.

What you want from these docs

IETF documents a tool you may use. Decide what you want to do with it, then read only what answers that.

Ideas you will meet

HTTP and QUIC
HTTP versions, QUIC, caching headers and web performance.

What we already know about this

Our own lessons on these ideas. Read them here before you start, so it makes sense.

  • Core Concepts: How Things Actually Work · 7 minHTTP/1.1, HTTP/2 and HTTP/3What changed between HTTP versions and why it makes pages faster.Read here

    HTTP/1.1

    • One request at a time per connection (responses come back in order).
    • To fetch many resources, browsers open about six connections per host.
    • Each request repeats large text headers.
    • A slow response blocks those behind it: head-of-line blocking.
    • Keep-alive lets a connection be reused, saving handshakes.

    HTTP/2

    • Multiplexing: many requests and responses share one connection at the same time, interleaved as separate streams.
    • Header compression removes the repeated cost.
    • Binary framing is more efficient to parse than text.
    • Server push existed but is rarely used and is being phased out.
    • Still runs over TCP, so if one packet is lost, TCP holds back all streams until it is resent (head-of-line blocking at the transport layer).

    Before: HTTP/1.1: many connections

    After: HTTP/2: one shared connection

    What changed

    • One connection carries many requests at once
    • Headers are compressed
    • Old tricks like domain sharding stop helping

    HTTP/3

    • Runs over QUIC, built on UDP, with encryption (TLS 1.3) included.
    • Independent streams: a lost packet only delays its own stream.
    • Faster connection setup: fewer round trips, and resuming a previous connection can send data immediately.
    • Connection migration: a phone moving from Wi-Fi to mobile data can keep the connection, because it is identified by an ID, not an IP address.

    Figure SDA-CORE-04-1 · HTTP/3 · © forcsguy.com

    Figure SDA-CORE-04-2 · What one lost packet does in each version · © forcsguy.com

    What this means for you

    • Use HTTPS everywhere. Browsers only use HTTP/2 and 3 over TLS.
    • Serve through a CDN or server that supports HTTP/2 and 3; clients negotiate automatically and fall back if needed.
    • Do not over-optimise for HTTP/1.1 any more. Keep requests cacheable and compressed.

    More on this site

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

  • Core Concepts: How Things Actually Work · 8 minHow HTTPS worksCertificates, key exchange and encryption in plain language: what the padlock actually proves.Read here

    What it provides

    HTTPS is HTTP inside TLS. TLS gives three things:

    1. Confidentiality: outsiders cannot read the traffic.
    2. Integrity: tampering is detected.
    3. Authentication: you are talking to the real owner of the domain.

    The handshake, simplified

    Figure SDA-CORE-05-1 · The handshake, simplified · © forcsguy.com

    1. The browser says which versions and ciphers it supports.
    2. The server answers with a certificate containing its public key.
    3. The browser checks the certificate: signed by a trusted authority, matches the domain, not expired, not revoked.
    4. They run a key exchange (modern TLS uses ephemeral Diffie-Hellman) to agree on a secret that never crosses the network.
    5. From that secret both sides derive symmetric session keys and encrypt everything after.

    TLS 1.3 shortens this to one round trip, and can resume with none.

    Figure SDA-CORE-05-2 · The order of a secure page load · © forcsguy.com

    Padlocks: the browser padlock symbol means the connection is encrypted and the site's identity was checkedImage: Mx. Granger · CC0 · Source · Wikimedia Commons: Three padlocks

    Certificates and trust

    A certificate says "this public key belongs to example.com", signed by a certificate authority. Your browser and operating system ship with a list of trusted CAs. A server presents a chain (its certificate, plus intermediates) that leads to one of them.

    Free automated certificates (for example from Let's Encrypt) made HTTPS the default. Certificates expire, so renew automatically and monitor expiry: an expired certificate is a common cause of outages.

    A useful detail: asymmetric operations are one-way in practice. Anyone can encrypt or verify with the public key, but only the private-key holder can decrypt or sign. That asymmetry is what lets strangers agree on a secret over an open network, and why the session then switches to a much faster shared symmetric key.

    Forward secrecy

    With ephemeral key exchange, each session uses fresh keys. If the server's long-term key is stolen later, old recorded traffic still cannot be decrypted.

    What HTTPS does not do

    • It does not make a site trustworthy: phishing sites use HTTPS too.
    • It does not hide which site you visit from the network (the domain is visible in DNS and sometimes in the handshake).
    • It does not protect data once it reaches the server: you still need good storage security.

    Practical checklist

    • Redirect HTTP to HTTPS and send an HSTS header so browsers refuse plain HTTP.
    • Use TLS 1.2 or 1.3 only; disable old protocols.
    • Mark cookies Secure and HttpOnly.
    • Automate certificate renewal and alert before expiry.

    Real-world reading

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

  • Real-World Systems · 10 minHow a browser turns a URL into a pageFrom the address bar to pixels: navigation, parsing, the render pipeline, JavaScript, and what makes pages fast or slow.Read here

    From address bar to HTML

    When you press Enter on https://example.com/page:

    1. The browser decides if it is a URL or a search, and checks its caches (HTTP cache, service worker).
    2. DNS turns the name into an IP address; a TCP connection and TLS handshake follow (with HTTP/3, QUIC does both at once). See the networking lessons.
    3. It sends an HTTP request and receives the HTML response, streaming in as it arrives.

    A multi-process program

    Modern browsers run as several processes for speed and safety:

    • a browser process (address bar, tabs, navigation),
    • a renderer process per site or tab (parsing, JavaScript, layout, painting),
    • a network process, and a GPU process for drawing.

    A crashing or malicious page is isolated in its own renderer and cannot read other sites' data.

    The rendering pipeline

    Figure SDA-RWS-11-1 · Browser rendering pipeline · © forcsguy.com

    1. Parse HTML into the DOM (a tree of elements). Parsing is incremental: the browser starts working before the whole file arrives.
    2. Parse CSS into the CSSOM. Rendering waits for CSS, because showing unstyled content then restyling would flash. CSS is render-blocking.
    3. Combine into the render tree (only visible elements, with computed styles).
    4. Layout works out the size and position of every box.
    5. Paint draws the boxes into layers.
    6. Composite: the GPU assembles layers into the final image. Animating a layer's transform or opacity only needs this last step.

    JavaScript on the main thread

    • JavaScript runs on the renderer's main thread, one task at a time in an event loop, alongside parsing, layout and input handling. A long script blocks everything, and the page feels frozen.
    • A normal <script> is parser-blocking: parsing stops until it downloads and runs. Use defer (run after parsing, in order) or async (run as soon as available) for scripts not needed to build the first view.
    • Changing the DOM or styles can trigger reflow (layout again) and repaint. Reading layout values in a loop right after writing styles forces repeated layout (layout thrashing): batch reads and writes.

    What makes pages fast

    GoalTechniques
    Less to downloadCompression (brotli, gzip), image optimisation and modern formats, remove unused JavaScript
    Fewer round tripsCDN, HTTP/2 and 3, preconnect, caching with long lifetimes and versioned names
    Less blockingInline critical CSS, defer scripts, avoid huge CSS and fonts blocking text
    Smooth interactionBreak up long tasks, move heavy work to web workers, animate with transform and opacity
    Load only what is visibleLazy-load images and routes

    Browsers also cache, preload likely navigations, and can run offline logic with service workers.

    Measuring

    Use the Core Web Vitals: LCP (when the main content appears), INP (responsiveness to input) and CLS (unexpected layout shifts). Check both lab tests and real-user data, because real devices and networks are slower and more varied than a developer laptop.

    Real-world reading

    Related reading

    Show 6 more

    Open this lesson with its quiz and exercise

Continue to IETF

Go deeper on this

A path through videos, articles, other case studies and code on the same ideas as RFC 9000: QUIC.

  1. Warm upGet the vocabulary first.

  2. WatchHow others solve the same problem, on video.

    Videos belong to their creators and play from YouTube. More on YouTube (opens in a new tab)

  3. ReadEngineers explain it in their own words.

Keep learning

Loading community…