HTTP & Its Versions
From HTTP/1.1 to HTTP/3 — how the web’s core protocol got faster
HTTP is the protocol your code speaks most. Its rules — methods, status codes, headers — have stayed familiar, but the way it moves bytes has been reinvented three times for speed. Knowing the differences helps you reason about real-world performance.
HTTP = request / response
HTTP is a request/response protocol: the client sends a request, the server returns a response. It is stateless — each request stands alone — which is why cookies and tokens exist to carry identity between requests.
Anatomy of a request
A request has a request line (method + path + version), headers (metadata like Host and Authorization), a blank line, and an optional body. The method states intent:
- GET
- Read a resource.
- POST
- Create / submit data.
- PUT / PATCH
- Update a resource.
- DELETE
- Remove a resource.
Status codes
The response starts with a status code that tells you what happened, grouped by first digit: 2xx success, 3xx redirect, 4xx client error (you sent something wrong), 5xx server error (the server broke). Learning these families makes debugging APIs much faster.
HTTP/1.1
HTTP/1.1 kept connections open (keep-alive) so they could be reused, which was a big improvement. But on a single connection requests are handled one at a time — a slow response blocks the ones behind it (head-of-line blocking). Browsers worked around this by opening several connections at once.
HTTP/2
HTTP/2 introduced multiplexing: many requests and responses share a single connection as independent streams, so they no longer wait in line. It also switched to a compact binary format and compressed headers — big wins for pages that load many resources.
HTTP/3 (QUIC)
HTTP/2 still ran on TCP, where a single lost packet stalls all streams. HTTP/3 fixes this by running on QUIC, a new transport built on UDP. QUIC gives each stream independence (one loss does not block the others) and faster connection setup — including quicker TLS.
The evolution at a glance
The through-line: same HTTP semantics, ever-better transport. 1.0 opened a connection per request; 1.1 reused connections; 2 multiplexed them; 3 moved onto QUIC/UDP to remove TCP’s head-of-line blocking entirely.