mark nottingham

Will HTTP/2.0 Happen After All?

Friday, 13 November 2009

HTTP

A couple of nights ago, I had a casual chat with Google’s Mike Belshe, who gave me a preview of how their “ Let’s make the Web faster” effort looks at HTTP itself.

SP DY (nee FLIP) is an alternate application protocol that’s in Chromium, but buried so deeply that you have to enable it with a command-line option (—use-flip). AFAICT there aren’t even any public servers that support it yet, but it’s still a very exciting development.

Why? In a nutshell, it’s a binary, frame-based protocol for multiplexing bidirectional data streams over TCP (to start with). See flip_protocol.h for an idea of what it looks like, as well as the whitepaper.

HTTP’s Limits

HTTP-over-TCP has some pretty basic limits; most seriously, you can practically only have one request or response in flight on a connection at the same time.

Pipelining was designed to alleviate this, but at best it’s only a partial fix ( head-of-line blocking is still an issue), and implementation problems means it’s almost unusable on the open Web (although Serf has had success in using pipelining in Subversion). It also can’t be used for methods like POST, which is important for interactive applications.

This drives people to use multiple, parallel TCP connections — something that we’ve accommodated in HTTPbis by lifting the two-connection limit for clients. However, that’s not a great solution either; TCP doesn’t allow you to share connection state between them, which brings problems when dealing with congestion.

What about WAKA?

These problems are well-known and have been discussed for years, all the way back to HTTP-NG, WebMUX and other efforts. More recently, Roy Fielding has been working behind the scenes on WAKA, with similar goals. So similar that I had to smile when Belshe explained what they were doing; it’s very similar to how Roy explains WAKA’s use of the transport.

However, I wouldn’t say that SPDY is competing with WAKA — yet. Belshe goes out of his way to point out that SPDY is more about doing real-world experimentation rather than saying “this is the protocol we’ll use.” In his words;

We’re hoping to put theories to the test; while many of the ideas are not new, we’re aggregating them, making them cooperate together, implementing them, and then measuring them. We hope that others will appreciate and expand this effort so that we can all evolve toward a protocol we think is universally better in a relatively quick timeframe.

In other words, they seem to be positioning this as input to the eventual design of HTTP/2.0, WAKA or whatever, rather than a browser-specific push to define a new protocol alone.

… and the IETF

The other interesting aspect, of course, is the relationship to WebSockets, especially since there was a pretty strong sense in the IETF earlier this week in Hiroshima that a Working Group to standardise it should be started. if SPDY really does eventually follow the path of WAKA, it could be that some HTTP-like use cases that people have planned for WebSockets may have another outlet instead.

Finally, you might ask what bearing this has on our efforts in HTTPbis. Right now, the answer is “nothing”, in that we’re chartered explicitly NOT to create a new version of HTTP. However, I think that our work — especially in splitting up the spec (a decision driven by Roy a long time ago) — will help any eventual successor protocol, whether it be WAKA, SPDY, their child or something completely different.

That’s because the minimum bar to entry for replacing HTTP/1.1 is to exactly support its semantics and capabilities, while making it more efficient. The fact that all of the wire-level goop in HTTP is now moving to a single, separate document helps that.

The last thing that I’d mention is that when we started HTTPbis a couple of years ago, there was a strong sentiment against creating a new protocol, both because of the can of worms it would open, and because of deployment problems in doing so. However, I’ve recently heard many people complaining about the limitations of HTTP over TCP, and it seems that one way or another, we’re going to start tackling that problem soon.