Google sees 15% speed boost with HTTP tweak
All Google SSL connections now SPDY
Ensure Ease of Recovery with Asigra’s Agentless Software
Velocity Google is now using its HTTP-boosting SPDY protocol to accelerate almost all SSL web traffic between Chrome browsers and its many web services, and according to Mike Belshe, an engineer on Google's Chrome team, the protocol is juicing performance by more than 15 per cent on average.
"We do not have any property that is not performing better with SPDY than without," Belshe said this afternoon at the O'Reilly Velocity conference in Santa Clara, California.
SPDY quietly made its debut with Chrome 6, and Initially, the protocol was only turned on for a limited percentage of SSL connections to Google services. But Belshe says the company is now using the protocol about 99 per cent of the time. The remaining one per cent, he says, is a necessary control group. "The only way we can measure how it works – the only way we can figure that 15 per cent [speed boost] – is to measure exactly the same usage case," Belshe told us following a conference presentation.
First unveiled as an experimental project in the fall of 2009, SPDY is an application layer protocol designed to improve the speed of the aging HTTP. The protocol has been available with Chrome since the sixth version of the browser, but at this point, it only kicks into action when the browser is used with Google services and a few other test platforms. At this point, Google services use SPDY exclusively with SSL connections.
Earlier this week, Strangeloop added SPDY to its flagship online service, which websites use to accelerate their load times, and the Israel-based Cotendo has said it will add SPDY to its content delivery network. Cotendo offers services for accelerating both desktop and mobile traffic, but SPDY is not yet available on mobile devices.
Mike Belshe
Belshe confirmed that the Google Android team is incorporating SPDY into the mobile operating system's browser, and he said that Mozilla is "interested" in using the protocol as well. Google also offers a public SPDY proxy, and there are now SPDY servers written in C++, Python, Go, Ruby, and node.js. The project is open source.
SPDY creates a session between the HTTP application layer and the TCP transport layer, using an HTTP-like request-response setup. It speeds downloads via multiplexed streams, request prioritization, and HTTP header compression. Multiplexing is the main change, Belshe says. With HTTP, you can only handle one request at a time, and though you can open multiple connection, if you open too many, you run into problems with TCP. Multiplexing is hardly a complicated change – "it's been done before, there's no new idea here," Belshe says – but it solves much of the problem.
At this point, SPDY is limited to application layer. It does not require kernel changes. You don't have to rewrite apps. You simply need new web servers and clients. But Belshe says that Google will eventually extend its work. "Because we can identify issues at the application layer, it made sense to try to address those first, develop an application protocol that works really well, that people agree works really well, and then start to dig down," he said. ®
COMMENTS
Errm...
Except or course, it's open-source and free... no one really has an objection with giants coming up with new technologies, it's their job, as long as they're backwards compatible and don't break stuff.
No, Google hasn't published a full spec @alain williams
If you read the spec you'll see it's far from full. There are too many holes on it, even many parts still saying TODO.
It may be here on day, but it's not now. They seem to move very quickly at implementing it in their products but reallyyyy slow when it comes down to putting into a document.
And while this goes on they are already using it unfairly to push their own products.
SPDY - proprietatry or not ?
Google has published a full spec of the protocol, this means that others are capable of implementing it fully and compatably. If you choose to not use SPDY things will still work, albeit not so quickly.
The MS way is to extend a standard in a way that is not completely documented, then fail interoperation if the extensions are not used.
Note that it is still under development. I would hope/expect to see an RFC come out of this at some point.
IT infrastructure monitoring strategies
Agentless Backup is Not a Myth
Steps to Take Before Choosing a Business Continuity Partner
Requirements Checklist for Choosing a Cloud Backup and Recovery Service Provider
Data control in the cloud
