Since it's creation in the early 1990's, by Sir Tim Berners-Lee, the World Wide Web has operated on top of the HTTP and TCP protocols. Almost everything an average user would do on the net would have these protocols working behind the scenes to request, reply and display a website or page to the user. Over the years we have seen great advances in speeding the web up, from the increasing usage of fibre optics to better programming methods of web sites and servers. The Internet though can only be as fast as the protocols it operates under can provide.

With this in mind Google wants to augment the ageing HTTP protocol with it's own SPDY (pronounced "speedy") protocol, with the aim of reducing latancy and therefore allowing websites to load faster. As Google describe on their blog HTTP is an  "elegantly simple protocol", however as part of it's 'Lets make the web faster' initiative, Google thinks that HTTP has many shortcomings when it comes to providing next generation web services and experiences. As part of their research Google has found that HTTP has the following shortcomings (quoted from chromium.org):

• 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.

Their findings have led them to the development of the SPDY protocol. Initial simulations of the experimental protocol show definite speed increases over HTTP. The company has set up a test that comprises of a typical computer system, running a special version of the Chrome browser that can handle SPDY requests. Google found that after connecting to the top 25 websites on the Internet, over half loaded faster with their protocol. Some sites loaded 64 percent faster over SPDY compared to HTTP.

Google being as collaborative as ever wants help from the outside world and as one of it's goals for SPDY, wants the open source community and industry specialists to help further the development SPDY.

For more information see the SPDY whitepaper.