Why HTTP Evolved: From 0.9 to HTTP/3 and the Design Decisions Behind It

Background and Core Design

HTTP (Hypertext Transfer Protocol) was built on top of TCP because TCP guarantees reliable, ordered delivery of data. The client initiates a request after establishing a TCP connection, making HTTP a client‑driven request‑response protocol.

Length‑Stream vs. Delimiter‑Stream

TCP can split data into multiple segments, so the server must reassemble the fragments. Two common strategies determine when a full request has been received:

Length‑stream : The client first sends the length of the payload; the server reads that length and then reads exactly that many bytes.

Delimiter‑stream : The client terminates the payload with a special delimiter (e.g., \r\n for HTTP).

Length‑stream is simple and memory‑efficient but inflexible for large or variable‑size data. Delimiter‑stream removes the length limitation but requires the server to allocate more memory and can be vulnerable to maliciously long payloads.

HTTP/0.9 – The First Version

The simplest request line looks like: GET /mypage.html\r\n The server parses the path, reads the requested file, and returns its content. To signal the end of the response, the original design closed the TCP connection after sending the file, because the response body could itself contain \r\n.

Adding Headers – HTTP/1.0

Headers (key‑value lines ending with \r\n) were introduced to convey additional metadata such as the protocol version, user‑agent, and host. An example request with headers:

GET /mypage.html HTTP/1.0
Host: taoshu.in
User-Agent: NCSA_Mosaic/2.0 (Windows 3.1)

Responses now start with a status line (e.g., 200 OK) followed by headers and an empty line before the body.

Caching and Conditional Requests

Headers such as Last-Modified and Expires allow clients to cache resources. A conditional request using If-Modified-Since can receive a 304 Not Modified response, avoiding unnecessary data transfer. Later, the Etag header provided a content‑based validator, used with If-None-Match.

Range Requests and Partial Content

Clients can request a byte range with the Range header, receiving a 206 Partial Content response. This enables resumable downloads and parallel download acceleration.

Virtual Hosts and Connection Upgrade

The mandatory Host header lets a single IP serve multiple domains (virtual hosting). HTTP also defines an upgrade mechanism; for example, a request with Upgrade: websocket and Connection: Upgrade can switch the TCP connection to the WebSocket protocol, returning a 101 Switching Protocols response.

HTTP/1.1 – Major Extensions

Key improvements include persistent connections (default keep‑alive), pipelining (later deemed ineffective), chunked transfer encoding, refined caching controls, and additional status codes. Chunked encoding allows the server to stream dynamically generated content without knowing the total length in advance:

HTTP/1.1 200 OK
Transfer-Encoding: chunked

7
Mozilla
9
Developer
0

SPDY and HTTP/2 – Binary Framing

Google’s SPDY introduced binary frames with a length, type, flags, and stream identifier, moving HTTP from a delimiter‑stream to a length‑stream model. HTTP/2 adopted this framing, allowing multiple concurrent streams over a single TCP connection, header compression (HPACK), and server push (later deprecated in favor of 103 Early Hints).

Challenges with HTTP/2

Because browsers typically open only one TCP connection per origin, HTTP/2 can suffer head‑of‑line blocking when packet loss forces retransmission of a single stream, delaying all others. The protocol’s complexity and limited server‑push adoption also reduced its practical benefits.

QUIC and HTTP/3 – UDP‑Based Transport

To eliminate TCP‑induced head‑of‑line blocking, Google designed QUIC, a message‑oriented transport over UDP with its own stream multiplexing. Mapping HTTP/2 frames onto QUIC streams yields HTTP/3 (RFC 9114). QUIC faces deployment hurdles such as UDP throttling by some networks and the need for an initial HTTP/1.1/2 handshake to discover HTTP/3 support via the TLS ALPN extension or DNS SVCB/HTTPS records.

Remaining Open Issues

Text‑based headers are human‑readable but inefficient for machines; header compression mitigates but does not eliminate overhead.

UDP‑based QUIC may be blocked by firewalls or ISP policies.

HTTP/3 startup latency remains a concern because browsers must first determine server support.

Overall, the HTTP protocol’s evolution reflects a continuous effort to improve reliability, performance, and extensibility while preserving backward compatibility.