By Matthew Steele and Bryan McQuade,
PageSpeed Insights Team
At Google, we strive to make the whole web fast. Our work in this area includes PageSpeed, Google Chrome, and the SPDY protocol, among other
efforts. In December of 2011, to make it easy for you to enable the SPDY (pronounced "SPeeDY")
protocol on your sites, we released an early beta of mod_spdy, an Apache module that adds SPDY
support to the Apache HTTPD server. We’ve spent the last few months working with our early
adopters to fix bugs and tune performance of the module. Today, we’re launching a version of
mod_spdy that we encourage you to try on your web server.
Installing mod_spdy
To install mod_spdy on your Apache 2.2 server, simply download the appropriate mod_spdy Debian or RPM
package for your platform, or compile from source.
Once installed, your Apache server will begin using SPDY to communicate with SPDY-compatible
browsers (e.g. Google Chrome, Android, and recent versions of Firefox). SPDY runs over HTTPS,
so any HTTP (non-HTTPS) traffic on your site will not be affected by mod_spdy. Further, since
SPDY requires server-side support for the NPN TLS HTTPS extension, which is not available in
most current Apache environments, a version of mod_ssl with NPN support is included with the
mod_spdy packages.
Enabling SPDY for your site improves performance in several ways:
The server and browser can compress HTTP headers, saving bytes on the
network.
Multiple resource requests can be multiplexed over a single TCP connection, saving
connections on the network.
The browser can request all page resources at once instead of a few at a time, which
reduces the number of network round-trips needed between server and client.
We've tested mod_spdy using locally-mirrored pages from popular websites, and have
seen significant speedups compared to serving via plain HTTPS – comparable to the gains that
Google’s own servers achieve by using SPDY – with no extra configuration and negligible effect
on Apache’s CPU and memory usage. In extreme cases, for example, pages with many small
resources, we’ve seen mod_spdy reduce load times by more than 50%.
How mod_spdy works in Apache
Implementing SPDY in Apache posed several interesting challenges. For example, multiplexing is
an important performance feature of SPDY which allows for multiple requests in a single SPDY
session to be processed concurrently, and their responses interleaved down the wire. However,
due to the serialized nature of the HTTP/1.1 protocol, the Apache HTTP server provides a
one-request-per-connection architecture. Apache’s connection and request processing normally
happens in a single thread, like so:
This works well for HTTP, but it presents a problem for multiplexed protocols like SPDY
because in this flow, each connection can only process one request at a time. Once Apache
starts processing a request, control is transferred to the request handler and does not return
to the connection handler until the request is complete.
To allow for SPDY multiplexing, mod_spdy separates connection processing and request
processing into different threads. The connection thread is responsible for decoding SPDY
frames and dispatching new SPDY requests to the mod_spdy request thread pool. Each request
thread can process a different HTTP request concurrently. The diagram below shows the
high-level architecture.
Happily, all this is almost completely invisible to users and server administrators alike--you
can continue to use your existing Apache modules and configurations.
Download mod_spdy
for your platform and give it a try, and let us know what you think on our mailing
list. mod_spdy is an open-source
project and we welcome contributions. We are continuing to add new features, tune
performance, and improve support for up-and-coming versions of the SPDY protocol.
Matthew Steele and Bryan McQuade are Software Engineers on the Google PageSpeed
Insights Team in Cambridge, MA. When not working on mod_spdy, they focus on developing tools
to help site owners understand how to speed up their sites.
