SPDY: Let's make the web faster

Introduction

SPDY (Pronounced as "SPeeDY") is an open networking protocol similar to HTTP, with particular goals of reducing web page load latency and improving web security. SPDY achieves reduced latency through compression, multiplexing, and prioritization. 

Background: web protocols and web latency

Today, HTTP and TCP are the protocols of the web. TCP is the generic, reliable transport protocol, providing guaranteed delivery, duplicate suppression, in-order delivery, flow control, congestion avoidance and other transport features. On the other hand, HTTP is the application level protocol providing basic request/response semantics.

Unfortunately, HTTP was not particularly designed for latency. Furthermore, the web pages transmitted today are significantly different from web pages 10 years ago and demand improvements to HTTP that could not have been anticipated when HTTP was developed. The following are some of the features of HTTP that inhibit optimal performance:

• Single request per connection: Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue), a server delay of 500 ms prevents reuse of the TCP channel for additional requests. Browsers work around this problem by using multiple connections. Since 2008, most browsers have finally moved from 2 connections per domain to 6.
• Exclusively client-initiated requests: In HTTP, only the client can initiate a request. Even if the server knows the client needs a resource, it has no mechanism to inform the client and must instead wait to receive a request for the resource from the client.
• Uncompressed request and response headers: Request headers today vary in size from ~200 bytes to over 2KB. As applications use more cookies and user agents expand features, typical header sizes of 700-800 bytes is common. For modems or ADSL connections, in which the uplink bandwidth is fairly low, this latency can be significant. Reducing the data in headers could directly improve the serialization latency to send requests.
• Redundant headers: In addition, several headers are repeatedly sent across requests on the same channel. However, headers such as the User-Agent, Host, and Accept* are generally static and do not need to be resent.
• Optional data compression: HTTP uses optional compression encodings for data. Content should always be sent in a compressed format.

Goals for SPDY

The SPDY project defines and implements an application-layer protocol for the web which greatly reduces latency. The high-level goals for SPDY are:

• To target a 50% reduction in page load time.
• To minimize deployment complexity. SPDY uses TCP as the underlying transport layer, so requires no changes to existing networking infrastructure.
• To avoid the need for any changes to content by website authors. The only changes required to support SPDY are in the client user agent and web server applications.

Some specific technical goals are:

• To allow many concurrent HTTP requests to run across a single TCP session.
• To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.
• To define a protocol that is easy to implement and server-efficient. 
• To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure.
• To enable the server to initiate communications with the client and push data to the client whenever possible.

SPDY design and features

SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection. The usual HTTP GET and POST message formats remain the same; however, SPDY specifies a new framing format for encoding and transmitting the data over the wire.

Streams are bi-directional, i.e. can be initiated by the client and server. SPDY aims to achieve lower latency through basic (always enabled) and advanced (optionally enabled) features.

Basic features

• Multiplexed streams SPDY allows for unlimited concurrent streams over a single TCP connection. Because requests are interleaved on a single channel, the efficiency of TCP is much higher: fewer network connections need to be made, and fewer, but more densely packed, packets are issued.
• Request prioritization Although unlimited parallel streams solve the serialization problem, they introduce another one: if bandwidth on the channel is constrained, the client may block requests for fear of clogging the channel. To overcome this problem, SPDY implements request priorities: the client can request as many items as it wants from the server, and assign a priority to each request. This prevents the network channel from being congested with non-critical resources when a high priority request is pending.
• HTTP header compression SPDY compresses request and response HTTP headers, resulting in fewer packets and fewer bytes transmitted.

Advanced features

In addition, SPDY provides an advanced feature, server-initiated streams. Server-initiated streams can be used to deliver content to the client without the client needing to ask for it. This option is configurable by the web developer in two ways:

• Server push SPDY experiments with an option for servers to push data to clients via the X-Associated-Content header. This header informs the client that the server is pushing a resource to the client before the client has asked for it. For initial-page downloads (e.g. the first time a user visits a site), this can vastly enhance the user experience.
• Server hint Rather than automatically pushing resources to the client, the server uses the X-Subresources header to suggest to the client that it should ask for specific resources, in cases where the server knows in advance of the client that those resources will be needed. However, the server will still wait for the client request before sending the content. Over slow links, this option can reduce the time it takes for a client to discover it needs a resource by hundreds of milliseconds, and may be better for non-initial page loads.

For technical details, see the SPDY draft protocol specification.

Server Side Implementation

As of April 2013, approximately 1% of all websites support SPDY. Some Google services (e.g. Google search, Gmail, and other SSL-enabled services) use SPDY when available. Google's ads are also served from SPDY-enabled servers. SPDY community is working on developing modules for various server platform.

• Jetty Web Server: http://wiki.eclipse.org/Jetty/Feature/SPDY
• Apache module for SPDY: http://code.google.com/p/mod-spdy/
• Python implementation of a SPDY server: http://github.com/mnot/nbhttp/tree/spdy
• Ruby SPDY: https://github.com/igrigorik/spdy
• node.js SPDY: https://github.com/indutny/node-spdy

Browser support and usage

• Google Chrome:  SPDY sessions in Chrome can be inspected via the URI: chrome://net internals/#events&q=type:SPDY_SESSION%20is:active. 
• Firefox: Firefox included in version 11, and default-enabled since 13 and later. SPDY protocol functionality can be (de)activated by toggling the network.http.spdy.enabled variable in about:config. Firefox 15 added support for version 3 of this protocol.
• Opera: Opera browser added support for SPDY as of version 12.10.
• Internet Explorer: Internet Explorer 11 added support for SPDY version 3, but not for the Windows 7 version.
• Amazon's Silk: Amazon's Silk browser for the Kindle Fire uses the SPDY protocol to communicate with their EC2 service for Web page rendering.