Google Works on a Protocol Intended to Replace HTTP

Posted by Abel Avram on Nov 13, 2009

Sections

Architecture & Design,

Development,

Operations & Infrastructure

Topics

Internet ,

Architecture ,

Performance & Scalability

Tags

Web Server ,

Chrome ,

HTTP ,

Google

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.

1. Back to top

   The biggest problem so far.....

   by Paul Fremantle

   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

   Reply

2. Back to top

   I am trepedacious

   by Porter Woodward

   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.

   Reply

3. Back to top

   Re: I am trepedacious

   by Marc Stock

   @Porter
   
   I agree. I always hate it when people try to ram performance improvements down my throat.

   Reply

4. Back to top

   Beware of Google

   by ryan martin

   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 :)

   Reply

5. Back to top

   Re: I am trepedacious

   by Abel Avram

   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.

   Reply

6. Back to top

   One of those things that will be buried quietly

   by Tero Vaananen

   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.

   Reply

7. Back to top

   push !!

   by Erik Gollot

   Maybe what they really want is "push" !.........to push !!!

   Reply

8. Back to top

   Re: Beware of Google

   by Esko Luontola

   Hmmm, what would be the next thing to re-invent...? x86?

   Reply

9. Back to top

   HTTP and SPDY happily ever after!

   by Roshan Shrestha

   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?

   Reply

10. Back to top

    Re: I am trepedacious

    by Roshan Shrestha

    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).

    Reply

11. Back to top

    SPDY?

    by Trung Nguyen

    Not sure about other stuff but typing SPDY is definitely not as user-friendly as HTTP

    Reply

• Older >