A 2x Faster Web
Wednesday, November 11, 2009
Labels: New Features
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.
This post is cross-posted at the Google Research Blog
100 comments:
Adam Fisk said...
Love it! Especially the interleaved channels and header compression. Great to see a group just throw their hat in the ring to start knocking out problems like this -- just the kind of proactive approach we need to create a better web!
November 12, 2009 10:43 AM
Jason M. Batchelor said...
Any chance that this is what continues to hold up the Mac version of Chrome, or have I missed a release announcement?
November 12, 2009 11:20 AM
Artem Russakovskii said...
This might just be the most important announcement for the web in the past 10 years. Keep pushing, guys!
November 12, 2009 11:28 AM
SiliconShaft said...
So by 2x Faster web you meant 1.5 times faster yeah? Apart from that sounds great! Keep going.
November 12, 2009 11:36 AM
kar said...
Looks very promising ...would definitely look at the code
November 12, 2009 11:45 AM
Digital Jedi said...
Someone seems to think that Google is five guys working on one project at the one time.
November 12, 2009 11:49 AM
dtiriba said...
Can't wait
November 12, 2009 11:59 AM
Jason M. Batchelor said...
Actually, if it was just 5 guys working on the project (Chrome, right?) I could understand the delay. As it is, the project team has produced how many releases of the Windows browser vs. how many releases of the Mac browser?
I'm much less interested in hearing how they've engineered Web 3.0 than in hearing how they're coming with the products they've already announced, personally. When I see a solid product for both platforms (as that's what they promised from the outset), then maybe I'll be interested in hearing of their new plans for the Web.
November 12, 2009 12:06 PM
Mike Beltzner said...
Despite potential difficulties with uptake, optimizing technologies for today's web uses has value. I've created a bug in Mozilla's bug tracker to follow this work as well.
November 12, 2009 12:17 PM
Andrew Charlton said...
Is this available in binary distributions of Chromium or is it source only for now?
November 12, 2009 12:17 PM
GeLeTo said...
I see one downside to this. With only one TCP connection loosing a packet will pause the transmission of ALL resources till the the lost packet is retransmitted. Because of the way the TCP/IP congestion works - loosing a packet is not a rare occurrence. There are two ways around this - use multiple TCP streams or better - use UDP.
November 12, 2009 12:28 PM
admin said...
Finally! -- web standards and a browser developed by the same team. I can't wait to see SPDY in action and how it positively affects cloud-based services.
November 12, 2009 12:39 PM
GeLeTo said...
...(continued from my previous post) or use a modified implementation of the TCP protocol that gives the application some control over the packet sizes and allows out-of-order receiving of packets.
November 12, 2009 12:48 PM
Titio Pentelho said...
Awesome.
November 12, 2009 12:55 PM
John "Z-Bo" Zabroski said...
Are you aware that there is an IETF Working Group for something similar?
The two proposed languages are Argot/XPL and EXI.
November 12, 2009 1:00 PM
upal said...
I guess all in all its a move towards web 3.0. First the wave, then GO language and now SPDY. I also smelt something similar while someone described wave as old wine in new bottle as XMPP was invented in 1998 (ref: Beginning of Web 3.0).
November 12, 2009 1:03 PM
Mike Belshe said...
@Jason - definitely not holding up the Mac. The Mac team is working extremely hard, and they want to get you a quality release. Sorry for the time it takes.
@kar - keep your expectations low! The first goal was to see how much faster we can get. That will be a continuing process. The code may be disappointingly simple, and there are bugs-a-plenty. But feedback is welcome!
@Andrew - the code is in chromium; it hasn't yet reached the chrome official releases. It will eventually, but it needs more work.
November 12, 2009 1:06 PM
Mike Belshe said...
@GeLeTo: Packet loss is a huge concern, one which we're actively studying (want to help?) We believe the answer will be in a protocol which can dynamically determine the right number of connections.
There is a growing number of connections with little or no loss. For these, 1 channel is optimal, as we can do better compression and better prioritization.
However, even using multiple connections, SPDY fares better than HTTP today. There are several reasons: a) it's sending about 40% fewer packets. This just makes it much less vulnerable to loss. b) Losing a SYN packet in TCP is disproportionately expensive. As per the TCP spec, the client must wait 3 seconds before retransmitting the first SYN. This is an *enourmous* amount of time. While HTTP opens up to 6-8 connections per domain (meaning 6-8 SYN packets), SPDY uses 1. In a random loss world, this means SPDY has fewer of these disproportionately expensive delays. c) TCP is actually pretty good (when using SACK) at keeping throughput high in the presence of packet loss. This is largely thanks to TCP's fast-retransmit algorithm. Because SPDY more efficiently uses the channel and more often has continued data flowing, it is able to hit fast-retransmit cases much more frequently than HTTP can, where only a single request flows at a time.
A lot more research needs to be done on this. We need better packet loss simulators, a better packet loss model of the real world, and we need to figure out how (or when) to throttle up more connections. I think we can get there.
November 12, 2009 1:10 PM
Alexander Orlov said...
With an own browser Google has enough power to push this technology. Other companies will adopt it fastly if they see the benefits via Google's services.
November 12, 2009 1:16 PM
nwhite said...
@Jason M. Batchelor relax on the who OS X issue. Mac users generally use a great browser by default (Safari). Windows is the place where the evolution of the web is being slowed. I am glad to see google put priority in the Windows environment. With that said I've had Chromium running on my OS X machine for a while now.
http://build.chromium.org/buildbot/snapshots/chromium-rel-mac/
@admin you mentioned "Finally! -- web standards and a browser developed by the same team."
There is nothing web standards about this. Its a proposed technology, if we find it beneficial as a community it could become a standard. Releasing software in no way makes it official or a standard.
November 12, 2009 1:18 PM
Oliver Oli said...
spdy://www.google.com ?!?
sorry, but the name SPDY is ridiculous and looks ugly.
November 12, 2009 1:18 PM
OneLifeLiveIt said...
Not sure if you guys in the labs have heard of a company called Endace - they have some great packet capture hardware that may be of interest for the server side of your development. www.endace.com is the URL
November 12, 2009 1:23 PM
Gherald L said...
If you're not replacing HTTP, but embracing and extending, then why not call it...HTTP 2.0 ?
November 12, 2009 1:35 PM
Brandon said...
I have a 10 meg charter connection. 99% of all pages will load with out a blink of an eye a small fraction of pages that say have bad java code, bad css or crap in the headers they do not need will cause a slow down but most of the time not noticed. I think the biggest problem to a slow down in page loading is web sites that use flash excessively, FLASH is a horridly slow loading application under any circumstances. I for one useally click back out of websites that use flash. I tend to love the beautiful designs and pages that one can create with css and wordpress. Most themes in wordpress can be made very beautiful and fulfilling to the websites reader with out the need for flash. I think we need to work on a new method for streaming video and animation and not rely on flash. I know there are some other applications out there but I am picking on flash because most websites that have heavy animation and or video use it. Very slow and outdated. Why should us developers focus on developing an open source a new protocol to make certain web companies bigger and more powerful. Its a great concept but I for one am not going to update my servers to a new method of delivering data in less its got its security in check and is a stable application. Trending article on my upcoming blog at: http://preview.tinyurl.com/yg5mu55
Another thought also comes to mind no matter how fast a page can load on your end or how fast your browser can render the page. The server on the other needs to load the page just as fast. If your server is on a 1 meg uplink heaven forbid And you are using 50% processing power and have a overloaded hard drive then you are still going to run in to the same problems. It is not always the users of the internet that is the problem sometimes it is our servers and data centers that are the problem as well. What those everyone think about that suggestion.
November 12, 2009 1:57 PM
nickshanks said...
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.
November 12, 2009 2:08 PM
Andreas said...
Sounds promising, but I concur with the earlier comment of SiliconShaft: 55 % is NOT 2x faster! You should change the title of your post, Mike!
November 12, 2009 2:09 PM
jms said...
Not sure what OS you are using but I don't thing anyone is following the TCP spec anymore.
Why do you feel packet loss is the most important issue, what networks are you thinking about. You would want to have some thought around object size as it relates to request priority and the relation to the TCP window size.
Here is some good reading http://caia.swin.edu.au/talks/CAIA-TALK-080122A.pdf. In addition, we did some work earlier this year modeling contention and the impact on efficient link utilization.
November 12, 2009 2:25 PM
phreakhead said...
This is a good start by Google, but I think if you are going to completely replace HTTP, you should do so in the most extreme way possible as to pave the way for websites 10-20 years from now.
The minor tweaks SPDY is about is more like optimizing HTTP. Sure you can get things twice as fast, but why not 10x? 100x?
Torrent technology has shown us that the fastest way to deliver content is via a distributed network. If HTTP could be replaced by a Torrent-like protocol, where each client in the network is actually a server as well, the web would be not only faster, but more reliable. A website's servers could go down, but the content would still be available since everyone viewing the site would also be a mirror! Slashdotting would be a thing of the past!
You can read more on this idea and discuss it on The Distributed Web and Why Netbooks Are a Waste.
November 12, 2009 2:41 PM
rmenglish@gmail.com said...
I've never quite understood the TCP SYN timeout. It's hard to believe there's a deep theoretical basis for a 3 second timeout, one that has somehow managed to remain stable for decades. Moreover, even if TCP stacks were to adhere rigorously to the 3 second standard, it wouldn't stop applications from terminating and restarting connections in less than three seconds. In that respect, 6-8 HTTP connections could be more tolerant of SYN losses, not less. It all depends on whether the data stream is bound to a socket before or after the connection open is complete.
November 12, 2009 2:48 PM
John "Z-Bo" Zabroski said...
Silly me. I forgot to link to the Working Group. It is 6LowApp.
http://trac.tools.ietf.org/area/app/trac/wiki/6LowApp
Argot/XPL was designed by David Ryan over the past decade,
whereas EXI is basically a heavily compressed XML Infoset Model-conforming XML documentation.
November 12, 2009 2:58 PM
John "Z-Bo" Zabroski said...
@rmenglish
Originally, TCP's -ilities were poorly understood.
In fact, TCP by itself is a bulky name without much meaning. People are usually referring to TCP Vegas and TCP Reno. These are different congestion detection and avoidance schemes. Windowing size will be a huge factor in *propagation delay*.
Bottom line: when you're discussing the performance of TCP, you have to be aware of what the network is.
November 12, 2009 3:05 PM
Alex Noguera said...
Cool, let's see what it is capable of...
November 12, 2009 3:17 PM
Brian Pontarelli said...
I worked on a project a number of years ago called IAP (Internet Application Protocol) that was very similar. We used a pure binary format that had a small header followed by a body.
Some of the benefits of IAP were:
- Multiple requests and responses were always over the same connection
- It dictated semantics on true caching of content that were necessary for sporadically connected clients when they are offline
- It was oriented more around applications than static content and provided requests such as OpenApplication, GetData, InvokeAction, GetView, etc.
- It supported rich data types not just Strings, including int, float, char, string, arrays, etc. All data was transmitted in binary so no conversion was necessary (as long as the client was the same endian)
- It had built in parental controls
- It was fully multiplex capable
- It was stream capable
- It was designed around the concept of sporadically connected applications and client side storage
- It had built in security via request types called AuthenticateUser and AuthorizeUser
- And more
After a 2-3 years of development, we had a full server and a browser written. We were planning on starting to write the language for the browser that would replace HTML/JavaScript/CSS, but never got there. We were going to call it IAL. The idea of the language was to fix the mess that is HTML/JavaScript/CSS and make a much more powerful environment for applications.
Everything worked quite nicely and was definitely a fun experiment. I'm hoping that at some point a large enough company really takes a stab at rewriting HTTP/HTML/JavaScript/CSS/etc. I've already proven that it is possible and makes sense and I'm waiting to see what happens.
It sounds like SPDY is a small step in the right direction, but has a huge way to go. HTML5 and all the new CSS and JavaScript work are decent, but they could definitely use an overhaul as well.
November 12, 2009 3:18 PM
Ronnie said...
"Losing" , the gerund of the verb "to lose" is not spelt "loosing".
:-)
November 12, 2009 3:32 PM
Bob Hansen said...
I'm interested in the details of the protocol, but it might be an interesting convergence to bring SPDY and SCTP together; that covers the "one dropped packet" concern. Since SCTP takes care of stream identity at layer 4, it might make the SPDY protocol considerably simpler than trying to interleave streams in the HTTP layer.
November 12, 2009 3:34 PM
Roberto said...
@oliver
Hopefully we'd never see spdy://...
That would be contrary to our goal of speeding things up without requiring content to change!
@phreakhead
I designed a p2p protocol in the past, and so have some love for new ideas... I think we have to take one step at a time, though.. One of the things we're attempting to do is design the protocol so that it is much easier to extend in the future. When/if we figure out that way to make things go 100X faster, hopefully changing or using the protocol won't be the bottleneck
November 12, 2009 3:39 PM
jms said...
Understanding TCP and the various implementations can be a life's work. Remember TCP starts out with a small window size and then scales up (at least per the spec.) so dropping a connection and reestablishing would be painfully expensive both in terms of connection setup and window scaling.
John "Z-Bo" Zabroski is also correct that understanding the network in use is a requirement.
Is this the forum for discussing engineering / research issues?
November 12, 2009 3:39 PM
Mark said...
I see this being a great implementation to use for HTML5 WebSockets. But to replace HTML I don't see the value in a 50% speedup at the cost of a completely new protocol. Unless it becomes as trivial as installing mod_spdy on an alternate port or coming up with an upgrade mechanism like discussed for the WebSockets back end.
PS: I implemented something very similar for use in a private application, nice to know I was on the right track.
November 12, 2009 3:42 PM
Mike Belshe said...
@brandon - of course you are right. Browsers, servers, and the protocol all need to be faster :-)
You're lucky to have 10Mbps, but the average user has ~1Mbps, and mobile users generally have far less than that. But equally critical is the RT time, and you probably have a ~10ms, while those poor cell phones have 100-400ms RTTs!
When you're on a 2Mbps link with a 20ms RTT, downloading a 350KB page (the average top-25 webpage is about that size), it's going to take ~1.5s just to download. Rendering in the browser is going to cost ~200-400ms (varies on the page), and server processing time usually is in the 50-250ms range. As you can see, the relative performance of the network is pretty heavy.
Your overall conclusion is still correct - web servers and browsers also need to improve. But hopefully the data shows there is justification in looking at the network too.
November 12, 2009 3:45 PM
tim said...
"sorry, but the name SPDY is ridiculous and looks ugly."
The name HTTP doesn't look ridiculous and ugly to you?
November 12, 2009 4:01 PM
Maxime said...
Is there any public available web-server serving queries over SPDY ?
November 12, 2009 4:03 PM
Jamie said...
Will it be possible set up a SPDY proxy (similar to a SOCKS proxy) for sites that don't support it? That could make quite a difference on my rural ADSL connection. :)
November 12, 2009 4:07 PM
BrandonLive said...
Cool stuff Mike!
@Ronnie - "Losing" isn't a gerund unless it's used as a noun. "Losing" is the present participle form of "to lose." :)
November 12, 2009 4:28 PM
Roberto said...
@Maxime
Hey there! Sorry, I'm in charge of open-sourcing a sample server.. It is coming soon!
November 12, 2009 4:31 PM
yonan32 said...
why aren't you building it on GO?
November 12, 2009 7:50 PM
Adonim said...
oh yes concerning security, it would be nice if some sort of encryption would be enabled by default (so if the server supports ssl or some other sort of encryption you don't need to use a different url to get the benefit of encryption). many passwords are at risk because people are too lazy or uncanny to enter the httpS:// in front of their email site or whatnot.
I would like it to be able to make use of the new pentium instruction sets for encryption. also some way for authentication or rather verfication that the connection hasn't been comprimised although that might be for a higher level protocol to do..
November 12, 2009 8:41 PM
Ian said...
Looking forward to whatever comes of this. I'm a firm believer in squeezing every last bit of web performance out of my hardware/connection as possible, and this is certainly a way to do that.
Looking forward to publicly available client/server versions that will gracefully scale down to plain old HTTP when some Luddite decides to view a page i IE :p
November 12, 2009 9:00 PM
viji said...
Nice to see that google is taking the web forward...
November 12, 2009 10:29 PM
Oleg Bezorudko-Chyrykalov said...
50% faster is not 2x faster guys... Though I am glad to see the advances.
November 12, 2009 11:29 PM
Reivall said...
November 13, 2009 1:12 AM
Javier Daza Conejero said...
Nice work from google, seems they take care of the evolution of the web. I think that SSL should be standar in web conections, people don't take care about security for themselves. Now to take a view into the code
November 13, 2009 1:13 AM
Remi Grumeau said...
Only Google can do that ...
November 13, 2009 1:34 AM
Ronnie said...
"Losing" is spelt "losing" not "loosing" :-)
R
November 13, 2009 3:01 AM
rasputnik said...
The nice thing these days is that advancing the state of the art doesn't necessarily need browser support.
More and more http clients are non-browsers anyway
(server-server).
Down at the desktop: is there anything stopping Javascript/GWT from retrieving content via non-http protocols?
November 13, 2009 3:07 AM
Bud said...
@Google - I think that this work is great, but testing that shows 55% improved load times versus live testing, will show the difference. Of course, it will be a while before something like this is adopted on a large scale. However, I look forward to it.
November 13, 2009 7:45 AM
Charles said...
A most interesting project. My company supplies Internet connectivity via sync satellites. We're already currently processing both TCP (via XTP) and HTTP in the middle, to accelerate performance. I'd be interested in helping, perhaps in the following ways:
1) Specs: I'd be interested in reviewing the specs and tech roadmap. At first glance, I couldn't find them. Specifically I'd like to make sure all the protocols remain cooperative and there are no unexpected interactions with existing processing systems. This project uses edge processing and we already have processing systems near the middle. We should strive for synergistic operation. In addition, we may be able to point out defacto requirements (at least for us) that are not obvious at first glance - in both the technical and business arenas.
2) Testing - Ultimately, if this catches on, we'll be interested in testing the protocols over our system. Perhaps we can contribute along the way.
I can move forward with the developer and testing groups. If you have any further connections to suggest, just let me know.
November 13, 2009 8:49 AM
Charles said...
Sorry - I am best contacted at:
C_Bergren@hotmail.com
November 13, 2009 8:58 AM
Jason M. Batchelor said...
Okay, okay... color me embarrassed... I have looked many times, and haven't found the link to the Mac version until this series of comments. Thank you very much.
I've been trying out the latest build today... very nice, very slick... I'm liking it a lot so far.
So, my apologies for coming off like a dweeb... still, could someone ask the Mac team to post something in regard to their progress on Chromium, so those (like me) can see that the needle is still in motion?
Thanks again!
November 13, 2009 10:08 AM
Joe said...
50% less time taken and 2 times faster are synonymous. If you guys think about what you're saying for a moment, you believe that in order for something to be 2 times faster, it must take 100% less time.
That wouldn't be two times faster, that would be infinity times faster.
If a page loads in four seconds under HTTP, and two seconds in SPDY, then it just took 50% less time, but is "twice as fast."
November 13, 2009 10:36 AM
kkll2 said...
Please push SCTP instead. It solves the same problem, but in more general fashion and will benefit more applications (don't be selfish, HTTP is not everything).
November 13, 2009 1:24 PM
nkuehn said...
Hi
I really like SPDY - in my opinion it hits a sweet spot because it seems to be designed around downwards-compatibility (no internet routing hardware changes affected and no hurt to UAs that don't support it) and HTTP transparency (neither the server application developer nor the client html-css-js developer need to change their habits, best practices, knowledge or existing applications).
Especially the transparency could be adressed stronger in the communication of SPDY because imho it is key to fast adoption by web developers.( mod_proxy_http2spdy / mod_spdy someone??)
It may be even sweeter in mobile applications where the content-body size is already very optimized by the developers and latency is really bad. (I assume you'll get the packet-loss/SYN/etc. questions solved somehow, packet loss can be bad in mobile nets afaik)
Are there plans for Android? Did you do your speed comparisons on mobile sites, too?
And, not to forget - free ssl for everyone :-) !
Looking forward to see implementations to try out, Nikolaus
November 13, 2009 1:52 PM
Roberto said...
@kkll2
We've thought about SCTP, and we'd love to be using it..
.. But ...
SCTP isn't a silver bullet. It provides multiplexing and helps with packet loss, but it doesn't do prioritization. In order to allow the browser to request things as quickly as it discoveres them, you have to promise that you'll serve the most important content first (i.e. serve the HTML+CSS+JS before you do the myriad of images, etc!)
SCTPs feature set could be enhanced to do this kind of thing, and then you could add a header to HTTP, and that would get you much of the way there.. but you'd still not have the header compression that saves the people on slower links!
.. So anyway, yup, SCTP is good. Its just not good enough on its own!
November 13, 2009 2:01 PM
taleks said...
Hm, I'd like to see robust testing before any praises. I'm concerned about compressed requests from server side point of view in real wild internet environment.
What about CPU usage on high-loaded servers? What share of this fifty percents speedup is related to compression, and what to multiplexing of streams? From SPDY tech doc it's seems that compression gives big impact ("We found a reduction of 45 - 1142 ms in page load time simply due to header compression." (c) http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper . However total page loading time is 3100 ms (1608 ms at SPDY powered soft) at the same article, so throwing away compression may easily transform "2x faster" buzzwords to less impressive results).
Although compression is good for bandwidth and compressed http-reply output is not rare thing today, however, let's think about amount of requests and it's sizes.
When we talk about small amount of requests, let's say less than 1000 requests per second I don't see any bottlnecks, however more requests -> more buffers for compression (memory overhead, memory fragmentation as well) -> more CPU utilization for LZ77 even on small-scale windows (CPU overhead). So, at some point there will be no benefits already for dynamical content (although it's possible to provide effficient pipeline for statical content, of course). The question is where is this point? I bet it is not such far away. I've not seen yet tests of thousands of simultaneous requests to web-sites. I think, compression must be optional and enforced during handshake as option. BTW: as for options, I think "estimated" bandwidth at HELLO control message is bad approach with many side effects.
Other thoughts are related to SCTP and SPDY comparisions.
Users may gain some benefits in SPDY due three major points: multiplexing, compressing and priorities of streams. From user side it seems like speed up of internet, and every normal user would like to see such improvement.
1. Compressing is subject to test, as overloaded server will never make user experience better. The other concern is mobile devices: PC is strong enough to compress everything (just see Snow Leopard file system compression, everyone is happy), but mobile devices are not such good in terms of performance.
2. Multiplexing in SCTP is better. SCTP supports multipoint streams, that may provide better performance for streaming over http and other multimedia related protocols (and multimedia data is going to take biggest part of Internet transmissions next years). SPDY goes only for http based content and makes web-crowling/browsing applications more sophisticated (just addition of streams handling increases complexity of such software), it's not good from application developer point of view.
3. SPDY is better at priorities, however as this protocol is fully between client/server, it's up to server how good prioritization will be implemented. It also gives additional overhead, due implementation of queueing with prorities and etc on _server_. There is also question, which data must have higher priority. Everyday's experience says: html, then images, then sounds, then everyting else. But in fact it depends on every site structure, thus site needs to instruct browser that some data is more needed then other. Do you remember any priority attributes in current html standarts (excluding video/audio tags, which understand "priority" in other way and for other purposes)
Although SCTP have also bad sides, I think more pushing of technologies based on it is better than standalone approaches to optimzation of web-transfers.
Anyway, SPDY is interesting idea, but - IMHO - with too many problems in adoption.
November 13, 2009 10:06 PM
Pinky's Brain said...
Without a standard for self-certified certificates this protocol will be rather painful to use for me as a Firefox user (having to click through 3 windows for each new website with a webmaster who doesn't want to pay for a cert). If you guys create a RFC for this it would be really nice if it included CERT-RR as an official alternative to CAs.
November 14, 2009 12:24 AM
Stifu said...
@Joe: you'd be right if the post actually said "50% less time". But it doesn't. It says "up to 55% faster". So your reply was pointless.
55% faster does NOT equal x2 faster, as pointed out several times. The only way to justify the "2x faster" thing is to consider that this is Google's goal, not what they achieved so far.
November 14, 2009 4:37 AM
Emir Delalic Zeko said...
hahhaha... its really stupid name...
whatever, it is nice thing that they work on that
November 14, 2009 6:43 AM
samuel said...
could this also have a power saving benefit, sending packets uses power, 40% less packets would see a power use reduction of 40%?
November 14, 2009 9:04 AM
Harry said...
Nice idea. About time, thanks.
Just would like to report from one of the worst trench on the frontline - Indonesia. Here we have lots of mobile users. I think your internal data will also verify this - Indonesia's mobile internet user is growing very rapidly
(I got the info from a friend of mine who got it from some Google guys in S'pore, who'd like to know why Indonesia is showing up on their radar quite prominently)
On the mobile, we got the worst possible scenario :
(1) Under-powered devices : sure, some are quite powerful. But, MOST are NOT.
(2) Packet loss : this is to be expected on wireless devices. Especially when you're on congested areas
(3) High latency
(4) Small available bandwidth
I've used my phone to browse the Internet, and it's quite a frustrating experience.
Sometimes I had to open up my bag and everything just so I can fire up my laptop - just to look up something simple. Would be nice if this can be avoided in the future.
An excellent application in this scenario is Gmail Apps for Symbian.
Can't praise it enough.
Even on slow & unreliable signal, it will work. Quite speedily too.
No idea how it accomplish it, but you may wish to look it up.
Anyway, wireless access is going to grow even faster in the future.
Your concern about packet loss and others are very much justified.
Thanks.
November 14, 2009 6:45 PM
Harry said...
Another thing about wireless access - it enable Internet access to proliferate even to remote areas MUCH faster than if we just rely on the good ol' cable.
Here in Indonesia we're witnessing explosive growth on Mobile internet users.
Suddenly Internet access is available even on remote areas.
Also, the providers are competing to provide the best UNLIMITED internet access packages - for as little as US$ 5 / month !
Of course, it may not be the fastest -- but the point is, more people are connected now than ever.
Access to the Internet has enabled people to do things they didn't think possible.
An example - we just have a national scandal exposed AND investigated, thanks to public pressure via FACEBOOK :-)
Very, very nice.
The Internet gave people voice.
It'd be really nice if Google can help support this in any way possible.
Thanks.
November 14, 2009 6:52 PM
Kaushik Bhandankar said...
Mike, I am still not sure how supporting multiple streams over a single underlying TCP connection will help solve the problem in case of packet loss. Further, how will TCP congestion avoidance work with SPDY request prioritization ?
Neverthless, some obvious latency gains are from compressing headers and not transmitting redundant headers.
November 14, 2009 7:08 PM
Harry said...
sorry this comment is just to enable email notification for me, thanks.
November 14, 2009 7:24 PM
Polin said...
Esto es interesante. Google son los mejores, por mi parte estoy ancioso por que esto llegue.
November 14, 2009 9:19 PM
skaiuoquer said...
@admin (who) said...
Finally! -- web standards and a browser developed by the same team. I can't wait to see SPDY in action and how it positively affects cloud-based services.
November 12, 2009 12:39 PM
Yeah ! Just like M$ =D
...
We trust you, Google.
Watch it.
November 14, 2009 11:22 PM
osmano807 said...
SSL! NO!
It's make proxy cache difficult a lot!
November 15, 2009 9:24 AM
mywit said...
Notification problems Google Chrome 4.0.245.0 Beta
when change google chrome language
November 16, 2009 1:26 AM
Vaishnavi said...
Wow....Web 3.0 is finally here... love it.....
November 16, 2009 6:12 AM
Maryam said...
Where do I download these files? Thanks!
November 16, 2009 5:58 PM
Maryam said...
.
November 16, 2009 5:58 PM
Arun S said...
totally against net neutrality,now what? dedicated hardware, chrome os, spdy protocol and then google says next president should be....... and we vote?? Google aint that diff from microsoft. Let me better align with linux and other guys where true open source exists...
November 17, 2009 7:25 AM
Annie said...
It's a good news for all of us. Specially for a student like me who rely on web for resources for my research papers. I'll be looking forward for this.
November 18, 2009 9:24 AM
Michael said...
Isn't this just reinventing the wheel that the IETF has already done in standardising BEEP? Have you looked at RFC 3080 and RFC 3081? It would be interesting to see a benchmark that compared SPDY, BEEP and plain HTTP/TCP.
November 19, 2009 2:17 AM
Brian Pontarelli said...
@Michael
If I recall, BEEP is a different layer. SPDY would sit on top of BEEP.
November 19, 2009 7:33 AM
Philip Kahn said...
Along the lines of "faster", I was curious if you guys had seen MS's IE9 stuff. Most of it is pitifully behind you guys (go Chrome!) but I think the Direct2D bits could be interesting.
November 19, 2009 4:05 PM
Prashanth Nuggehalli Srinivas said...
Waiting to test!
Meanwhile, any comments on this:
http://www.cultofmac.com/opinion-why-googles-chrome-os-will-look-hopelessly-antiquated-next-year/21663
November 20, 2009 1:24 AM
Rayzo said...
Not ashamed to the Google Guys have to invent this kind of thing to prevail and get more money? is that the HTTP protocol has lasted so many years by chance? not because it is stable and has more than proven? why not invent something that actually helps people in need instead of thinking all the time in imposing his ideas and concepts rather dismal, in my opinion
www.mecacho.com
November 20, 2009 6:49 AM
Nixtastic said...
Instead of breaking the header and data into separate gzips (thus forcing more than necessary decompression), what about pushing header information inside the content-disposition filename field or gzip metadata fields?
November 20, 2009 9:46 PM
talika said...
FANTASTIC GOOGLE
GO ON
November 29, 2009 4:53 AM
Md. Nasirul said...
Love this blog!1
Thanks for interesting articles
Google Wave Forum
December 1, 2009 8:43 AM
P@kirri said...
Well... i'm a student from Ecuador, and im really interested in testing this protocol but i don,t know how to do that....
If anybody can help me to test it ... by giving me a how to or telling me how to build the source code in windows or linux i really apreciate it....
If someone can help please contact me at franciscool004@gmail.com
P.D.: Keep up te good work because this announcement is really amazing
December 3, 2009 12:20 PM
CyberQat said...
December 21, 2009 7:44 AM
CyberQat said...
Oh boy another hack on a bag on a kludge. Lets restrict ourselves to one port on a machine, two connections at a time maximum, and then multiplex everything through that!
This is all like locking the front door and then trying to push the cat out through the key hole!
Maybe Web 10.0 will finally be the internet we had before this dann web stuff started,
December 21, 2009 7:46 AM
emanprinting said...
Really great Article thanks for share this article i like this work and this information is really helpful for me.
Custom Stickers
January 25, 2010 4:45 AM
EHSAN said...
Love it,thanks
Valentine Messages
January 26, 2010 3:06 AM
ap09.com said...
I would like to download.Could you please help me in finding the links?
February 3, 2010 8:34 PM
mounir said...
. I don't know what to say except that I have enjoyed reading. Nice blog.I will keep visiting this blog very often
Sell Gold
February 18, 2010 5:02 AM
mike said...
love to see this discussion! It’s great to see you all working through the issues and also, it’s great to see recommendations for testing. In the end, it’s what your actual users do and prefer hat should be your biggest driver in making these decisions.
get stage from home
March 4, 2010 10:43 AM
inseo said...
Oh, this is interesting. But where can I download?
Submit link free helps you promote what you want to promote.
March 8, 2010 10:11 PM
riderwear99 said...
keep it up.....please hurry up.i cant wait more........
May 7, 2010 3:34 AM
newhardware said...
Love it! Especially the interleaved channels and header compression. Great to see a group just throw their hat in the ring to start knocking out problems like this -- just the kind of proactive approach we need to create a better web!
May 26, 2010 2:49 AM
Mazhar said...
Someone seems to think that Google is five guys working on one project at the one time.
August 19, 2010 4:24 AM
Post a Comment