From SPDY to HTTP/2: How Web Transport Was Reframed

HTTP/2 was an important redesign of how HTTP messages travel, not a replacement for the meaning of HTTP requests and responses. Its history runs through Google’s experimental SPDY protocol, an Internet Engineering Task Force standardization effort, and later revisions that clarified the protocol after real implementations exposed rough edges. The central idea was to use one connection more efficiently by framing concurrent streams, compressing repeated headers, and separating message semantics from the bytes carried on the network.

That history is often summarized as “HTTP/2 made websites faster.” A more accurate account is that HTTP/2 changed a set of transport-level constraints that had shaped browser behavior, while leaving performance dependent on networks, servers, clients, and workloads. Multiplexing reduced some application-layer serialization, but it did not remove TCP’s transport-level behavior or make every request instantly independent.

Why HTTP/1.1 left room for a new transport mapping

HTTP/1.1 standardized persistent connections and mechanisms for sending multiple requests, but web pages grew into collections of documents, style sheets, scripts, images, and other resources. A client wanted to fetch several resources efficiently. In practice, browsers opened multiple connections, while HTTP pipelining could put requests in a queue but still had ordering and deployment limitations. These patterns added connection overhead and constrained how requests could overlap.

Google’s SPDY whitepaper framed the problem in terms of latency and described a proposal at the application layer. It aimed to allow concurrent requests over one TCP connection, prioritize work, compress repeated headers, and provide server-initiated streams. Crucially, SPDY tried to preserve familiar HTTP methods and header semantics while changing framing and connection behavior beneath them. Web application logic did not need to become a wholly new protocol simply because the wire representation changed.

SPDY was an experiment, not an IETF standard. Its project documentation identifies it as a latency-reduction protocol and later marks it deprecated in favor of HTTP/2. That distinction matters: a working browser and server prototype can demonstrate an approach, but cross-vendor interoperability requires a specification, review, and implementation agreement beyond one company’s deployment.

From a Chromium experiment to an open standards process

The Chromium project published the SPDY design and prototype details, including its framing layer and goals. Google later described SPDY as the foundation for HTTP/2 and noted that the standards work was taking place in the IETF. The path was not a simple rename. Protocol work had to translate experimental features into reviewed requirements, settle wire formats, define error handling, and account for participants implementing clients, servers, proxies, and tools.

The IETF published RFC 7540, “Hypertext Transfer Protocol Version 2 (HTTP/2),” in May 2015 as a Standards Track specification. Its authors and acknowledgments include people who had contributed to SPDY, but the RFC is the relevant source for HTTP/2’s normative behavior. The distinction between the predecessor experiment and the standard helps readers track which behavior belongs to which revision rather than assuming every SPDY detail survived unchanged.

Frames and streams separate wire format from HTTP meaning

HTTP/2 carries frames over a connection. A stream is an independently identified sequence of frames within that connection; a request and its response use a stream, and frames from multiple streams can be interleaved. HEADERS frames carry fields, while DATA frames carry message content. Connection-level and stream-level state let implementations manage concurrent exchanges and flow control without requiring one TCP connection per resource.

One TCP connection
  stream 1: HEADERS -> DATA -> DATA
  stream 3: HEADERS -> DATA
  stream 5: HEADERS -> DATA -> DATA

This is a conceptual frame sequence, not an exact trace. The interleaving describes HTTP/2’s application-layer framing; TCP still presents an ordered byte stream underneath. If a TCP segment is lost, later bytes on that same connection may wait for retransmission before the receiver can deliver them. Multiplexing addresses the HTTP request queue’s serialization problem, but it does not abolish transport-level head-of-line blocking.

Because semantics remain HTTP, applications still reason about methods, status codes, fields, and message content. The frame layer gives implementations a binary structure that can carry these elements and schedule concurrent streams. This boundary is a central design choice: browsers and servers can change transport machinery without asking every site author to redesign the meaning of a GET or a response status.

HPACK addressed repeated header cost

Many page loads make repeated requests to the same origin, sending common fields such as authority, accepted content types, and user-agent information again and again. SPDY experimented with header compression; HTTP/2 standardized HPACK in a separate RFC. HPACK defines a static table of common field values, a dynamic table maintained across a connection, and a compact representation for field names and values. It also defines a Huffman encoding for string representations.

Separating HPACK into RFC 7541 made the compression format independently precise while HTTP/2’s main RFC defined how header blocks traveled in frames. The design reflects a protocol lesson: compression behavior, connection state, and framing rules must agree precisely across independent implementations. An informal assumption that two peers will compress and decode the same fields is not enough for an interoperable protocol.

The compression mechanism is historically important because it addressed repeated metadata overhead, but its presence should not be simplified into “HTTP/2 compresses all content.” HPACK compresses HTTP field representations; content encodings and application payloads remain distinct concerns. HTTP/2’s wins came from a bundle of framing, concurrency, prioritization, and header handling choices, not one generic compression switch.

Standardization preserved some ideas and revised others

RFC 7540 defined streams, frames, flow control, header compression integration, and a priority scheme. The 2022 revision, RFC 9113, obsoleted RFC 7540 and RFC 8740. It retained the protocol name and core model while changing some requirements based on implementation experience. For example, RFC 9113 deprecates the priority scheme from RFC 7540 and notes that the HTTP/1.1 Upgrade mechanism was not widely deployed and is no longer specified there.

This update is a useful reminder that standards are maintained records, not museum plaques. The original RFC documents what the standard was in 2015; RFC 9113 is the current HTTP/2 specification in the sources checked for this article. When an operator or developer consults an older tutorial, they should compare any protocol requirement with the current RFC rather than assume every 2015 detail remains recommended.

Adoption changed software stacks, not web content semantics

Supporting HTTP/2 required changes in network stacks: browsers needed to negotiate and speak the framing protocol, servers and reverse proxies needed to parse it, and diagnostics needed to distinguish protocol negotiation from an application error. A site could often retain its methods, paths, status codes, and application logic, but the client-facing transport stack had to implement the new connection and stream model correctly.

The practical result depended on workload. A page with many small resources could benefit from fewer serialized exchanges and less repeated header data. A page dominated by a large download, an overloaded server, or a lossy network might see different results. One connection also has a shared congestion and failure context. HTTP/2 therefore offered tools for using connections more efficiently, not a blanket promise of a fixed percentage improvement for every site.

The historical shift is best understood as an optimization of a widely deployed protocol at the layer where browser and server implementations could coordinate. Rather than abandoning HTTP semantics, SPDY and then HTTP/2 reorganized how messages were represented and multiplexed. The standard gave that experiment a shared contract, and RFC 9113 records how the contract evolved after deployment.

Reading the standards as a timeline

For a reliable technical history, use each source for the question it can answer. The Chromium whitepaper documents SPDY’s proposal and original goals. The 2013 Chromium announcement describes the project’s connection between SPDY and the IETF HTTP/2 work. RFC 7540 records the published 2015 protocol, RFC 7541 specifies HPACK, and RFC 9113 gives the revised HTTP/2 requirements. These sources are more precise than retrospectives that collapse prototype, draft, publication, and later revisions into one launch date.

The resulting lineage is not “Google invented HTTP/2” or “HTTP/2 is just SPDY with a new number.” SPDY supplied an influential experiment; an open standards process produced HTTP/2; the resulting protocol retained a goal of efficient concurrent HTTP exchanges while specifying different interoperable mechanisms; and the current RFC revised parts of the first standard. That sequence explains both the continuity and the changes without mistaking a historical prototype for today’s normative specification.

Related:

Sources: