Google unveiled an experimental open source project in early November
aimed at reducing web site load times. SPDY, as it is called, is a
modification to HTTP designed to target specific, real-world latency issues
without altering GET, POST, or any other request semantics, and without
requiring changes to page content or network infrastructure. It does this
by implementing request prioritization, stream multiplexing, and header
compression. Results from tests on a SPDY-enabled Chrome and a SPDY web
server show a reduction in load times of up to 60%.
SPDY is part of Google's "Let's
make the web faster" initiative that also includes projects targeting
Belshe and Roberto Peon announced SPDY on November 11 on both the Chromium and
Research blogs, noting that "HTTP is an elegantly simple protocol
that emerged as a web standard in 1996 after a series of experiments. HTTP
has served the web incredibly well. We want to continue building on the
web's tradition of experimentation and optimization, to further support the
evolution of websites and browsers."
Finding the latency in HTTP
The SPDY white
paper details the group's analysis of web latency, beginning with the
observation that although page requests and responses rely on both HTTP as
the application-layer protocol and TCP as the transport-layer protocol, it
would be infeasible to implement changes to TCP. Experimenting on HTTP, on
the other hand, requires only a compliant browser and server and can be
tested on real network conditions.
The group found four factors to be HTTP's biggest sources of latency.
First, relying on a single request per HTTP connection makes inefficient
use of the TCP channel and forces browsers to open multiple HTTP
connections to send requests, adding overhead. Second, the size of
uncompressed HTTP headers, which comprise a significant portion of HTTP
traffic because of the large number of HTTP requests in a single page.
Third, the sending of redundant headers — such as User-Agent and Host
— that remain the same for a session. Finally, the exclusive
reliance on the client to initiate all HTTP requests, when there are cases
where the server knows that related content will be requested, but cannot
push it to the client.
SPDY tackles these weaknesses by multiplexing an unlimited number of
concurrent streams over a single TCP connection, by allowing the client to
assign priorities to HTTP requests in order to avert channel congestion,
and by compacting HTTP request and response headers with gzip compression
and omitting the redundant transmission of headers. The SPDY draft specification
also includes options for servers to initiate content delivery. The
available methods are "server
push," in which the
server initiates transmission of a resource via an X-Associated-Content
header, and "server hint," in which the server only suggests related
resources to the client with X-Subresources.
In addition, SPDY is designed to run on top of SSL, because the team
decided it was wiser to build security into its implementation now than to
add it later. Also, because SPDY requires agents to support gzip
compression for headers, it compresses the HTTP data with gzip too.
The important thing to note is that SPDY's changes affect only the
manner in which data is sent over the wire between the client and the
server; there are no changes to the existing HTTP protocol that a web page
owner would notice. Thus, SPDY is not a replacement for HTTP so
much as a set of possible enhancements to it.
Comments on the blog posts indicate that although most readers see the
value in header compression and request prioritization, some are skeptical
of the need to multiplex HTTP requests over a single TCP connection. Other
alternatives have been tried in the past, notably HTTP pipelining and
the Stream Control Transmission Protocol
The white paper addresses both. SCTP, it says, is a transport-layer
protocol designed to replace TCP, and although it may offer some
improvements, it would not fix the problems with HTTP itself, which SPDY
attempts to do. Implementing SCTP would also require large changes to client
and server networking stacks and web infrastructure. The latter is also
true for similar transport-layer solutions like Structured Stream Transport
(SST), intermediate-layer solutions like MUX, and HTTP-replacements like
Blocks Extensible Exchange
The problem with pipelining, it says, is that even when multiple requests
are pipelined into one HTTP connection, the entire connection remains
first-in-first-out, so a lost packet or delay in processing one request
results in the delay of every subsequent request in the pipeline. On top of
that, HTTP pipelining is difficult for web proxies to implement, and remains
disabled by default in most browsers. The fully multiplexed approach taken
by SPDY, however, allows multiple HTTP requests and responses to be
interleaved in any order, more efficiently filling the TCP channel. A lost
packet would still be retransmitted, but other requests could continue to be
filled without pausing to wait for it. A request that requires server-side
processing would form a bottleneck in an HTTP pipeline, but SPDY can
continue to answer requests for static data over the channel while the
server works on the slower request.
Implementation and test results
The development team wrote a SPDY web server and added client support in
a branch of the Chrome browser, then ran tests serving up "top 100" web
site content over simulated DSL and cable home Internet connections. The
test included SSL and non-SSL runs, single-domain and multiple-domain runs,
and server push and server hint runs. The resulting page load times were
smaller in every case, ranging from 27.93% to 63.53% lower.
The team's stated goal is a 50% reduction in load time; the average of
the published tests in all of their variations is 48.76%. Though it calls
the initial results promising, the team also lists several problems —
starting with the lack of well-understood models for real world packet loss
SPDY remains an experiment, however, and the team solicits input on a
number of open questions, including dealing with the latency introduced by
SSL handshakes, recovering from a lost TCP connection, and how best to
implement the server-side logic to truly take advantage of server push and
server hint. Interested people are encouraged to join the mailing list and
download the code.
So far, only the modified Chrome client code is available, and that from
the public Subversion repository, not binary downloads. Peon said that the
server release is coming soon, and the project page says that the test
suite and benchmarking code used in Google's test will be released under an
open source license as well.
A 50% reduction in page load times is nothing to sneer at, particularly
when all of the gains come from tweaking HTTP's connection and data
transfer behavior. Header
compression alone gives noticeable savings; the white paper states that it
resulted in an "~88% reduction in the size of request headers and an
~85% reduction in the size of response headers."
The future of the web may indeed include
new protocols like SCTP and BEEP, but SPDY is already demonstrating that
there is plenty of room for improvement without drastically altering the
to post comments)