Tracking change and innovation in the enterprise software development community
Free Book Offer
SOA Demystified
$40 Value
Scaling Scrum
in the enterprise?
ScrumWorks Pro
can help.
Start a trial today
QCon London 2010!
March 10-12, 100
Speakers, 80 sessions,
"THE" team leads and,
architects conference.
Posted by Abel Avram on Nov 13, 2009
Google proposes SPDY, a new application protocol running on top of SSL, a protocol to replace HTTP which is considered to introduce latencies. They have already created a prototype with a web server and an enhanced Chrome browser that supposedly loads web pages twice as fast.
Google initiative, "Let's make the web faster", launched some times ago aims to improve the speed on the Internet. The initiative covers several domains, from building a faster web server to building a faster browser. For example, Page Speed is a tool used to improve web pages to make them be downloaded faster. Google has open sourced a number of tools and published tutorials to help developers around the world improve the speed of their web sites.
But Google has not stopped there. They play with a new application protocol named SPDY, pronounced SPeeDY, which, if successful and widely adopted, would replace HTTP in what would be an overhaul of the entire Internet backbone. The SPDY whitepaper mentions the idea of going down the stack and replacing the transport protocol (TCP) with a better one, but they recognize it would be quite hard to deploy, so they intend to improve the application protocol instead, HTTP.
SPDY whitepaper mentions a number of limitations in the HTTP protocol introducing latency in page delivery:
- 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.
One of SPDY’s goals is to reduce the page load time by 50%, making browsing twice as fast. While a few hundred milliseconds might not mean much for an user, every millisecond will count for the highly interconnected web applications of the near future. The current web content is not affected by the introduction of the new protocol, only the web servers and their clients need to be enhanced to make use of it.
What exactly does Google want with SPDY?
To allow many concurrent HTTP requests to run across a single TCP session.
To reduce the bandwidth currently used by HTTP by compressing headers and eliminating unnecessary headers.
To define a protocol that is easy to implement and server-efficient. We hope to reduce the complexity of HTTP by cutting down on edge cases and defining easily parsed message formats.
- To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
- To enable the server to initiate communications with the client and push data to the client whenever possible.
To achieve these goals, SPDY is built by adding a session layer on top of SSL allowing for “multiple concurrent, interleaved streams over a single TCP connection”. The HTTP GET and POST message formats remain unchanged but SPDY proposes a new “framing format for encoding and transmitting the data over the wire”. The streams are to be bi-directional, being initiated both by the client and the server.
So far, Google has build an in-memory server that handles both HTTP and SPDY protocols with the code to be open sourced soon. Also, there is a modified Chrome version, internally and, they say, temporarily called flip (source code available), that works both with HTTP and SPDY. They have also created a suite of testing tools to make sure that pages are downloaded correctly with SPDY. These tools are also to be released soon.
Based on the prototype, the results are looking promising so far:
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
It is obvious that Google won’t succeed alone in this endeavor even if they create the best protocol there could be. It is necessary that the community embraces and joins the effort to create a new application protocol. It is interesting to see how other major players will react.
Resources: SPDY draft protocol specification, SPDY enabled Chrome.
Consolidation and Virtualization Are NOT Enough: The Case for Non-x86
Understand and Align BPM, SOA, and Lean Six Sigma: 43 page IBM Redguide
The article is bang on: Google needs community to make this happen, and so far there is *no* code project for the server, no Google discussion group for the spec and not even a comment box at the bottom of the white paper. I think SPDY seems like technically it has some merits, but Google has to open up fast if they want to engage the community.
Paul Fremantle, CTO, WSO2
While I agree these are issues with HTTP and the ways in which it is now being used... I can remember the "old days" of the web - when vendors were putting out various accelerator plugins to enhance the efficiency of HTTP. None of them were all that great and they only worked well if everybody had it - the classic problem of "what good is a phone, if you're the only person with one?"
If someone can do it or at least start the process of doing it - Google can. I think it's probably important to them to get something "coded" up first before releasing it to the "bazaar". But yes - it will need community involvement and quick. Otherwise it will seem like something that big G is trying to ram down our throats.
@Porter
I agree. I always hate it when people try to ram performance improvements down my throat.
So google has..
----------------
re-invented email,communication : Wave
created an operating system : Chrome OS
created a mobile platform : Android
created a browser : Chrome
created a new systems programming language : Go
and now...rewriting HTTP : Spdy
They want everything. If they aren't evil now..give it time.
Sounds awesome though :)
They already have a web server and a Chrome version (flip) implementing SPDY. flip is available for download and the web server is to be made available soon.
I hope I am not alone, but this is one of those things in the category of "aint ever gonna happen". This thing will be quietly put down into garbage as people realize that HTTP is virtually irreplaceable. It's like trying to get rid of IP v4...which has not happened...and there is no burning need to replace HTTP, so the chances are non existent that it will be replaced.
Maybe what they really want is "push" !.........to push !!!
Hmmm, what would be the next thing to re-invent...? x86?
If Google server up their pages over both HTTP and SPDY, and future Chrome browser support both HTTP & SPDY, then I will probably switch to using Chrome browser, knowing that it will work with other web sites, AND be twice as fast on Google sites.
So do I type spdy://google.com?
Google could support SPDY on their sites for Chrome browser, while still maintaining support for other browsers with HTTP. Since this will make Google sites twice as fast, more people will start using Chrome and more people will start visiting Google sites - a perfectly happy scenario for Google. In time, other sites may start supporting SPDY.
Google has control of the Chrome browser - earlier web sites utilizing "web-accelerator" did not have this luxury (IE and Netscape where the only choice).
Not sure about other stuff but typing SPDY is definitely not as user-friendly as HTTP
Brian Marick takes us through a quick tour of the most important values and challenges to adopting Agile successfully (they aren't the typical challenges and values we hear in the community).
The line between development and architecture is tricky. Does it exist at all? Is an ivory tower actually needed? There's a balance in the middle, but how do you move from developer to architect?
The word 'authority' sometimes produces an allergic response in hard-line agilists. Freedom and authority – both are bad if misused and both are good if used in right spirit for a noble cause.
"Getting Started with Grails" brings you up to speed on this modern web framework. Companies as varied as LinkedIn, Wired, and Taco Bell are all using Grails. Are you ready to get started as well?
Those familiar with only ITIL V2 often scoff at the thought that ITIL could serve as a governance framework for SOA. With ITIL V3, the focus of the framework shifted towards service-orientation.
SpringSource CTO Adrian Colyer discusses AspectJ, SpringSource's dm Server and tc Server products, OSGi and Scrum.
Heroku's Adam Wiggins talks about Rails, Background Jobs, Add-Ons, Ruby, and how Heroku manages to work around Ruby's inefficiencies using Erlang and other languages.
For Grady Booch the foundation of a good architecture is patterns, SOA being just one of many patterns. In this Second Life presentation, Booch attempts to bring more clarity on what architecture is.
11 comments
Watch Thread Reply