SPDY: Google Wants to Speed Up the Web With New Protocol
Google has just announced that it is working on a new protocol that will minimize latency and speed up the Web experience for users. SPDY (pronounced "speedy") is not meant to replace HTTP, the protocol that allows Web servers and browsers to talk to each other today, but it does augment HTTP. The new protocol incorporates features like multiplexed streams, request prioritization and HTTP header compression. Google has already developed a prototype Web server and a version of Google Chrome with built-in SPDY support.
Google claims that pages loaded 64% faster in lab tests in which the research team downloaded the top 25 websites. Now that the SPDY team has developed workable prototypes, Google decided to open up the process and is soliciting the "active participation, feedback and assistance of the web community."
In today's announcement, Google stresses that SPDY is not a replacement for HTTP. It uses HTTP methods and headers, but it overrides the parts of the protocol that manage connections and data transfer formats.
Google will soon release its open-source SPDY-enabled Web server. The source code for the SPDY-enabled version of Chrome can be found here.
Creating a Faster and More Secure Web
According to the SPDY white paper, the project's goals are to reduce page load times by 50%, minimize deployment complexity and avoid the need for website owners to make any changes to their sites to implement SPDY. Instead, all the hard work will happen in the client and the Web server.
The team also wants SPDY to allow many concurrent HTTP requests to run across one TCP session and to make SSL the standard transport protocol.
Google clearly has an interest in making the Web experience as fast and secure as possible for its users. One of the reasons Google released its own browser was to get every other browser developer to focus on speed again. SPDY is even more ambitious. With SPDY, Google wants to change one of the most fundamental protocols on the Internet.
According to Google, these are the basic improvement of SPDY over HTTP:
- Multiplexed requests. There is no limit to the number of requests that can be issued concurrently over a single SPDY connection. Because requests are interleaved on a single channel, the efficiency of TCP is much higher.
- Prioritized requests. Clients can request certain resources to be delivered first. This avoids the problem of congesting the network channel with non-critical resources when a high-priority request is pending.
- Compressed headers. Clients today send a significant amount of redundant data in the form of HTTP headers. Because a single Web page may require 50 or 100 subrequests, this data is significant. Compressing the headers saves a significant amount of latency and bandwidth compared to HTTP.
Facebook
Comments
Subscribe to comments for this post OR Subscribe to comments for all ReadWriteWeb posts
Awesome! love google!
By controlling both the client and server end, in a lab setting, only achieved 64% improvement? Seriously! If it's not some bored googlers are doing and posting it, it's not even worth a mentioning.
wow.. google got the superb track to get the speed up the web with new protocols
typo: SLL instead of SSL ('and to make SLL the standard transport protocol.')
Most of the time I see slow page loads it comes down to poorly written Javascript and/or abuse of third party content pulled from ad-servers, stat collectors and the like. Neither of which this would appear to address.
I dont know what you can do about web designers who abuse javascript and third party widgets. It probably only helps where designers put to many source files on the same server. But good luck to them. I assume that they have put it into the IETF to see if it gains traction.
Good Work Google...
Its good that someone is trying to make world(web) better.
This will definitely help to reduce the traffic on net. My question here is that is there any new enhancement in SPDY for mobile devices, as tomorrows web is highly dependent upon these small devices.
Great invention! Hope to see this as standard.
Allen: when car traffic is slow, do you teach the drivers to be better at dodging the holes or do you fix the roads?
Posted by: plillevold.myopenid.com
|
November 13, 2009 2:44 AM
@Rajesh G How will it reduce traffic on the web??
the first thing that came to my mind was the 64% improvement....in lab scenario........this may not rollover down to more than 10% in real world assuming the code is wriiten perfectly.....
What about using SCTP instead of TCP?
SCTP is already a network standard, it supports parallel streams, was designed to work over connections with long latency (e.g. satellite links), etc. It is aimed at replacing TCP, and its design is based on decades of TCP experience.
Most operating systems support SCTP already (Win XP may need a 3rd party library).
What is wrong with an approved standard that addresses many of the "benefits" listed for SPDY?
Most of the time spent loading pages I look at seems to be taken up by loading ads and Google site analysis tools. Cut out those and you've be speeding right along.
By trying to increase loading speeds of pages as they are, Google is really only trying to support its bottom line. They aren't doing us any favors here.
Would like to see what others do in that way, Microsoft and open source web servers, anyway I like the idea. I will be the first one that will use Chrome web browser.
@Mohammed
Where are you getting your numbers? Sounds like a very uneducated guess to me.
@tudza
How is any boost in performance not doing us a favor? If your ads and analytics are loading twice as fast, will that not improve your perceived download time?
What is your objection to free ad supported search? Would you rather pay and not have ads?
127.0.0.1 google-analytics.com
put it in your hosts file, and the web is nice and dandy again. oh and adblock
@moksha
its definitely going to reduce traffic all over the web if its faster.. means it is going to use less data to transmit the required message..
will google down for a short moment when come out new protocol?
This could mean great things for the web and Google certainly has the muscle to push adoption of a new protocol, I guess we'll have to see how it stands up in the real world and how or if adoption will come.
Looks like good engineering, addressing the performance issues in the correct layer. Google should call it HTTP 2.0 ;-)
IETF, anybody listening?
Is any of this actually necessary? for who, well obviously for Google, it gives them a competitive edge which translates into higher profits. but for everyone else including other IT employees it's not going to make any difference. i'm talking about the big picture here, not about technical specs. Wow this article was incredibly boring. the web is super speedy already. it's like the word "satisfaction" comes from an archaic language
I think the timing on this is actually pretty good. Google isn't the only one working on the problem, they just happen to make a bigger splash. The web, specifically http is not designed with low latency in mind. Despite that we need it to be fast and responsive. I think their strategy of slipping this in between TCP and HTTP is well reasoned if they are trying to build an incremental improvement of existing technology and actually want it adopted.