Re: SPDY = HTTP/2.0 or not ?

In message <B0FA4BA7-91AE-46DA-89C5-85B6978D865E@mnot.net>, Mark Nottingham wri
tes:

>What do you want from "multi-protocol" -- is it "protocol independence"?

No, it is software quality, and solution performance.

With respect to software quality, there should be no need to read all
333 pages of HTTPbis output, just to find out what it takes to move
a message across the wire.

Having "transport message definition" separated from "message
semantics interpretation" means that designing and debugging both
sides of that (virtual) API becomes much easier.

The HTTPbis effort have made it easier to spot the line where it
exists, but it is still hidden in old dirty hacks a lot of places.

Even if we end up with only one protocol defined, having the interface
between transport and semantics clearly defined will make that job easier.


As for performance, Varnish has users who are starting to knock on
the underside of one million requests a second per machine, at these
levels of trafic, neither SSL nor CRNL terminated text formats play
well with the SOCKET-API for pulling stuff out of TCP connections.

Just to give an idea about the kind of numbers we are talking about,
I think HTTP/2.0 should have a performance goal for one of its
transports, that a COTS machine can run a (load-balancer) at
wire-speed for 500.000 clients, with less than 5% CPU usage.  Given
that we'll take a couple of years, this may be too unambitious.

So, what I would really like to see come out of HTTPbis is four
standards, (each of which might be one or more documents):

	HTTP/2.0 semantics:
		Defines what HTTP/2.0 messages mean. 

		(Ie: GET, POST, Vary, E-tags, Sessions, Cookies...)

	HTTP/2.0 transport requirements:
		Defines the message components and the primitives a
		transport protocol must/can support.

		(Ie: http_req is {req,proto,metadata*,data+}, endpoint
		identification/X-F-F etc.)

	HTTP/2.0 high performance bulk transport
		Transport for moving lots of bits fast.

		(Ie: HTTP/1.1 with length-prefixes and maybe metadata
		enumeration/compression. No-RTT penalty HTTP/1.1
		upgrade by sending first request as HTTP/1.1 with
		"I can do HTTP/2.0" marker.  Maybe pipelining/mux
		to fill windows) 

	HTTP/2.0 full feature transport
		Transports for fancy HTTP apps which needs server
		push, websockets, mux, pipeline, crypto (Ident,
		Auth, Priv, Integ, non-repudiation etc.)

		(Ie: Probably something like a fuller marriage of
		SPDY and HTTPS, switching to this protocol with
		"UPGRADE" is probably perfectly acceptable.)

And this is why I think that the second document is much more
important to focus on right now, than specifying SPDY without having
specified where ind what it plugs into.

-- 
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 Sunday, 25 March 2012 14:18:43 UTC