Re: The HTTP vs SPDY debate

I thought the goal was to figure out HTTP/2.0; I hope that the goals of
SPDY are in-line with the goals of HTTP/2.0, and that ultimately SPDY just
goes away.

Mike


On Thu, Mar 29, 2012 at 2:22 PM, Willy Tarreau <w@1wt.eu> wrote:

> Hello,
>
> after seeing all the disagreements that were expressed on the list these
> days (including from me) about what feature from SPDY we'd like to have
> mandatory or not in HTTP, I'm thinking that part of the issue comes from
> the fact that there are a number of different usages of HTTP right now,
> all of them fairly legitimate.
>
> First I think that everyone here agrees that something needs to be done
> to improve end user experience especially in the mobile networks. And
> this is reflected by all proposals, including the http-ng draft from
> 14 years ago!
>
> Second, the privacy issues are a mess because we try to address a social
> problem by technical means. It's impossible to decide on a protocol if
> we all give an example of what we'd like to protect and what we'd prefer
> not to protect because it is useless and possibly counter-productive.
>
> And precisely, some of the disagreement comes from the fact that we're
> trying to see these impacts on the infrastructure we know today, which
> would obviously be a total breakage. As PHK said it, a number of sites
> will not want to afford crypto for privacy. I too know some sites which
> would significantly increase their operating costs by doing so. But
> what we're designing is not for now but for tomorrow.
>
> What I think is that anyway we need a smooth upgrade path from current
> HTTP/1.1 infrastructure and what will constitute the web tomorrow without
> making any bigbang.
>
> SPDY specifically addresses issues observed between the browser and the
> server-side infrastructure. Some of its mandatory features are probably
> not desirable past the server-side frontend *right now* (basically
> whatever addresses latency and privacy concerns). Still, it would be
> too bad not to make the server side infrastructure benefit from a good
> lifting by progressively migrating from 1.1 to 2.0.
>
> What does this mean ? Simply that we have to consider HTTP/2.0 as a
> subset of SPDY or that SPDY should be an add-on to HTTP. And that
> makes a lot of sense. First, SPDY already is an optimized messaging
> alternative to HTTP. It carries HTTP/1.1, it can as well carry HTTP/2.0
> since we're supposed to maintain compatible semantics.
>
> We could then get to a point where :
>  - an http:// scheme indicates a connection to HTTP/1.x or 2.x server
>  - an https:// scheme indicates a connection to HTTP/1.x or 2.x server
>    via an SSL/TLS layer
>  - a spdy:// scheme indicates a connection to HTTP/1.x or 2.x server
>    via a SPDY layer
>
> By having HTTP/2.0 upgradable from 1.1, this split is natural :
>
>        +----------------------------+
>        |       Application          |
>        +----+-----------------------+
>        | WS |     HTTP/2.0          |
>        +----+--------------+        |
>        |      HTTP/1.1     |        |
>        |         +-----+---+--------+
>        |         | TLS | SPDY       |
>        +---------+-----+------------+   server-side
>            ^        ^        ^
>            |        |        |
>            |        |        |
>            |        |        |
>        +---------+-----+------------+  user-agent
>        |         | TLS | SPDY       |
>        |         +-----+-------+----+
>        |  HTTP/1.1, 2.0        |    |
>        +-------------------+---+    |
>        |                   |   WS   |
>        |  Applications     +--------+
>        |                            |
>        +----------------------------+
>
> The upgrade path would then be much easier :
>
>  1) have browsers, intermediaries and servers progressively
>     adopt HTTP/2.0 and support a seamless upgrade
>
>  2) have browsers, some intermediaries and some servers
>     progressively adopt SPDY for the front-line
>
>  3) have a lot of web sites offer URLs as spdy:// instead of http://,
>     and implement mandatory redirects from http:// to spdy:// like a
>     few sites are currently doing (eg: twitter)
>
>  4) have browsers at some point use the SPDY as the default scheme
>     for any domain name typed on the URL bar.
>
>  5) have browsers at one point disable by default transparent support
>     for the old http:// scheme (eg: put a warning or have to tweak
>     some settings for this). This will probably 10-20 years from now.
>
> Before we get to point 5, we'd have a number of sites running on the
> new protocol, with an efficient HTTP/2.0 deployed at many places
> including the backoffice, and with SPDY used by web browsers for
> improved performance/privacy. That will not prevent specific agents
> from still only using a simpler HTTP/2.0 for some uses.
>
> So I think that what we should do is to distinguish between what is
> really desirable to have in HTTP and what is contentious. Everything
> which increases costs or causes trouble for *some* use cases should
> not be mandatory in HTTP but would be in the SPDY layer (as it is
> today BTW).
>
> I think that the current SPDY+HTTP mix has shown that the two protocols
> are complementary and can be efficient together. Still we can significantly
> improve HTTP to make both benefit from this, starting with the backoffice
> infrastructure where most of the requests lie.
>
> Willy
>
>
>