Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

In message <4F4E89B5.1000606@qbik.com>, Adrien de Croy writes:

>So what would we do?  We can either
>
>a) specify a different protocol for this environment
>b) make the encryption and compression be optional and then just use the 
>same protocol.

>(a) makes no sense.

Actually, I think (a) makes a lot of sense.

That it one of the main reasons why I think we should not focus on
SPDY, but rather on getting a clean and modular transport/semantics
split which will allow us to have multiple transport protocols with
different properties.

There is an ocean between the desired protocol properties for a
porn site, a news media, a daytrader and a webbank site.

Trying to use a once-size-fits-nobody model to bridge that span is
exactly why we are talking about HTTP/2.0 in the first place.

At the very minimum, there is a need for two different transport
protocols:

1. Bulk (focus on bw/latency/load)

2. Cryptographically protected (focus on auth/priv/ident)

Which is why we have HTTP and HTTPS today.

SPDY tries to be both, and adds server push and various other bells
and whistles on top, and as others have commented, Moores law is
not enough to make that feasible for high-volume sites.

I think any attempt to have just one transport protocol runs into
so many conflicting demands that implementing X.40? in INTERCAL
will seem like a nice project to relax with, and a successful
transition period only slightly longer than IPv6 is almost guaranteed.

I think HTTP/2.0 should expect to have at least four transport
protocols:

a) HTTP/1.x for backwards compatibility

b) HTTP/2.0 Bulk mode (smaller headers, possibly mux/pipeline)

c) HTTP/2.0 Crypto (or possibly HTTPS unchanged to avoid recertification)

d) HTTP/2.0 Bells&Whistles (server push, websockets, RPC etc.)

SPDY may be a candidate for d), but it sure as hell isn't for b).

To what extent c) and d) can be combined I will not venture an opinion.
I will note that deployment of a HTTPS replacement involves a lot of
paperwork and in some cases regulatory action.

So can we please stop this one-eyed focus on SPDY, and start looking
at how we accomodate multiple transport protocols in a sensible manner ?

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Wednesday, 29 February 2012 20:51:11 UTC