SPDY and What's Wrong with HTTP

SPDY has arrived - quietly, almost unannounced. Here is a quick overview of why it is important.

HTTP was designed over 10 years ago to deliver web pages that are significantly different (and simpler) than today's. HTTP is no longer efficient for modern web applications.

HTTP Limitations

  • HTTP can only fetch one resource at a time per connection. This means a delay by the server will block that connection until the previous request has been serviced. Modern browsers support between 2 and 6 connections but this HTTP limitation still creates inefficiency.
  • HTTP only supports client requests - a server cannot initiate a request even if It knows the browser needs additional resources.
  • HTTP request and response headers are typically around 800 bytes these days. That is a large overhead for each resource request and response.
  • Several headers are repeatedly sent across a connection even if the headers are static (eg User-Agent, Host, and Accept)

Here Comes SPDY

In response to the limitations of HTTP Google engineers proposed SPDY - a new networking protocol designed to speed up the web. SPDY doesn't replace but augments HTTP with several key features that dramatically reduce page load time:

SPDY enables:

  • Client and server to compress request and response headers, cutting down on bandwidth
  • Multiple, simultaneously multiplexed requests over a single connection
  • The server to actively push resources to the client that it knows the client will need without waiting for the client to request them

As I mentioned SPDY does not replace HTTP but modifies the way HTTP requests and responses are sent over the network. This means that all existing server-side applications can be used without modification once the SPDY-compatible translation layer is put in place.

SPDY got off to a slow start but is now gaining momentum as performance becomes a competitive battleground. SPDY is now implemented on most browser clients including IE11, and implemented by Google, Twitter and Facebook. It is only a matter of time when SPDY will be implemented on sites such as ecommerce, online gaming and banking.

Performance Testing Challenges

Because of the extra layer added by SPDY there is an impact on performance - SPDY relies on one unique encrypted socket. This means that your server and network equipment are loaded differently. The SSL encrypted communication uses more CPU than HTTP and loading a web page requires fewer sockets.

To date NeoLoad is the only load test tool which can generate SPDY traffic and enables you to test your SPDY enabled servers under realistic conditions.