HTTP

The Hypertext Transfer Protocol: stateless requests and responses (a method, a target, header fields, a status code), with one set of semantics carried by three wire versions, HTTP/1.1, HTTP/2 and HTTP/3.

What it is: Network protocols (web protocols)
Type: Open source
Made by: IETF
License: Open standard (IETF RFC)
Facts checked: 8 October 2026

What it is

A client sends a request: a method such as GET, POST, PUT or DELETE, a target such as /orders/4812, header fields and an optional body. The server answers with a three-digit status code (2xx success, 3xx redirection, 4xx client error, 5xx server error), header fields and usually content. HTTP is stateless: each message can be understood on its own, whichever connection it came on, which is what lets proxies reuse connections, caches store responses and load balancers send each request to a different server. Methods carry promises that intermediaries rely on: GET and HEAD are safe, and PUT and DELETE are idempotent, so a request can be retried after a dropped connection. Since 2022 these semantics live in one document, RFC 9110, separate from any wire format; an http URL defaults to TCP port 80.

Three versions put those semantics on the wire. HTTP/1.1 (RFC 9112) sends text messages over a persistent TCP connection, one response at a time, so clients open several connections to send requests in parallel. HTTP/2 (RFC 9113) frames messages in binary, interleaves many on one TCP connection and compresses header fields with HPACK, but a single lost TCP packet still stalls every stream. HTTP/3 (RFC 9114) maps the same semantics onto QUIC streams over UDP, with QPACK for fields, so a loss stalls only the request it hit. None of them has replaced the others: clients pick one per connection, HTTP/2 and HTTP/3 through TLS negotiation (h2, h3) and an Alt-Svc header that advertises HTTP/3. HTTP inside TLS is HTTPS.

Why teams pick it

Spoken by browsers, proxies, CDNs, load balancers and API gateways alike, so a service can be called with nothing more than curl
Stateless messages with safe and idempotent methods let intermediaries cache, retry and load-balance without knowing the application
The same semantics on three transports: move from HTTP/1.1 to HTTP/2 or HTTP/3 without changing a single URL, method or status code
HTTP/2 and HTTP/3 multiplex many requests on one connection and compress repetitive headers

Watch out for

Plain http is unencrypted and unauthenticated: anyone on the path can read and change requests, so real traffic belongs on HTTPS
HTTP/1.1 has no multiplexing: one slow response blocks the requests behind it on that connection, and pipelining never fixed this because responses must stay in order
HTTP/2 still runs over one TCP connection, so a lost or reordered packet stalls every request in flight
Cleartext HTTP/2 needs prior knowledge that the server supports it (the h2c upgrade is deprecated), and HTTP/3 can’t serve http URLs directly, only through Alt-Svc

The HTTP family

1 technologies built from or on HTTP

Built on it

HTTPSOpen sourceHTTP inside TLS: the same requests and responses, sent only after the client has checked the server’s certificate, and encrypted and integrity-protected all the way, on port 443 by default.

How it fits with other technologies

What HTTP uses

An HTTP/1.1 request and its response, as they appear on the wire · http

GET /orders/4812 HTTP/1.1
Host: api.shop.example
Accept: application/json

HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 40

{"id":4812,"status":"shipped","items":2}

Three versions, one set of semantics#

Version	Runs over	Message format	Requests per connection	Header compression	How a client picks it	Specification
HTTP/1.1	TCP, or TLS over TCP	Text lines	One response at a time (pipelining keeps them in order)	None	Default	RFC 9112 (2022); first RFC 2068 (1997)
HTTP/2	TLS over TCP in practice	Binary frames	Many, interleaved on one connection	HPACK	`h2` in TLS ALPN	RFC 9113 (2022); first RFC 7540 (2015)
HTTP/3	QUIC over UDP	Binary frames on QUIC streams	Many, each on its own QUIC stream	QPACK	`h3` in ALPN, advertised by `Alt-Svc`	RFC 9114 (2022)

All three use the methods, status codes and header fields of RFC 9110.

See it in a real stack

No architecture uses HTTP yet. Drop it into the playground and wire it up yourself.Open playground →

Where it came from1991–2022

Tim Berners-Lee introduced HTTP with the World Wide Web in 1990. The version his 1991 prototype implemented, later called HTTP/0.9, was a single line: the client opened a TCP connection to port 80, sent GET and a document address, and the server sent back HTML and closed the connection. Errors were just HTML text; there were no headers or status codes. As the web grew, HTTP gained messages with headers, MIME-style media types and support for intermediaries, documented as HTTP/1.0 in RFC 1945 (May 1996). HTTP/1.1, introduced in 1995 and published in January 1997 as RFC 2068, added chunked transfer, content negotiation, conditional requests, cache controls, range requests and persistent connections by default. It was revised in 1999 (RFC 2616) and again in 2014 (RFCs 7230 to 7235).

In 2009 Google announced SPDY, an experimental protocol that multiplexed streams, prioritised requests and compressed headers; in lab tests pages loaded up to 55% faster. SPDY became the foundation of HTTP/2 (RFC 7540, May 2015). Google’s QUIC work then led to HTTP/3. In June 2022 the IETF reorganised the whole family: RFC 9110 holds the semantics shared by every version, and RFC 9112, RFC 9113 and RFC 9114 define HTTP/1.1, HTTP/2 and HTTP/3 on the wire.

Why it’s built this way

Stateless messages: Each request can be understood in isolation, so servers keep no per-client state between requests and any proxy, cache or load balancer can sit in the path.
Text first, binary later: Early HTTP used telnet-style text lines over TCP, which kept every exchange human readable. HTTP/2 moved to binary frames because whitespace-delimited text leads to parsing complexity and can’t multiplex.
Separate semantics from the wire format: Splitting RFC 9110 from the version documents lets HTTP/1.1, HTTP/2 and HTTP/3 evolve independently while every method, status code and header field means the same thing in all of them.

Timeline

1991
Tim Berners-Lee documents the original HTTP, later called HTTP/0.9
1996
HTTP/1.0 documented as RFC 1945
1997
HTTP/1.1 published on the Standards Track as RFC 2068
2009
Google announces SPDY
2015
HTTP/2 published as RFC 7540
2022
RFC 9110 to RFC 9114: shared semantics, plus HTTP/1.1, HTTP/2 and HTTP/3

Sources5 · facts checked 8 October 2026

Improve this page on GitHub