Introduction to HTTP

Opening a web page looks like one action. In the background, the browser may request an HTML document, fonts, scripts, images, and API data from several hosts. Early HTTP handled that world one short-lived connection at a time. As pages became applications, the protocol had to learn how to reuse connections, interleave work, compress repeated metadata, and recover more gracefully from loss.

HTTP is the application-layer request-and-response protocol behind that exchange. Its meaning—methods, status codes, headers, and resources—has remained recognizable while the way those messages travel has changed substantially.

HTTP/1.0 and HTTP/1.1

HTTP/1.0

Working of http1.0
Click Here For Explanation Of Above Diagram (working of http1)
This diagram shows the usual HTTP/1.0 connection pattern: one request and response per TCP connection. Some implementations later used a non-standard `Keep-Alive` extension, but persistence was not the default behavior standardized by HTTP/1.0.

The key points shown in the diagram are:

  1. A new connection is opened for each request: For each request the client sends (HTTP 1.0), a new TCP connection is established between the client and server.

  2. Server closes the connection after sending the response: After sending the response (HTTP 1.0) to the client’s request, the server immediately closes the connection.

This process repeats for subsequent requests, where a new connection is opened, the request is sent, the response is received, and the connection is closed again.

The default one-request pattern creates extra connection overhead and latency, especially when a page needs many resources.

The introduction of persistent connections in HTTP/1.1 aimed to address this issue by allowing a single TCP connection to be reused for multiple requests and responses, reducing the overhead of opening and closing connections for each request.

HTTP/1.0 was documented in RFC 1945 in 1996 and became the first version to be widely adopted. RFC 1945 was Informational rather than a Standards Track standard. Some key features of HTTP/1.0 include:

  • Simple Request/Response Model: HTTP/1.0 uses a straightforward request/response approach where the client sends a request to the server, and the server sends back the requested data.
  • Stateless Protocol: Each request from a client to a server is treated as an independent transaction that is unrelated to any previous request. This statelessness simplifies the protocol but requires each request to carry all necessary information, leading to inefficiency.
  • Textual Start Lines and Headers: HTTP/1.x start lines and header fields use a textual format, making the protocol relatively easy to inspect. Message bodies can contain arbitrary bytes, including images, compressed files, and video.
  • Limited Persistent Connections: By default, HTTP/1.0 closes the TCP connection after each request/response cycle. This behavior introduces significant overhead due to the cost of setting up and tearing down connections.

HTTP/1.1

Working of http1.1
Click Here For Explanation Of Above Diagram (working of http1.1)

This diagram illustrates how HTTP/1.1 works in terms of connection management between a client and a server.

The key points shown are:

  1. Connection is kept alive after the response: After the server sends the initial response (HTTP 1.1) to the client’s request, the connection is kept alive instead of being closed immediately.

  2. Server keeps the connection open: The server keeps the same connection open and does not close it after sending the response.

  3. Same connection is used for subsequent requests: The client and server can send additional requests/responses over the same established connection, instead of creating a new connection for each request/response cycle.

  4. Either endpoint may decide not to reuse the connection. A Connection: close header signals that the connection will close after the current message.

  5. The connection also ends on timeout, error, or an ordinary TCP close; the client is not the only endpoint allowed to initiate closure.

The main advantage of this approach in HTTP/1.1 is that it allows for persistent connections, where a single TCP connection can be reused for multiple HTTP requests and responses, reducing the overhead of establishing new connections for every request. This improves performance and efficiency compared to the non-persistent connections used in earlier versions of HTTP.

HTTP/1.1, released in 1997, addressed many limitations of HTTP/1.0 and introduced several enhancements:

  • Persistent Connections: One of the most significant improvements in HTTP/1.1 is the use of persistent connections, where a single TCP connection can be reused for multiple requests and responses. This reduces latency and the overhead of establishing multiple connections.
  • Chunked Transfer Encoding: HTTP/1.1 introduced chunked transfer encoding, allowing a server to start sending a response before knowing its total size, which is beneficial for dynamically generated content.
  • More Efficient Caching: HTTP/1.1 includes more sophisticated caching mechanisms, such as the Cache-Control header, which provides fine-grained control over caching policies.
  • Additional Methods and Status Codes: HTTP/1.1 expanded the range of HTTP methods (e.g., OPTIONS, PUT, DELETE) and status codes, providing more tools for developers to handle different types of requests and responses.
  • Host Header: The Host header allows multiple domains to be hosted on a single IP address, a critical feature for the expansion of the web.

HTTP/2: A Major Overhaul

Working of http2
Click Here For Explanation Of Above Diagram (working of http2)

This diagram illustrates HTTP/2’s binary framing and multiplexed streams over a single TCP connection. QUIC belongs to HTTP/3, not HTTP/2.

The key steps shown in the diagram are:

  1. Connection setup:

    • The client sends a Connection Preface to initiate the connection.
    • The client and server exchange Settings Frames to negotiate connection parameters.

  2. Multiplexed streams over a single connection:

    • After the connection is established, the client and server can send data frames belonging to different streams (e.g., Stream 1 and Stream 3) over the same connection.
    • Headers Frames and Data Frames for each stream are interleaved and transmitted between the client and server.

  3. Streams are multiplexed and prioritized:

    • The streams are multiplexed together, allowing for efficient resource utilization and prioritization of streams.

  4. Streams can be canceled:

    • An individual stream (in this case, Stream 1) can be canceled or reset using the RST_STREAM Frame without affecting the entire connection or other streams.

HTTP/2, standardized in 2015, brought significant improvements over HTTP/1.1, addressing performance bottlenecks and inefficiencies. Key features of HTTP/2 include:

  • Binary Protocol: Unlike the text-based HTTP/1.x, HTTP/2 uses a binary framing layer, which is more efficient to parse and less prone to errors.
  • Multiplexing: HTTP/2 interleaves frames from several streams on one connection, removing HTTP/1.1’s application-level response-ordering problem. Because every stream still shares one TCP byte stream, a lost TCP segment can temporarily block them all.
  • Header Compression: HTTP/2 introduces HPACK, a header compression algorithm that reduces the overhead caused by repetitive header data, improving performance.
  • Server Push: The protocol allows a server to offer resources before the client asks for them. In practice it was difficult to use efficiently, and major browsers have disabled or removed support, so it should not be treated as a current optimization strategy.
  • Stream Prioritization: Clients can prioritize streams, allowing more important resources to be delivered first, which enhances the user experience.

HTTP/3: The Next Generation

Working of http3
Click Here For Explanation Of Above Diagram (working of http3)

This diagram illustrates the process of multiplexed streams over a single connection using the QUIC protocol between a client and a server.

The key points shown in the diagram are:

  1. Connection setup using QUIC: The initial handshake packets are exchanged between the client and server to establish a QUIC connection.

  2. Multiplexed streams over a single connection: Once the connection is set up, multiple streams (Stream 1 and Stream 3) can be transmitted over the same connection. Frames from these streams are interleaved and sent back and forth between the client and server.

  3. Streams are multiplexed and prioritized: The different streams are multiplexed together, allowing for prioritization and efficient resource utilization.

  4. Streams can be canceled: As shown by the RESET_STREAM Frame for Stream 1, individual streams can be canceled or reset independently without affecting the entire connection.

HTTP/3 was standardized in RFC 9114 in 2022. It maps HTTP semantics onto IETF QUIC, a secure transport derived from Google’s earlier QUIC work. QUIC is carried in UDP datagrams but implements its own reliable streams, congestion control, and TLS 1.3 handshake.

  • Independent Streams: Loss in one QUIC stream does not block data already available to another stream. Ordering within the affected stream still matters, so “no head-of-line blocking” is not absolute.
  • Improved Security: QUIC integrates TLS 1.3, providing enhanced security and privacy protections.
  • Connection Migration: QUIC supports connection migration, allowing a session to continue seamlessly if the client’s IP address changes, such as when switching from Wi-Fi to mobile data.
  • Potentially Reduced Latency: Connection resumption and independent streams can help on some networks. Zero-RTT is only available for resumed connections and has replay risks, so servers limit what early data may do. HTTP/3 is not automatically faster for every site or network.

The versions are easiest to compare side by side:

FeatureHTTP/1.0HTTP/1.1HTTP/2HTTP/3
First specification1996199720152022
Message formatTextTextBinary framesBinary frames over QUIC
Usual transportTCPTCPTCPQUIC over UDP
Connection reuseNot the default; non-standard keep-alive existedPersistent by defaultOne TCP connection can carry many streamsOne QUIC connection can carry many streams
Header compressionNoneNoneHPACKQPACK
Concurrent responses on one connectionNoPipelining existed but was rarely practicalYes, through multiplexed streamsYes, through multiplexed streams
Effect of packet lossAffects the active TCP transferCan delay queued workTCP loss can pause all HTTP/2 streamsUsually confined to the affected QUIC stream
TLSOptional HTTPS layerOptional HTTPS layerCommonly used with TLS; browsers generally require itTLS 1.3 is integrated into QUIC
Connection migrationNo protocol supportNo protocol supportNo protocol supportSupported through QUIC connection IDs

A New Method: QUERY

HTTP changes do not always arrive as a new numbered version. In June 2026, the IETF published RFC 10008, defining the QUERY method for a safe, idempotent server-side query whose input is carried in the request content.

That fills an awkward gap. GET clearly means retrieval, but a large or structured query may be a poor fit for a URI. POST can carry a body, but its method semantics do not tell a cache or retrying client that the operation is read-only and repeatable. QUERY makes those properties explicit:

QUERY /reports HTTP/1.1
Host: example.org
Content-Type: application/json
Accept: application/json


{"from":"2026-08-01","to":"2026-08-23","groupBy":"region"}

The request needs a Content-Type, and the server decides which query formats a resource accepts. Responses can be cached, but the cache key must include the request content and relevant metadata. The new Accept-Query response field can advertise supported formats.

QUERY is now in the IANA HTTP Method Registry as safe and idempotent. That makes it worth knowing about, but not a drop-in replacement for every existing API. Support in frameworks, gateways, CORS policies, observability tools, and caches is still new, so an application should verify the whole request path and retain a compatible fallback where necessary.

Conclusion

HTTP did not replace its basic request-and-response model as the web grew. It changed how those messages share connections and react to network conditions. HTTP/1.1 made reuse practical, HTTP/2 added framing and multiplexing over TCP, and HTTP/3 moved those streams onto QUIC. Newer is not automatically faster on every path, which is why measurement and graceful version negotiation matter more than the version number alone.