Episode 1 — Fundamentals / 1.4 — Understanding HTTP and HTTPS

1.4.a — What is HTTP and Its Different Versions?

In one sentence: HTTP (HyperText Transfer Protocol) is the application-layer language browsers and servers use to exchange web resources; each version changes how efficiently and safely those messages move over the network.

Navigation: ← 1.4 Overview · 1.4.b — HTTP Status Codes →

1. What is HTTP?

HTTP is a stateless, request–response protocol. A client (usually a browser) sends a request; a server returns a response. The server does not inherently remember past requests — state is added with cookies, tokens, sessions, or application design.

PropertyMeaning
Application layerSits above TCP (or QUIC for HTTP/3) — defines what is said, not how bits cross every hop
Text-based (HTTP/1.x)Headers are readable lines like Host: example.com
Resource-orientedURLs identify things (pages, APIs, images)
ExtensibleNew headers and semantics evolve over time (RFC 9110 family today)

Minimal mental model

CLIENT (browser)                         SERVER (origin / CDN)
      │                                           │
      │  HTTP REQUEST                           │
      │  method + path + headers + body?        │
      │  ─────────────────────────────────────►│
      │                                           │
      │  HTTP RESPONSE                          │
      │  status + headers + body (HTML/JSON…)   │
      │  ◄─────────────────────────────────────│

2. Anatomy of an HTTP Message (Quick Refresher)

Request (HTTP/1.1 style)

GET /articles/42 HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 …
Accept: text/html,application/json;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: keep-alive

Response

HTTP/1.1 200 OK
Date: Sat, 11 Apr 2026 12:00:00 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 2048
Cache-Control: max-age=60

<!DOCTYPE html>…

3. HTTP Versions — Timeline and Trade-offs

VersionEraTransportWhat changed (high level)
HTTP/0.91991TCPSingle GET /path line; only GET; response was raw HTML — no headers
HTTP/1.01996TCPFull request/response with headers; often one request per TCP connection
HTTP/1.11997+ (RFC 9110 family)TCPPersistent connections, Host header required, chunked bodies, better caching semantics
HTTP/22015 (RFC 9113)TCPBinary framing, multiplexing many streams on one connection, header compression (HPACK)
HTTP/32022 (RFC 9114)QUIC (UDP)Same HTTP semantics, different transport: faster handshakes, better loss recovery, no TCP HOL blocking

ASCII: evolution of “how many things can fly on one wire?”

HTTP/1.0           HTTP/1.1 (keep-alive)        HTTP/2 (multiplex)        HTTP/3 (QUIC)
──────────         ───────────────────         ─────────────────         ─────────────
[req][close]       [req][resp][req][resp]…       [req1]                    QUIC
                   same TCP socket               [req2]  } one TCP         encrypts
                                               [req3]  } connection        + streams
                                                                         over UDP

4. HTTP/1.1 — Still the “Default Mental Model”

Strengths: simple to debug with curl -v, universal support, great for learning.

Pain points:

  • Head-of-line blocking at HTTP layer — one slow response can delay others on the same connection in practice (mitigated by multiple TCP connections in browsers — costly).
  • Verbose headers repeated on every request (mitigated in practice by compression and connection reuse).

5. HTTP/2 — Multiplexing and Efficiency

Key idea: many requests/responses in parallel on one TCP connection via streams.

Benefits:

  • Fewer TCP connections (better for congestion control and TLS)
  • Header compression (HPACK)

Caveat:

  • TCP-level head-of-line blocking still exists — a lost TCP segment can delay all streams until repaired.

6. HTTP/3 — QUIC Changes the Transport

Key idea: HTTP/3 runs over QUIC (UDP-based) with integrated TLS 1.3 in common stacks.

Why it matters:

  • Faster connection establishment (often fewer round trips than TCP+TLS classic stacks)
  • Stream independence — loss on one stream doesn’t block unrelated streams the same way TCP can
  • Connection migration — moving Wi‑Fi → cellular can be smoother (in supported deployments)

Interview tip: HTTP/3 is still “HTTP” — methods, status codes, headers (mostly) — but framing differs from HTTP/1.1’s plain text.

7. “Which version am I using?”

In Chrome DevTools → Network → click a request → Protocol column often shows h2, http/1.1, or QUIC / h3.

8. Key Takeaways

  1. HTTP defines requests and responses between clients and servers.
  2. It is stateless at the protocol level — sessions are an application pattern.
  3. Versions trade simplicity (1.1) for performance (2) and transport modernization (3).
  4. HTTP/2 multiplexes on TCP; HTTP/3 uses QUIC/UDP to address transport limitations.

Explain-It Challenge

Explain without notes:

  1. What does stateless mean for HTTP, and how do cookies still “remember” you?
  2. One advantage of HTTP/2 over HTTP/1.1 for a page with many small assets.
  3. Why HTTP/3 is not “HTTP over TCP.”

Navigation: ← 1.4 Overview · 1.4.b — HTTP Status Codes →