HTTP/1.0 → HTTP/1.1 → HTTP/2 → HTTP/3

Every time you load a website, your browser talks to a server using a set of rules called HTTPHyperText Transfer Protocol — the language browsers and servers speak. When your browser says "GET /index.html," it's speaking HTTP. Every webpage you've ever loaded was delivered via this protocol.. The first version was designed in 1991 by Tim Berners-Lee at CERN — when a "webpage" was one screen of text with a few links. It worked fine for that era. The problem is that a modern web page (like Amazon's homepage) needs 237 separate files — images, scripts, stylesheets, fonts, API calls. Fetching those files one at a time, with a brand-new connection each time, is like ordering 237 packages and having each one delivered by a different truck that drives to the warehouse and back. Each version of HTTP exists because someone measured the waste, identified the bottleneck, and engineered a fix.

Here is what each version actually changed, in plain English. HTTP/1.0 opened a brand-new TCP connectionTransmission Control Protocol connection — a reliable two-way communication channel between your browser and the server. Opening one requires a 3-step handshake (SYN → SYN-ACK → ACK) that takes one full round trip before any data can flow. for every single file — brutally wasteful. HTTP/1.1 fixed that by keeping the connection open (called "keep-alive"), but requests still had to wait in line, one after another. HTTP/2 let multiple requests fly over a single connection at the same time — a technique called multiplexingSending multiple independent streams of data over the same connection simultaneously. Like a highway with many lanes — cars don't have to wait for the car in front to arrive before leaving.. But HTTP/2 still ran on TCP, and when one packet got lost, TCP froze everything until that one packet was retransmitted. HTTP/3 replaced TCP entirely with a new transport called QUICQuick UDP Internet Connections — originally designed by Jim Roskind at Google. Runs on UDP instead of TCP, supports 0-RTT reconnection, and doesn't freeze all streams when one packet is lost. that doesn't have this freezing problem.

Open Chrome DevTools on Amazon's homepage (press F12, click the Network tab, then reload). Watch the waterfall. You will see 237 separate HTTP requests fire off — one for the HTML document, dozens for CSS and JavaScript bundles, over a hundred for product images, font files, tracking pixels, and API calls. The server can generate each response in under 5 milliseconds. But the page still takes 3-4 seconds to fully load. Where is the time going?

The answer is protocol overhead. Before your browser can receive a single byte of a file, it has to open a connection to the server (that is a TCP handshakeThe 3-step process that establishes a reliable connection: your browser sends SYN, the server replies SYN-ACK, your browser sends ACK. This takes one full round-trip time (RTT) — typically 20-100ms depending on distance. — one round trip), then negotiate encryption (that is a TLS handshakeTransport Layer Security handshake — the encryption negotiation between your browser and the server. In TLS 1.2, this adds 2 more round trips. In TLS 1.3, it is reduced to 1 round trip. Without this, your data travels in plaintext. — one or two more round trips), and THEN send the actual request. If every file requires its own connection, the overhead adds up fast.

Let's do the math. Say you are in London and the server is in Virginia (Amazon's us-east-1). The round-trip time is about 80ms. Opening a TCP connection costs 1 RTT (80ms). TLS 1.2 costs 2 more RTTs (160ms). Then the actual request-response is 1 RTT (80ms). That is 320ms just to fetch ONE file. Multiply by 237 files, and you would be waiting 75 seconds if the browser fetched them one at a time.

Of course, browsers don't fetch one file at a time. Chrome opens up to 6 parallel connections per domain. That means it can download 6 files simultaneously — but each of those 6 connections still has to pay the full TCP + TLS setup cost. With 237 files and 6 connections, the browser makes about 40 batches of requests. That is still too slow, and it is why every version of HTTP tried to reduce this per-request overhead.

Open DevTools right now on any website. Click the Protocol column header in the Network tab (you may need to right-click the column header and enable it). You will see h2 (HTTP/2) or h3 (HTTP/3) next to most requests. These newer protocols exist specifically because the math above was unacceptable.

Now let's rewind to the beginning. To understand WHY each version was built, we need to start with the original HTTP — the one Tim Berners-Lee typed into a text editor at CERN in 1991.

The year is 1991. Tim Berners-Lee is at CERNThe European Organization for Nuclear Research in Geneva, Switzerland. Berners-Lee was a software engineer there who invented the World Wide Web, HTML, HTTP, and the first web browser — all to help physicists share research documents. in Geneva, and he has a problem: physicists need to share research papers, but every department uses a different document system. His solution is a linked document system — he calls it the "World Wide Web." He needs a simple way for one computer to ask another computer for a document. So he designs a protocol so simple it fits in a few paragraphs.

Here is what the very first HTTP looked like. You could literally type it by hand using telnetA command-line tool that opens a raw TCP connection to any server and lets you type text directly. Before web browsers existed, this is how people tested HTTP — by typing the requests character by character.:

# This is what the FIRST web request looked like in 1991
# HTTP/0.9 — literally one line

$ telnet info.cern.ch 80
Trying 188.184.21.108...
Connected to info.cern.ch.

GET /hypertext/WWW/TheProject.html
                                        # ← That's it. One line. No headers.

<TITLE>The World Wide Web project</TITLE>
<NEXTID N="55">
<H1>World Wide Web</H1>The WorldWideWeb (W3) is a wide-area
<A NAME=0 HREF="WhatIs.html">hypermedia</A> information retrieval
initiative aiming to give universal access to a large universe of documents...

Connection closed by foreign host.      # ← Server closes connection immediately

That is HTTP/0.9 — the very first version. No headers. No status codes. No content types. Just GET /path and the server sends back HTML and hangs up. It worked beautifully when a "website" was one page of text with a few blue links.

By 1996, the web had grown. People wanted images on pages. They wanted to know if a page existed or not (404 errors). They wanted servers to tell them what kind of file they were sending (is this HTML or a JPEG?). So Berners-Lee, along with Roy Fielding and Henrik Frystyk Nielsen, formalized HTTP/1.0 in RFC 1945. This version added headers, status codes, and content types — the building blocks of the modern web.

# HTTP/1.0 — now with headers!
# You can try this RIGHT NOW:

$ telnet www.example.com 80
GET / HTTP/1.0                          # ← Version declared
Host: www.example.com                   # ← Headers added
User-Agent: Mozilla/1.0                 # ← Identify yourself
Accept: text/html                       # ← Tell server what you want
                                        # ← Blank line = end of request

HTTP/1.0 200 OK                         # ← Status code!
Content-Type: text/html                 # ← "Here's what I'm sending"
Content-Length: 1256                     # ← "Here's how much"
Date: Sun, 06 Nov 1994 08:49:37 GMT    # ← Timestamp

<html><body>Example Domain...</body></html>

Connection closed by foreign host.      # ← Connection DIES after every response

The key improvement: headers let the browser and server negotiate — what format do you want? What encoding do you support? Is the content compressed? This was essential for the multimedia web. But there was a brutal cost hidden in the design.

Every single request paid the full price of opening a TCP connection (1 RTTRound-Trip Time — the time for a packet to travel from your browser to the server and back. From London to Virginia, this is roughly 80ms. From Mumbai to California, roughly 150ms. Pure physics — nothing can beat the speed of light in fiber.), doing the actual request-response (1 RTT), and then tearing the connection down. For a page with 10 images, that is 10 TCP handshakes — 800ms of pure overhead before a single byte of image data is delivered. In 1996, most pages had fewer than 10 resources, so this was tolerable. But the web was about to get much more complex.

HTTP/1.1 fixed the worst sin of 1.0 — it kept connections alive so you didn't pay a fresh TCP handshake for every file. That was a huge win. But as websites grew from 10 resources to 80+, three new bottlenecks emerged. Each one is measurable, each one is mathematical, and each one drove the design of HTTP/2.

Problem 1 — Connection Overhead Still Adds Up

Even with keep-alive, browsers open multiple TCP connections to speed things up. Each connection still pays the full TCP + TLS setup cost. A typical page in 2012 needed about 80 resources. Let's measure the real cost with curlA command-line tool for transferring data with URLs. The -w flag lets you print timing metrics like connection time, TLS handshake time, and total transfer time — invaluable for diagnosing HTTP performance.:

# Measure the REAL cost of a single HTTPS connection
$ curl -w "time_connect: %{time_connect}\ntime_appconnect: %{time_appconnect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" -o /dev/null -s https://www.amazon.com

time_connect:       0.024       # TCP handshake: 24ms
time_appconnect:    0.068       # TLS handshake done: 68ms (44ms for TLS alone)
time_starttransfer: 0.153       # First byte arrived: 153ms
time_total:         0.412       # Everything downloaded: 412ms

# That's 68ms of pure overhead BEFORE any content flows.
# Now multiply: 80 resources ÷ 6 connections = ~14 connection setups
# 14 × 68ms = 952ms wasted on handshakes alone

Run that command yourself — replace the URL with any site you like. The time_connect is your TCP handshake, time_appconnect is TCP + TLS combined. The gap between time_appconnect and time_starttransfer is how long the server took to generate the response. You will almost always find that the handshake overhead dwarfs the server processing time.

Problem 2 — The 6-Connection Limit per Domain

Browsers deliberately limit themselves to 6 simultaneous TCP connections per domain. Why? Because if Chrome opened 80 connections to Amazon, and 10 million users did the same thing at the same time, Amazon's servers would have to juggle 800 million open connections. The server would collapse. So browsers cooperate — they open at most 6 connections and queue the remaining requests.

The math is simple but painful. If you have 80 resources and 6 connections, the browser fetches files in batches of 6. That is 80 ÷ 6 = 14 rounds (rounding up). Each round has to wait for the slowest file in that batch to finish before the next batch can use that connection slot. If one file in a batch takes 200ms (maybe a large image), all other connections in that batch sit idle waiting for the next round.

Developers got creative. Since the 6-connection limit is per domain, they spread their files across multiple subdomains — img1.cdn.com, img2.cdn.com, img3.cdn.com. This hack was called domain shardingA performance hack where you serve resources from multiple subdomains so the browser opens 6 connections to EACH subdomain, multiplying your parallelism. Common from 2008-2015 but actually harmful with HTTP/2, which multiplexes everything on one connection., and it worked — but it was a bandaid on a protocol-level limitation. Each extra domain added a DNS lookup (~20-50ms) and a new TLS handshake. HTTP/2 would make this hack obsolete (and actually harmful — domain sharding with HTTP/2 is worse because it defeats multiplexing).

Problem 3 — Head-of-Line Blocking in Pipelining

HTTP/1.1 had a feature called pipeliningAn HTTP/1.1 feature that lets the browser send multiple requests on one connection without waiting for each response. Sounds great, except the server MUST return responses in the exact same order the requests were sent — and that causes head-of-line blocking. that was supposed to solve the serialization problem. The idea was clever: instead of waiting for a response before sending the next request, the browser could fire off 5 requests in a row on the same connection. The server would process them and send responses back. Sounds perfect, right?

Here's the catch: the HTTP/1.1 spec requires responses to come back in the same order as the requests. If you request style.css, app.js, and hero.jpg in that order, the server MUST send the CSS response first, then the JS, then the image — even if the image was ready first. If the CSS file takes 500ms to generate (maybe it's dynamically compiled), the JS and image sit on the server fully ready but unable to be sent. This is called head-of-line blocking — the first item in the queue blocks everything behind it.

This problem was so bad that no major browser ever enabled pipelining by default. Firefox had it as a hidden flag (network.http.pipelining). Chrome never shipped it. The feature existed in the spec but was dead on arrival because head-of-line blocking made it unreliable. The only real fix was to rethink the entire protocol — which is exactly what happened next.

In 2009, Mike Belshe and Roberto Peon at Google were staring at the same numbers we just calculated. Google's business literally depends on page load speed — they had measured that an extra 500ms of latency costs them 20% of traffic. So Belshe's team built an experimental protocol called SPDYPronounced "speedy." An experimental protocol developed by Google in 2009 that introduced multiplexing, header compression, and server push. It was so successful that it became the foundation for HTTP/2, which was standardized as RFC 7540 in 2015. (pronounced "speedy") that attacked all three bottlenecks at once.

The core idea is beautifully simple. Instead of treating a TCP connection as a single pipe that carries one request at a time, SPDY turned it into a highway with numbered lanes. Each request gets a unique stream IDA number that tags every frame in an HTTP/2 connection. Stream 1 might carry style.css, stream 3 carries app.js, stream 5 carries hero.jpg — all flowing over the same TCP connection simultaneously. Odd numbers are client-initiated, even numbers are server-initiated., and the server can send responses for different streams in any order, interleaved freely. This is called multiplexing — many independent conversations on one connection.

SPDY was so successful that the IETFThe Internet Engineering Task Force — the body that standardizes internet protocols. When they publish an RFC (Request for Comments), it becomes the official specification that every browser and server follows. adopted it as the starting point for HTTP/2. In 2015, HTTP/2 became an official standard (RFC 7540). You can see it in action right now:

# See HTTP/2 in action — the -v flag shows protocol negotiation
$ curl --http2 -v -o /dev/null -s https://www.google.com 2>&1 | head -20

* Connected to www.google.com (142.250.80.4) port 443
* ALPN: server accepted h2                    # ← Server says "yes, I speak HTTP/2"
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://www.google.com/
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [:scheme: https]
> GET / HTTP/2                                 # ← Request sent on stream 1
< HTTP/2 200                                   # ← Response on stream 1
< content-type: text/html; charset=UTF-8

# The key line is "ALPN: server accepted h2"
# ALPN = Application-Layer Protocol Negotiation
# It happens DURING the TLS handshake — zero extra round trips

Notice the line ALPN: server accepted h2. That is the browser and server agreeing to use HTTP/2 during the TLS handshake itself — no extra round trip needed. The protocol negotiation is piggybacked on encryption setup, which is clever engineering. From this point on, every request and response is a numbered stream, and the days of head-of-line blocking at the HTTP layer are over.

Now that you understand why each version was created, let's look at how each one works under the hood. Each card below covers one HTTP version — what it added, what it fixed, and a real command you can run to see it in action.

# Force HTTP/1.1 and watch the connection stay open
$ curl -v --http1.1 -o /dev/null -s https://www.example.com 2>&1 | grep -i "connection\|HTTP/"

> GET / HTTP/1.1                    # ← Using HTTP/1.1
> Host: www.example.com             # ← Host header (virtual hosting!)
> Connection: keep-alive            # ← "Don't close after responding"
< HTTP/1.1 200 OK
< Connection: keep-alive            # ← Server agrees to keep it open
< Transfer-Encoding: chunked        # ← Chunked! Size unknown upfront

# The connection stays open for more requests
# No new TCP handshake needed for the next file

# See HTTP/2 binary framing in action
$ curl --http2 -v -o /dev/null -s https://www.cloudflare.com 2>&1

* ALPN: server accepted h2            # ← Protocol negotiated during TLS
* using HTTP/2
* [HTTP/2] [1] OPENED stream for /    # ← Stream ID 1
* [HTTP/2] [1] [:method: GET]         # ← Pseudo-headers (HTTP/2 uses : prefix)
* [HTTP/2] [1] [:path: /]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: www.cloudflare.com]
> GET / HTTP/2
< HTTP/2 200
< content-encoding: br                # ← Brotli compression (common with H2)
< cf-ray: 8a3f2...                    # ← Cloudflare edge server

# Notice: no "Connection: keep-alive" — HTTP/2 connections are always persistent
# Notice: pseudo-headers use : prefix instead of "Host:" header

# See HTTP/3 (QUIC) in action — requires curl 7.66+ with HTTP/3 support
$ curl --http3 -v -o /dev/null -s https://cloudflare.com 2>&1

* Connecting to cloudflare.com (104.16.132.229)
* QUIC cipher: TLS_AES_256_GCM_SHA384      # ← Encryption built into QUIC
* using HTTP/3                                # ← Running over UDP, not TCP
* h3 [:method: GET]
* h3 [:path: /]
* h3 [:scheme: https]
> GET / HTTP/3
< HTTP/3 301                                  # ← HTTP/3 response!
< alt-svc: h3=":443"; ma=86400               # ← "I support HTTP/3 for 24 hours"

# Notice: no TCP handshake at all
# QUIC combines crypto + transport in a single handshake
# "alt-svc" header tells browsers "you can upgrade to h3 next time"

The previous sections covered what each version does. This section covers how it does it — the wire-level details that come up in senior-level system design interviews. Each topic below is a common follow-up question after you explain the HTTP versions.

# Server response with push hints
HTTP/2 200
content-type: text/html
link: </style.css>; rel=preload; as=style    # ← "Push this too"
link: </app.js>; rel=preload; as=script       # ← "And this"

# The server sends style.css and app.js BEFORE the browser asks
# Saves 1 full RTT per pushed resource

# Step 1: Server sends 103 immediately (while still computing the page)
HTTP/2 103 Early Hints
link: </style.css>; rel=preload; as=style
link: </app.js>; rel=preload; as=script

# Step 2: Browser starts fetching style.css and app.js immediately
# (respecting cache — if already cached, no fetch needed!)

# Step 3: Server finishes computing and sends the real response
HTTP/2 200 OK
content-type: text/html
...

# Result: same time savings, but cache-aware and simpler

HTTP is a request-response protocol — the client asks, the server answers. But many real-world applications need different communication patterns: continuous streams of data, real-time bidirectional chat, or compact binary serialization for microservice-to-microservice calls. Three protocols extend or replace HTTP for these use cases. Understanding when to use which is a staple of system design interviews.

# grpcurl is like curl but for gRPC services
# List available services
$ grpcurl -plaintext localhost:50051 list
greet.GreetService
health.HealthService

# Call a unary RPC
$ grpcurl -plaintext -d '{"name": "Alice"}' localhost:50051 greet.GreetService/SayHello
{
  "message": "Hello, Alice!"
}

# Server streaming — watch prices flow in real time
$ grpcurl -plaintext -d '{"symbol": "GOOGL"}' localhost:50051 stock.StockService/StreamPrices
{"price": 141.23, "timestamp": "2024-01-15T10:00:01Z"}
{"price": 141.45, "timestamp": "2024-01-15T10:00:02Z"}
{"price": 141.38, "timestamp": "2024-01-15T10:00:03Z"}
... (keeps streaming until cancelled)

# wscat is a command-line WebSocket client
$ npm install -g wscat

# Connect to a WebSocket echo server
$ wscat -c wss://echo.websocket.org
Connected (press CTRL+C to quit)

> Hello, WebSocket!
< Hello, WebSocket!          # ← Server echoes back instantly

> {"action": "subscribe", "channel": "stocks"}
< {"status": "subscribed", "channel": "stocks"}
< {"price": 141.23}          # ← Server pushes data WITHOUT a request
< {"price": 141.45}          # ← And again...

# The connection stays open — server can send anytime
# No polling, no long-polling, no hacks

# -N disables buffering so events appear in real time
$ curl -N https://example.com/events

# SSE format — simple text, human-readable
event: score-update
data: {"match": "Arsenal vs Chelsea", "score": "2-1"}

event: score-update
data: {"match": "Arsenal vs Chelsea", "score": "2-2"}

event: notification
data: {"text": "Half-time: Arsenal 2-2 Chelsea"}

# Events keep flowing until connection closes
# If the connection drops, the browser reconnects automatically
# with a Last-Event-ID header so the server can resume from where it left off

Protocol specs are written in conference rooms, but they prove themselves in production. Four companies pushed HTTP forward by shipping real code to billions of users — and the data they collected shaped the standards we use today. These aren't academic case studies; they're the reason your browser speaks HTTP/2 and HTTP/3 right now.

Every time a new protocol version ships, a wave of blog posts and conference talks oversimplify the story. "Just upgrade and everything is faster!" "HTTP/3 is always better!" These half-truths sound reasonable, but they lead to bad decisions in production. Here are three claims that experienced engineers hear all the time — and why they fall apart when you measure.

# Compare HTTP/1.1 vs HTTP/2 for the same resource
curl -w "HTTP/1.1: %{time_total}s\n" --http1.1 -so /dev/null https://example.com
curl -w "HTTP/2:   %{time_total}s\n" --http2   -so /dev/null https://example.com

Alt-Svc: h3=":443"; ma=86400

These aren't hypothetical — they're the mistakes that show up in post-mortems, Hacker News threads, and 3 AM Slack messages. Every one of them has a simple fix, but you have to know they exist first. If you're running a web server or building APIs, scan this list and check whether any apply to you right now.

# nginx.conf — add 'http2' to the listen directive
server {
    listen 443 ssl http2;
    ssl_certificate     /path/to/cert.pem;
    ssl_certificate_key /path/to/key.pem;
}

# httpd.conf — enable the http2 module
LoadModule http2_module modules/mod_http2.so
Protocols h2 http/1.1

# Request with Brotli support, check response encoding
curl -sI -H "Accept-Encoding: br, gzip" https://yoursite.com | grep -i content-encoding
# Should show: content-encoding: br

# Measure TTFB for any URL
curl -w "DNS: %{time_namelookup}s | TCP: %{time_connect}s | TLS: %{time_appconnect}s | TTFB: %{time_starttransfer}s | Total: %{time_total}s\n" -so /dev/null https://yoursite.com

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </app.js>; rel=preload; as=script

HTTP/1.1 200 OK
Content-Type: text/html
...actual page content...

This question shows up in system design rounds, backend interviews, and even frontend interviews. The interviewer isn't looking for a memorized spec — they want to see that you understand why each version exists, what problem it solved, and what trade-offs it introduced. Your answer depth should match the role level. Here's a cheat sheet for each level:

Reading about HTTP versions is one thing. Actually seeing the differences with your own eyes is what makes the knowledge stick. These exercises go from "open a browser tab" to "capture raw protocol frames." Pick the level that matches your experience and work your way up.

# HTTP/1.1
curl -w "HTTP/1.1 → DNS: %{time_namelookup} | Connect: %{time_connect} | TTFB: %{time_starttransfer} | Total: %{time_total}\n" --http1.1 -so /dev/null https://www.cloudflare.com

# HTTP/2
curl -w "HTTP/2   → DNS: %{time_namelookup} | Connect: %{time_connect} | TTFB: %{time_starttransfer} | Total: %{time_total}\n" --http2 -so /dev/null https://www.cloudflare.com

worker_processes 1;
events { worker_connections 128; }

http {
    server {
        listen 443 ssl http2;
        server_name localhost;

        ssl_certificate     /path/to/cert.pem;
        ssl_certificate_key /path/to/key.pem;

        root /var/www/html;
        index index.html;
    }
}

# Linux/Mac: Set the TLS key log file before launching Chrome
export SSLKEYLOGFILE=~/tls-keys.log
google-chrome &

# Windows (PowerShell): Set environment variable
$env:SSLKEYLOGFILE = "$HOME\tls-keys.log"
Start-Process chrome

Six cards. Everything you need when you're configuring a server, debugging a slow page, or answering an interview question. All real data, all real commands.

HTTP/1.0  1 req per connection
HTTP/1.1  persistent, pipelining
          (6 conn per domain)
HTTP/2    binary, multiplexed
          HPACK, server push (dead)
HTTP/3    QUIC (UDP), 0-RTT
          per-stream loss recovery

HTTP/1.1 page load (100 files):
  6 conn × ~17 files each
  = 17 serial round trips
  = 17 × RTT overhead

HTTP/2 page load (100 files):
  1 conn × 100 streams
  = 1 round trip (parallel)
  = massive RTT savings

TCP only:       1 RTT
TCP + TLS 1.2:  3 RTT
TCP + TLS 1.3:  2 RTT
QUIC (new):     1 RTT (TLS built in)
QUIC (resume):  0 RTT

curl --http1.1 -I URL  # force v1.1
curl --http2 -I URL    # force v2
curl --http3 -I URL    # force v3

# Timing breakdown:
curl -w "TTFB: %{time_starttransfer}
Total: %{time_total}" -so /dev/null URL

# Check compression:
curl -sI -H "Accept-Encoding: br"

Nginx:
  listen 443 ssl http2;

Apache:
  Protocols h2 http/1.1

Node.js:
  http2.createSecureServer()

Caddy:
  HTTP/2 + H3 automatic

Alt-Svc: h3=":443"; ma=86400
  → tells browser H3 is available

Content-Encoding: br
  → Brotli compression (best)

Cache-Control: max-age=31536000
  → 1 year cache (use with hashes)

103 Early Hints
  → preload before HTML is ready

HTTP doesn't exist in isolation — it's one layer in a stack. Understanding TCP/UDP explains why QUIC exists. Understanding DNS explains the first step before any HTTP request. Understanding load balancers explains what happens at scale. Pick the topic that fills the biggest gap in your knowledge.