Why HTTP Was Designed That Way: From TCP Basics to HTTP/3 Evolution

HTTP (Hypertext Transfer Protocol) is a TCP‑based request‑response protocol designed to ensure reliable data transmission. The client initiates a request after establishing a TCP connection, and the server replies with the requested resource.

Because TCP may split data into multiple segments, the server must reassemble the fragments before it can interpret the full request. Two common framing strategies are used: length‑prefixed streams and delimiter‑based streams.

Length‑prefixed streams send the data length first, allowing the receiver to know exactly how many bytes to read. This method is simple and memory‑efficient but limits the maximum transferable size and makes extensibility harder.

Delimiter‑based streams use a special separator (the HTTP line break "\r\n") to mark the end of a message. This approach supports arbitrary message lengths but requires the server to allocate larger buffers and can be vulnerable to resource‑exhaustion attacks. The original HTTP request line looks like: GET /mypage.html\r\n After the client sends this line, the server parses the path, locates the file, and returns the content. Early HTTP (HTTP/0.9) relied on closing the TCP connection to signal the end of the response.

HTTP/0.9 was later extended with version information, header fields, and status codes, forming HTTP/1.0. Common extensions include:

Version information (e.g., HTTP/1.0)

Header fields (e.g., User-Agent)

Status line (e.g., 200 OK)

Typical HTTP/1.0 request with headers:

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

Responses include a status line, headers, a blank line, then the body. Example:

200 OK
Date: Tue, 15 Nov 1994 08:12:32 GMT
Server: CERN/3.0 libwww/2.17
Content-Type: image/gif

(image content)

Key header fields introduced later are Content‑Type, Content‑Length, and Content‑Encoding, which describe the media type, size, and compression of the payload.

When clients need to upload data (POST) or when the response size is unknown, the Content‑Length header becomes essential. It also enables connection reuse (keep‑alive) and conditional requests (If‑Modified‑Since, resulting in 304 Not Modified).

Cache control evolved with headers such as Last‑Modified, Expires, and later ETag, allowing browsers to validate cached resources efficiently.

Range requests (Content‑Range) enable partial downloads and resumable transfers, improving performance for large files.

HTTP/1.1, standardized in RFC 2068, added persistent connections by default, pipelining (later deemed ineffective), chunked transfer encoding, refined caching, content negotiation, and virtual hosting via the Host header.

Chunked encoding allows the server to stream dynamically generated content without knowing the total length in advance:

HTTP/1.1 200 OK
Content-Type: text/plain
Transfer-Encoding: chunked

7
Mozilla
9
Developer
7
Network
0

Connection upgrade introduced the ability to switch protocols on an existing TCP connection, most notably to WebSocket:

GET /chat HTTP/1.1
Host: taoshu.in
Upgrade: websocket
Connection: Upgrade

Google later created SPDY (the basis for HTTP/2) to address HTTP/1.x limitations: binary framing, header compression, and true multiplexing over a single TCP connection.

HTTP/2 (RFC 7540) uses binary frames, stream identifiers, and HPACK header compression, but still suffers from TCP head‑of‑line blocking.

To overcome that, QUIC was designed on top of UDP, providing independent streams, reduced latency, and built‑in encryption. Mapping HTTP/2 semantics onto QUIC yields HTTP/3 (RFC 9114).

HTTP/3 deployment relies on TLS ALPN negotiation (e.g., Alt‑Svc: h3=":4430"; ma=3600) or DNS SVCB/HTTPS records to advertise UDP support before the first request.

Overall, the HTTP protocol has continuously evolved from a simple text‑based request‑response model to a highly optimized, multiplexed, and secure family of protocols that underpin the modern web.