Google SPDY promises speedy Web browsing

By Richi Jennings. November 13, 2009.
(GOOG)

Your humble blogwatcher selected these bloggy morsels for your enjoyment. Not to mention Tweetlanta...
 
 
Cade Metz rushes in where fools fear to tread:

Google is developing a new application layer protocol designed to speed the movement of stuff across the web. It's called SPDY, pronounced, yes, speedy. ... this "early-stage" research project is specifically designed to reduce latency via things like multiplexed streams, request prioritization, and HTTP header compression.
...
This "early-stage" research project is specifically designed to reduce latency. ... Google's documentation explains that SPDY is not a means of replacing http. It will create a session between the HTTP application layer and the TCP transport layer.

Here's Iljitsch van Beijnum: [Crazy name, crazy guy -Ed.]

The main problem with HTTP is that today, it's used in a way that it wasn't designed to be used. ... It wasn't designed to transfer a large number of small files efficiently, and this is exactly what the protocol is called upon to do with today's websites. ... Loading all those individual files mostly takes time because of all the overhead of separately requesting them and waiting for the TCP sessions HTTP runs over to probe the network capacity and ramp up their transmission speed.
...
In an attempt to avoid these issues, SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate.

Google's Mike Belshe and Roberto Peon come not to bury Caesar:

HTTP is an elegantly simple protocol that emerged as a web standard in 1996 after a series of experiments. HTTP has served the web incredibly well. We want to continue building on the web's tradition of experimentation and optimization, to further support the evolution of websites and browsers.
...
There is still a lot of work we need to do to evaluate the performance of SPDY in real-world conditions. However, we believe that we have reached the stage where our small team could benefit from the active participation, feedback and assistance of the web community. ... We invite you to review our early stage documentation, look at our current code and provide feedback through the Chromium Google Group.

Alex Russell is excited:

The really interesting stuff from my perspective is the way SPDY enables server push both for anticipated content and for handling Comet-style workloads. The first bit is likely to have the largest impact for the largest set of apps. Instead of trying to do things like embed images in data: URLs — which punishes content by making it uncacheable — SPDY allows the server to anticipate that the client will need some resource and preemptively begin sending.
...
One socket, many requests. Statefully. By default. Awwwww yeah. That means that a client that wants to hang on to an HTTP connection (long polling, “hanging GET”, <term of the week here>) isn’t penalized at the server since SPDY servers are expected to be handling stateful, long-lived connections. ... SPDY finally brings servers into architectural alignment with how many clients want to use them.

commodore64_love misses a simpler time:

I used to be able to participate in discussion forum with nothing more than a 1200 baud (1kbit/s) modem. If I tried that today, even with all images turned off, it would take 45 minutes to load [Slashdot].

But James Ranson proposes prior art:

AOL actually does something similar to this with their TopSpeed technology, and it does work very, very well. It has introduced features like multiplexed persistent connections to the intermediary layer, sending down just object deltas since last visit (for if-modified-since requests), and applying gzip compression to uncompressed objects on the wire.
...
In full disclosure, I was proud to be a part of the team that made it all possible. It's too bad all of this is specific to the AOL software, so I'm glad a name like Google is trying to open up these kind of features to the general internet.

Didn't I see an infomercial about this? Karl Bode opines:

Over the years we've seen no limit of specialized hardware, software or other gadgetry promising to defeat the laws of physics and speed up your Internet connection above and beyond its basic capabilities. From the "Juice Boosted" scam to Earthlink's latest absurd acceleration ploy, by and large these are all snake oil. Even well-intentioned ideas to deploy new, faster protocols 99.4% of the time wind up being little more than blistering hype.
...
We've seen these kinds of promises so many times ... compression, new protocols, or variations of existing protocols, that we're just kind of innately skeptical until we see real world application. As with any innovation, you might want to wait until Google has a working product before doling out your kisses.

So what's your take?
Get involved: leave a comment.
 
 
And finally...

• Which Tweet is from Atlanta?
  

Richi Jennings is an independent analyst/consultant, specializing in blogging, email, and security. A cross-functional IT geek since 1985, he is also an analyst at Ferris Research. You can follow him as @richi on Twitter, or richij on FriendFeed, pretend to be richij's friend on Facebook, or just use good old email: itblogwatch@richij.com.

 
 
Don't miss out on IT Blogwatch:

• Subscribe to the Computerworld Blogs and IT Blogwatch newsletters
• Catch up with posts from the previous few days