W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: The HTTP vs SPDY debate

From: Willy Tarreau <w@1wt.eu>
Date: Sat, 31 Mar 2012 08:58:20 +0200
To: Mike Belshe <mike@belshe.com>
Cc: ietf-http-wg@w3.org
Message-ID: <20120331065820.GK14039@1wt.eu>
Hi Mike,

On Sat, Mar 31, 2012 at 12:32:04AM +0200, Mike Belshe wrote:
> > I'm not talking about having *multiple* experimental specs,
> > just one stable standard and one experimental from which the next standard
> > will be built. This is exactly what is happening right now, and you know
> > too well that it will not stop here !
> >
> I'm pretty familiar with what the browsers do, and they don't do this :-)
> So I must be misunderstanding what you mean.

OK, I'll try to explain below (long version). Too bad we didn't have more
time to discuss this on thursday!

> If you're talking about how a feature goes from dev channel to beta channel
> to release channel in chrome,  thats true.  But its not used the way I
> thought you were asking it to be used - features don't stay locked at one
> level - they either get rolled into the next version (which is ~3 weeks
> apart!) or they get kicked out.  In other words, all features are always on
> path to get shipped within ~10weeks.

Interesting, but I'm not talking about having features in experimental
browser versions but experimental protocols in browsers. Right now, SPDY
is evolving. Maybe you'll say that it has reached a stable point, but
anyway given all the things we discussed about on Thursday, I'm pretty
sure that you won't stop there, and that new versions will appear and
will be adopted by browsers :-)

So at the moment we have HTTP as the legacy protocol and SPDY as a new
protocol, adopted by some websites and some browsers willing to accept
a few changes if/when the protocol becomes the new legacy protocol.

What this means to me is that it's more or less a matter of "regularly"
(I mean every few years maybe) rebasing HTTP on the latest stable SPDY
spec to ease integration of new features.

What I'm observing is that right now there are two maint points in SPDY :
  - improve HTTP and work around a number of its current shortcomings ;
  - improve/secure the transport layer

The first point is a strong one which all 4 proposals identified as a
"must be fixed". The second point is probably where SPDY is the most
advanced at the moment eventhough as you suggested, it clearly targets
end users and does not necessarily bring any specific value to webservices
or such usages.

At the moment, SPDY is more or less HTTP/1.1 + MUX + an improved transport
layer. And I have a number of reasons to think that the transport layer
will be the place which will get the most changes in the future due to
its current limitations in mobile environments, and because of the way
mobile applications are evolving (less web, more json).

So what I'm saying is that we really need two things for HTTP :

   - fix some of the 1.1 design issues that we all hate (metadata weight,
     parsing complexity, in-order delivery, etc...). We need to address
     these issues at once for a long time (probably as long as 1.1 has
     lived) so that 2.0 can become the legacy protocol for everything as
     1.1 currently is ;

   - define a way to improve transport for a number of evolving usages
     and to be able to easily plug new transport mechanisms that are
     being experimented (which might include registering new schemes
     or field values to exchange information between layers).

The first point is in line with the WG's charter. The second point is
around all the research you guys have been (and are) doing. At the moment,
we know that people are using HTTP over a few different transport layers
and that it works pretty well, meaning that HTTP currently is transport
agnostic (SSL/TLS is often offloaded by front gateways, UNIX-stream is
regularly used for inter-process communication in the same host, and UDP
is used as a transport layer in UPNP).

By keeping the HTTP core independant of the transport layer, we can
regularly bring new transport combinations on the table, and if some of
them require minor improvements to the protocol, these changes can lead
to a new revision of the protocol. Want HTTP over TLS over TCP ? trivial.
Want HTTP over DTLS over UDP ? Some adaptations might be needed but at
least we'd have the HTTP core ready for this. Want HTTP over two different
channels for people using satellite links so that meta-data passes over
the wire and entities pass over the air ? Create a new transport layer.
Want HTTP to pass over a new to-be-defined streaming secure transport
protocol ? Just change the lower layer again.

In fact, even the flow control is transport-specific. Seeing how many
flow control algorithms there are for TCP depending on whether you use
a slow link, a long fat pipe, a big local pipe etc... it would make
sense to have the transport layer take care of this and take the latency
and underlying buffers into account.

The transport layer is where I expect a lot of activity in the coming
years, and having a stable and efficient protocol base for this would
make experimentations and deployments very easy by the simple addition
of transport layer gateways. Then maybe we can standarize a new transport
layer every year or two and expect them to be quickly adopted because it's
cheap and provides real benefit. For instance, let's say that a company
develops a WiFi-to-WiMax gateway to provide connectivity to small villages.
Users will probably use TLS+TCP to the local gateway and the gateway might
at one point prefer to use a new layer more suited to WiMax than what we
have. Then it's important to make them able to standardize what they're
using and that it's transparent to the end user.

But I also know that some improvements will be transport-independant and
will be worth backporting into the spec (server push maybe, or new auth
schemes). So maybe 1 year after 2.0 will be out, a number of shiny new
features will be ready and new transport protocols will require minor
adaptations and it will be time to issue 2.1 to benefit from all of this
in the standard protocol.

Received on Saturday, 31 March 2012 06:59:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:01 UTC