A 2x Faster web: SPDY

Google have created a new HTTP-based protocol “SPDY” (pronounced “Speedy”) to solve the problem of the client-server latency with HTTP. “We want to continue building on the web’s tradition of experimentation and optimization, to further support the evolution of websites and browsers. So over the last few months, a few of us here at Google have been experimenting with new ways for web browsers and servers to speak to each other, resulting in a prototype web server and Google Chrome client with SPDY support.”

As a web developer, I can tell you that HTTP-requests are painfully slow and any decent front end developer optimises the content to use as few requests as possible, and to combine as many resources as possible into one request. The reason why it’s so slow? Firstly, the Request (the ping to ask what resource you want from the server) and Response (the header sent back to state the file type, size and caching information) headers are uncompressed. This is the first thing SPDY rectifies:

Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Mbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 – 1142 ms in page load time simply due to header compression.

Google describe the basic principle of how SPDY works in one line:

SPDY adds a session layer atop of SSL that allows for multiple concurrent, interleaved streams over a single TCP connection.

The use of SSL gives them safe passage through proxies and legacy network hardware, as well as increasing security for all users of the web—this is most welcome giving what some backwards countries are planning to do.

SPDY multiplexes the resource requests, increasing overall throughput. Fewer costly TCP connections need to be made. Whilst HTTP-Pipelining can allow more than one request per TCP connection, it’s limited to FIFO (and thus can be held up by one request), and has proven difficult to deploy—no browser ships with support enabled (The FasterFox add on for Firefox does enable HTTP-Pipelining, but at the cost of compatibility with some servers)

Results have been good, Google’s goal is a 50% increase in speed. Under lab conditions “The results show a speedup over HTTP of 27% – 60% in page load time over plain TCP (without SSL), and 39% – 55% over SSL.”

An interesting feature of SPDY is the ability for the server to push to the client. At the moment the server cannot communicate with the browser unless a request is made. Push is useful, because it would allow web apps to receive a notification the instant something happens, such as mail arriving, rather than having to poll the server at an interval, which is very costly. AJAX apps like GMail and Wave currently use a faux-push hack, whereby an HTTP-Request is left open by the server (it never hangs up on the browser) keeping the AJAX in a suspended state whereby the server can add information to the end of this hanging request and the browser receives it immediately. SPDY will allow for much greater flexibility with server push, and bring web apps that bit closer to the desktop.

Google are quick to stress the experimental nature of SPDY, all existing work has been done under lab conditions, and they are uncertain how it will perform “in the real world”. There are also a number of questions still be answered about packet loss and deployment (compatibility with existing network equipment is key to adoption, especially when you have such awful network operators like AOL in the game).

All in all, Google are not looking to outright replace good ol’ HTTP, rather to augment it with new capabilities that compliment its purpose to serve you content. I’m glad that Google are willing to question even such a well established corner stone of the Internet as HTTP—if we don’t ask questions then we will never discover better ways of doing something. Google are really pushing every field of Internet engineering to get this big mess we call home moving in a positive direction—they can hardly expect Internet Explorer to be waving the banner of progress after all.


  1. dmrio 2009-11-12 8:15 pm EST
    • Kroc 2009-11-12 9:08 pm EST
      • dmrio 2009-11-13 3:07 pm EST
    • gustl 2009-11-14 10:40 am EST
  2. dindin 2009-11-12 8:23 pm EST
    • Delgarde 2009-11-12 8:35 pm EST
    • BallmerKnowsBest 2009-11-12 11:31 pm EST
      • FunkyELF 2009-11-13 6:08 pm EST
  3. Delgarde 2009-11-12 8:27 pm EST
  4. geleto 2009-11-12 8:32 pm EST
    • cerbie 2009-11-12 11:42 pm EST
    • modmans2ndcoming 2009-11-13 4:10 am EST
      • geleto 2009-11-13 5:29 pm EST
        • modmans2ndcoming 2009-11-15 4:41 am EST
  5. jharrell 2009-11-12 8:39 pm EST
    • elanthis 2009-11-12 10:32 pm EST
  6. joshv 2009-11-12 8:47 pm EST
  7. tomcat 2009-11-12 8:58 pm EST
    • evert 2009-11-12 10:06 pm EST
      • tomcat 2009-11-12 11:09 pm EST
        • dnebdal 2009-11-12 11:24 pm EST
          • tomcat 2009-11-12 11:41 pm EST
          • ichi 2009-11-13 12:08 am EST
          • DOSguy 2009-11-13 12:30 am EST
          • tomcat 2009-11-13 1:10 am EST
          • Panajev 2009-11-13 11:26 am EST
          • DOSguy 2009-11-13 6:14 pm EST
        • ichi 2009-11-12 11:25 pm EST
          • tomcat 2009-11-12 11:41 pm EST
          • madcrow 2009-11-13 12:30 am EST
    • Soulbender 2009-11-13 6:06 am EST
  8. harcalion 2009-11-12 9:07 pm EST
    • mckill 2009-11-12 9:12 pm EST
    • galvanash 2009-11-13 1:28 am EST
      • FealDorf 2009-11-13 9:29 am EST
        • Kroc 2009-11-13 11:30 am EST
          • FealDorf 2009-11-13 12:52 pm EST
          • Johann Chua 2009-11-13 1:19 pm EST
          • FealDorf 2009-11-13 1:29 pm EST
          • Bill Shooter of Bul 2009-11-13 5:42 pm EST
        • gustl 2009-11-14 10:56 am EST
  9. JacobMunoz 2009-11-12 10:20 pm EST
    • modmans2ndcoming 2009-11-13 4:14 am EST
    • sbenitezb 2009-11-13 5:13 am EST
    • Soulbender 2009-11-13 6:15 am EST
      • JacobMunoz 2009-11-13 4:02 pm EST
    • ghen 2009-11-13 8:00 am EST
  10. bornagainenguin 2009-11-13 3:01 am EST
    • Kroc 2009-11-13 7:37 am EST
  11. tyrione 2009-11-13 3:21 am EST
    • gomerComPiler 2009-11-13 7:42 am EST
  12. deathshadow 2009-11-13 9:25 am EST
    • kaiwai 2009-11-13 10:09 am EST
      • Kroc 2009-11-13 11:33 am EST
      • ba1l 2009-11-13 3:16 pm EST
      • cerbie 2009-11-13 9:15 pm EST
    • Kroc 2009-11-13 1:00 pm EST
    • edmnc 2009-11-13 1:33 pm EST
      • deathshadow 2009-11-14 3:17 pm EST
  13. 3rdalbum 2009-11-13 10:02 am EST
  14. Brunis 2009-11-13 11:27 am EST
    • Kroc 2009-11-13 11:37 am EST
      • FealDorf 2009-11-13 12:55 pm EST
  15. harsha.reddy 2009-11-13 1:53 pm EST