Cross-posted with the Chromium Blog.
Today we'd like to share with the web community information about SPDY, pronounced "SPeeDY", an early-stage research project that is part of our effort to make the web faster. SPDY is at its core an application-layer protocol for transporting content over the web. It is designed specifically for minimizing latency through features such as multiplexed streams, request prioritization and HTTP header compression.
We started working on SPDY while exploring ways to optimize the way browsers and servers communicate. Today, web clients and servers speak HTTP. 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. 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.
So far we have only tested SPDY in lab conditions. The initial results are very encouraging: when we download the top 25 websites over simulated home network connections, we see a significant improvement in performance - pages loaded up to 55% faster. 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.
For those of you who would like to learn more and hopefully contribute to our experiment, we invite you to review our early stage documentation, look at our current code and provide feedback through the Chromium Google Group.
skip to main |
skip to sidebar
Archives
16 comments:
This seems quite promising! A faster web environment is something that everyone should strive for, and something that large companies, such as Google, should help implement, and I applaud Google for experimenting with this.
However, how do you guys plan on implementing SPDY onto servers world-wide? Will there be some sort of application installation process, where you simply install a file that uploads the SPDY protocol onto your server, allowing SPDY enabled web browsers to access your pages through a SPDY connection?
Or something else entirely?
@Xak: Thanks for the encouragement.
We don't have a definitive plan on deployment, mostly because there is a tremendous amount of work to do before it would be realistic. Goal number one is building a protocol which works better than what we have today. As long as we build something compelling, I suspect lots of vendors will help. We will actively work with anyone that is serious about making this all work.
I am still advocating that browsers, proxies and caches support content type "multipart/mixed"
This would be a great way to provide multiple related documents in one request, without having to use data: URIs within the HTML code itself.
See this URL for an example:
http://web.nickshanks.com/browsers/safari/multipart
This example also tests base64 and Content-ID support, but you don't need to use either of those.
While you are implementing a new protocol, could you please add a "Comet" style "push" as a first class mechanism. And also a clean secure way to do cross-site javascript?
Thanks!
MIME message can carry pretty much anything. Why not using it to transfer complicated web pages in response.
Answer to Xak D.
More then likely a plug-in layer for Apache,
But IIS im not sure about yet im guessing this will run on a different port from the HTTP 80
Also i would love to show support for this system i would love to see the communication protocols but this means new browsers will be required for site using this witch screws up the cross compatibility Microsoft would have to join in to me to prove the SPDY browser in there base system
Other wise the Problem in Europe would a occur where no one would know how to download the new browser
Are proxies expected to understand SPDY? While I suppose they do not have to, it would seem they will be "closest" to the bottleneck link and so where you would want the SPDY prioritization to allow SPDY messages to leapfrog one another on the way to the client.
A couple questions:
Did the "real world" simulation :) include packet losses and proxies?
On the subject of proxies, is it expected that proxies will understand SPDY protocol? I can see where at least initially they do not need to, but given that they are likely closest to the bottleneck link I have to figure you would want them understanding SPDY to allow them to have SPDY messages leapfrog one another based on priority.
como tudo criado pelo google acho magnifico, acredito que este SPDY sera uma excelente evolução na velocidade ao acesso da linha web.
Ah, but will this new protocol allow caching? Or will it intentionally defeat it to make sure that every click is tracked? Also, will it deprive users of privacy? (Google has a motivation to do both, since it now owns DoubleClick.) We must beware that any new protocol proposed by Google is not designed to further Google's monopolistic aims.
I don't think proxy's will have a problem unless there web only proxy then you supposes a SPDY port web proxy will work
Most Proxy's work on a packet redirecting type of method
When you say 55% improvement, it is time consumption reduction doesn'it ? Does your study include multimedia standard such as image and video (or anything you could think of) ?
Well, whatever the gain is, 10% would be enough and it could have a great "green computing" argument to be spread (ie less data means less server consumption). I would be very interested to have more information on this indeed.
BTW, I like the sarcastic remark about "We must beware that any new protocol proposed by Google is not designed to further Google's monopolistic aims." Simply out of the context. Be sure that such contribution to the web from google will be opensource and double checked by all the community before using it.
Are Google actually claiming a server (or client) side reduction in processing overhead? I was under the impression that this was all about saving wall clock time, which does not necessarily mean fewer CPU cycles (eg compression).
Mike Belshe - would NetIPC message mode help here?-)
Wow this is really interesting! Are you looking to fully support (or create equivalents of) the 4 HTTP verbs (GET, POST, PUT, DELETE)?
55% faster is technically 1.55x as fast, 2x faster would be 100% faster.
Still, great job.
Never heard about this, until today. "resulting in a prototype web server and Google Chrome client with SPDY support."
Is there a way I can try this out? Just curious. Please outline steps.
Post a Comment