SPDY: Google wants to speed up the web by ditching HTTP

Google isn't content with providing us with fast search and a fast browser: we …

On the Chromium blog, Mike Belshe and Roberto Peon write about an early-stage research project called SPDY ("speedy"). Unhappy with the performance of the venerable hypertext transfer protocol (HTTP), researchers at Google think they can do better.

The main problem with HTTP is that today, it's used in a way that it wasn't designed to be used. HTTP is very efficient at transferring an individual file. But it wasn't designed to transfer a large number of small files efficiently, and this is exactly what the protocol is called upon to do with today's websites. Pages with 60 or more images, CSS files, and external JavaScript are not unusual for high-profile Web destinations. Loading all those individual files mostly takes time because of all the overhead of separately requesting them and waiting for the TCP sessions HTTP runs over to probe the network capacity and ramp up their transmission speed. Browsers can either send requests to the same server over one session, in which case small files can get stuck behind big ones, or set up parallel HTTP/TCP sessions where each must ramp up from minimum speed individually. With all the extra features and cookies, an HTTP request is often almost a kilobyte in size, and takes precious dozens of milliseconds to transmit.

In an attempt to avoid these issues, SPDY uses a single SSL-encrypted session between a browser and a client, and then compresses all the request/response overhead. The requests, responses, and data are all put into frames that are multiplexed over the one connection. This makes it possible to send a higher-priority small file without waiting for the transfer of a large file that's already in progress to terminate. Compressing the requests is helpful in typical ADSL/cable setups, where uplink speed is limited. For good measure, unnecessary and duplicated headers in requests and responses are done away with. SPDY also includes real server push and a "server hint" feature.

So should we all praise Google and switch to SPDY forthwith? Not quite yet. With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP. Of course HTTP also runs over SSL in many cases, but there's also lots of content out there that doesn't need encryption. Making SSL mandatory is a strange move that has the potential to increase the number of people who don't bother getting a proper certificate for their server, meaning that users will become even more blas� about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks.

On small devices, SSL slows down the communication significantly, and because it can't be cached, SSL-protected sites are often slower on big machines as well. The extra CPU cycles also mean that more servers are needed to handle the same number of clients.

It also looks like this protocol is designed by Web people, rather than network people. How the IETF applications area will respond to this effort is a big unknown. For instance, one thing that isn't mentioned in the protocol specification is how a browser knows that it should set up a SPDY connection rather than an HTTP connection. Are we going to see SPDY:// in URLs rather than HTTP:// ? That wouldn't work with browsers that don't support the new protocol.

It's for reasons like this that the IETF isn't a big fan of replacing protocols wholesale. It's much more in line with the IETF way of doing things to add the new features proposed in SPDY to a new—but backward-compatible—version of HTTP. Designing a new protocol that does everything better than an existing protocol usually isn't the hard part. The real difficulty comes in providing an upgrade path that allows all the Internet users to upgrade to the new protocol in their own time such that everything keeps working at every point along that path.

This is something the SPDY developers recognize. There are proposals for running HTTP over SCTP, a protocol similar to TCP, but with the ability to multiplex several data streams within a single session. That would have some of the same advantages as SPDY. Unfortunately, most home gateways don't know about SCTP and can only handle TCP and UDP, so HTTP over SCTP would face a long, uphill battle, not unlike IPv6, but without the ticking clock that counts down the available IPv4 addresses.

That said, it's good to see interest in improving the underlying technologies that power the Web, and Google should be applauded for taking the discussion in a new direction. There's still a lot to be done in this space.

Iljitsch van Beijnum
Iljitsch is a contributing writer at Ars Technica, where he contributes articles about network protocols as well as Apple topics. He is currently finishing his Ph.D work at the telematics department at Universidad Carlos III de Madrid (UC3M) in Spain. Emaililjitsch.vanbeijnum@arstechnica.com//Twitter@iljitsch

68 Reader Comments

Im sure that they will come up with some way of letting the browser know what protocol to use, although a lot of users never upgrade their browser so it may be an issue. The blanket SSL thing confuses me too, but they may already be thinking of a way to solve that as well. I am wondering if this will result in servers running two instances of a website(one for each protocol).

You mention that SSL content cannot be cached. This is not strictly true, and is by convention rather than by specification. Safari, Firefox, Chrome, Opera don't cache SSL responses to disk by default, but Firefox 3 will if you explicitly set a Cache-control: public header. IE can be told explicitly to cache SSL content.

I would imagine, given that User agents will need to be updated to make spdy requests, there is very little impedance to including explicit directive regarding cache support in the spec. I would highly doubt Google would avoid supporting one of the cornerstones of web scalability.

On the SPDY white paper page, the Google researchers show a speed increase of up to 50 percent.

...

With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP.

You can already turn on mod_deflate/mod_gzip in apache and get the same sort of effect, I'm sure IIS has similar options. I turned on mod_deflate for anything with the a text type mimetype (essentially that adds up to php/html/css/js/etc) a couple weeks ago on a server that was handed to me. The changes got both a dramatic drop in bandwidth used & page load time, the server's bandwidth usage dropped like a stone and cpu usage only jumped a smidge. Most php/html/etc pages compress 30-90%+. Likewise, cranking the prefork options can give a nice little bump to a high traffic site as well. The 50% speed increase needs to be clarified if this is in comparison to a webserver with mod_deflate/mod_gzip enabled or not, if the answer is not then it's far less impressive than it sounds. The SPDY site linked doesn't mention mod_deflate or mod_gzip in the faq at the bottom, I'm guessing it's not compared to a server using one of those.

With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP.

Mandatory gzip compression is a GOOD thing. We've been CPU-rich and {everything else}-poor for years now, and CPUs aren't the main power draw in mobile devices anyways (that honour goes to the device screen usually).

With the advent of multi-threaded, multi-core netbook processors, this is only going to get more true as time goes on.

I work with a database technology that has just enabled some form of compression for requests over TCP/IP. Average compression of this data is about 3-4 times.

With text headers, the situation is probably even better (maybe even as high as 10:1).

Originally posted by kcisobderf:All the requests for web page(s) going to one computer bundled up in one tidy SSL session? How convenient it makes snooping by telecoms, Internet access providers, and governments.

SSL usually gets higher priority than unencrypted traffic. I won't believe their 50% speedup figures unless they factor out this - if everyone was using SPDY then giving SSL higher priority would be irrelevant.

quote:

You can already turn on mod_deflate/mod_gzip in apache and get the same sort of effect

mod_gzip / mod_deflate compress the data that your webserver sends back in response to requests. It looks like this protocol is two-way, compressing both the request responses *and* the outgoing requests from your own machine.

Originally posted by kcisobderf:All the requests for web page(s) going to one computer bundled up in one tidy SSL session? How convenient it makes snooping by telecoms, Internet access providers, and governments.

Tinfoil hat.

Well, as concerned citizens we do have a responsibility to drive up cpu usage for snooping the entire internet with one fat tube going to a phone company.

That means the gov needs to crack the ssl or look up the key (I assume), which takes even more cpu time. And, after all that, they will finally read the email to my mom that says the weather sucks.

You can already turn on mod_deflate/mod_gzip in apache and get the same sort of effect

mod_gzip / mod_deflate compress the data that your webserver sends back in response to requests. It looks like this protocol is two-way, compressing both the request responses *and* the outgoing requests from your own machine.

Not only is the compression two-way, but the SPDY spec also mentions compressing the request & response headers, which IIRC is not possible in HTTP. With HTTP, only the content can be zipped.

I'm disappointing that the author of this article seems to be unaware of some issues that I would assume any Ars contributor is keenly aware.

quote:

Of course HTTP also runs over SSL in many cases, but there's also lots of content out there that doesn't need encryption. Making SSL mandatory is a strange move that has the potential to increase the number of people who don't bother getting a proper certificate for their server, meaning that users will become even more blasé about ignoring the resulting security warnings. This, in turn, would pave the way for more man-in-the-middle attacks.

First, making SSL mandatory, or any encryption for that matter, should not be that strange. I would hope that you would be aware that there exists an argument that all traffic should be encrypted for anonymity and privacy reasons. Secondly, implying that the issue of certificates would be ignored and never solved is itself "strange."

This is "an early-stage research project," so just make a list of the issues that need to be addressed. Why bother imagining what might happen if they aren't resolved?

To article author: The docs explicitly state that SPDY is not a replacement for HTTP, but a layer between it and TCP, and thus that most parts of the application stack will be unchanged and you will still see http:// in your address bar. HTTP is explicitly _not going to be ditched_. Thus the title, subhead, and much of the content of this article are completely misleading. It's not clear how you managed to read the white paper and not grasp this.

I'm not a network guy, but when I started reading this article the first thing that jumped to mind was, "Why not use SCTP?" since it solves the problem of ramping up multiple TCP streams, and allows messages to be delivered out of order. It was nice to see it get a mention at the tail of the article.

Really, I just want to see SCTP become a widely implemented protocol, since it seems so useful, at least based on its feature list.

With the mandatory SSL encryption and gzip compression, SPDY will hit server and client CPUs much harder than traditional HTTP.

Mandatory gzip compression is a GOOD thing. We've been CPU-rich and {everything else}-poor for years now, and CPUs aren't the main power draw in mobile devices anyways (that honour goes to the device screen usually).

With the advent of multi-threaded, multi-core netbook processors, this is only going to get more true as time goes on.

I work with a database technology that has just enabled some form of compression for requests over TCP/IP. Average compression of this data is about 3-4 times.

With text headers, the situation is probably even better (maybe even as high as 10:1).

I'm not suggesting this is a bad thing, I'm simply curious what the 50% figure is in comparison to.

I don't imagine designing some sort of auto-detection capability using request/response headers of initial http requests would be all that difficult.

"Hi, I'm a browser, I want index.html, and oh, by the way, I speak SPDY 1.0"

"Welcome, I'll be your server for this request, here's index.html, and I speak SPDY 1.0 as well on port 443".

As for building this as an extension of http, I don't think so, it's really an entirely different protocol. I imagine one could negotiate and build a SPDY connection using http, and then switch to sending SPDY's binary protocol over the same connection - but that's not really extending http in any meaningful way.

You can already turn on mod_deflate/mod_gzip in apache and get the same sort of effect

mod_gzip / mod_deflate compress the data that your webserver sends back in response to requests. It looks like this protocol is two-way, compressing both the request responses *and* the outgoing requests from your own machine.

Not only is the compression two-way, but the SPDY spec also mentions compressing the request & response headers, which IIRC is not possible in HTTP. With HTTP, only the content can be zipped.

mod_deflate is also two-way, you can apply it as an input filter just like you can an output filter. You're right, in both cases the headers are relied upon to relay the information on whether or not the body is compressed, although headers tend to be rather small in comparison so I'm not sure how much header compression buys us. The big hurdle on two-way compression is, again, web clients that support it.

Ah, Google has no lock-in. They're nothing to worry about. If consumers ditch them for something new, the new guys will slowly have time to ramp up datacenters and Google's effects on non-consumer markets will go away. They're trying to build the only legitimate monopoly, one based on superior products. (Which is legal, by the way.)

Ubiquitous encryption is a bad idea for the reasons the author mentions.

Originally posted by yesno:Ah, Google has no lock-in. They're nothing to worry about. If consumers ditch them for something new, the new guys will slowly have time to ramp up datacenters and Google's effects on non-consumer markets will go away. They're trying to build the only legitimate monopoly, one based on superior products. (Which is legal, by the way.)

Ubiquitous encryption is a bad idea for the reasons the author mentions.

++

And they're not trying to shove proprietary standards down anyone's throat. Not to mention that they open source at least the core of many of their efforts (Chromium, Android, Protocol Buffers, Go, etc).

Originally posted by gruntboyx:wow... Google is just out to re-architect everything.

....whats next TCP/ip ?

Oh my goodness gracious I hope so!!

It is probably responsible for a lot more inefficiency than 50%

I once worked for this company that had a product that involved passing many gigabytes of data around the network. Customers frequently complained about how long it took to see the results of their data. Finally a company genius wrote his own protocol to replace TCP/IP within our software and we saw 10x speed increases. I believe that software is still being used by the company, probably much improved since then.

There are a lot of other ways to speed up web page loading than mucking about in stuff that will take forever to get adopted to the point where you can count on it being used. Case in point, IE 6 was released in 2001, and it's still very widespread.

In the meantime, you can do things like combine css/js files, minify and compress them, and try to use consistent sets of css and js across pages. Images for layout can be sprited, and sprites can be shared across pages. Images for content can have delayed loading, so the important stuff gets loaded first.

I saw no mention of HTTP pipelining. I understand that there are some problems with it that lead to browsers either not implementing it at all or disabling it by default, but can't those problems be fixed?

Originally posted by Sheriff:You mention that SSL content cannot be cached. This is not strictly true, and is by convention rather than by specification. Safari, Firefox, Chrome, Opera don't cache SSL responses to disk by default, but Firefox 3 will if you explicitly set a Cache-control: public header. IE can be told explicitly to cache SSL content.

I would imagine, given that User agents will need to be updated to make spdy requests, there is very little impedance to including explicit directive regarding cache support in the spec. I would highly doubt Google would avoid supporting one of the cornerstones of web scalability.

SSL is also a royal pain in the arse to deliver through any sort of content delivery network (the browser has to talk to a machine which has the SSL certificate, so you have to distribute your SSL certs to all the caches in the CDN (which means your SSL cert is now at much greater risk of compromise.)

SPDY is actually a great idea though I think it should simply be factored into an HTTP/2.0. Browsers could start to implement this support easily, first you'd send a plaintext HTTP header like this...

HEAD / HTTP/1.1[CRLF]Upgrade: HTTP/2.0[CRLF][CRLF]

If the browser sends back

HTTP/2.0 200 OK[CRLF][Other Headers][CRLF]

Then you'd have a valid HTTP/2.0 request and could continue using it. (Remember that a HEAD request is basically the same as a GET requestion without the entity or message body being sent). The entire series of headers and message bodies should be sent as a single compressed stream, so it can be uncompressed and basically parsed like a normal HTTP/1.1 response, though HTTP/2.0 can include some additional headers, such as a request for a port change on the next request, which may be strange for an application protocol, would help against any ridiculous traffic shaping crap that may pop up in the future if net neutrality is broken by mentally defective law makers.

Yes, others have mentioned bzip2 or 7z (lzma). One (or maybe both) of those is supported by Apache (I think), however it still requires client support to be useful. Of course adding such support is trivial anyway. I would expect that unless the standard header Content-Encoding: [encoding type] (usually deflate,gzip or gzip) is used, then the actual data would be sent uncompressed, but still under encryption by SSL. Of course you'd do this for already compressed data, such as a PNG file, where you don't want to waste CPU power compressing already decently compressed data.

HTTP is simple. That why it's used E V E R Y W H E R E. Multiplexing different requests over the same connection ? Do you think that's easy ? If you think it is, I challenge you to write a prototype client/server. Then as an exersice, write a simple HTTP client/server.

WRT HTTP optimization there are many techniques to be tried and yet our browsers come with unoptimal defaults (check Firefox's about:config) and our servers do not support keep-alive.

Also, I think we mess things up by NOT taking into account that HTTP is an APPLICATION LEVEL protocol. Almost on the top of stack. I fail to see how encapsulating something like HTTP into another application layer will help the situation we are into. It's like having a castle made of sand, and then in order to make it more stable, we put in more sand.

HTTP is simple. That why it's used E V E R Y W H E R E. Multiplexing different requests over the same connection ? Do you think that's easy ? If you think it is, I challenge you to write a prototype client/server. Then as an exersice, write a simple HTTP client/server.

WRT HTTP optimization there are many techniques to be tried and yet our browsers come with unoptimal defaults (check Firefox's about:config) and our servers do not support keep-alive.

Also, I think we mess things up by NOT taking into account that HTTP is an APPLICATION LEVEL protocol. Almost on the top of stack. I fail to see how encapsulating something like HTTP into another application layer will help the situation we are into. It's like having a castle made of sand, and then in order to make it more stable, we put in more sand.

Replying to my original post this starts to smell bad. From the Protocol Draft in the chapter Future Work/Experiments:

"It is suboptimal that the browser must discover new hostnames and then look them up in cases where it is fetching new resources controlled by the same entity. For example, there shouldn't be a need to do another DNS lookup for a resource from static.foo.com. when the browser has already resolved xxx.foo.com. In these cases, it would seemingly make sense to send (over the SPDY channel) the DNS data (signed in such a way that the user-agent can verify that it is authoritative)."

I think spdy is a good idea. I like the always encrypted connection idea. Yes, I see problems with man in the middle attack, but the current https doesn't help with that either really (people are already blase about the warnings). But encryption all the time means you traffic is safe from end point to endpoint which is more important to me than a few extra warnings when surfing.

On the question of how to start a spdy connection, why not continue using http for initial page request, but the browser and server switch over to spdy after that initial request? there would be no need to change the way the web works now, because http will still be doing the thing it was originally designed for. spdy can take over from there and finish the downloads/uploads. Just an idea.

You mention that SSL content cannot be cached. This is not strictly true, and is by convention rather than by specification.

I came in here to say this, too. At the very least, most web browsers allow the items to be cached during the browser session, so you are not downloaded logo.png every time you click another page on the same site.

quote:

Are we going to see SPDY:// in URLs rather than HTTP:// ? That wouldn't work with browsers that don't support the new protocol.

Sure it would. You can add URI handlers to your system with ease. On my home PC I can put unreal://1.2.3.4 in my web browser and it will launch UT3 and attempt to connect to that server.

Originally posted by ronelson:Sure it would. You can add URI handlers to your system with ease. On my home PC I can put unreal://1.2.3.4 in my web browser and it will launch UT3 and attempt to connect to that server.

you know, that is actually very cool. is it browser specific, or a system setting?

"Hi, let's use a stateless protocol to to stateful things. And lets make everything unencrypted by default, so security is an immediate concern. And then, we'll re-implement all of our existing protocols using HTTP for encapsulation (MAPI turns into OWA HTTP, Usenet turns into RSS, IRC turns into Twitter), so we make things even more inefficient."

So, anything that shakes up this "let's do everything with HTTP" mentality is a good thing in my opinion.