W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: A proposal

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Wed, 20 Nov 2013 00:41:17 +0000
To: "Adrien de Croy" <adrien@qbik.com>
cc: "Zhong Yu" <zhong.j.yu@gmail.com>, "Nicolas Mailhot" <nicolas.mailhot@laposte.net>, "Mike Belshe" <mike@belshe.com>, "Roy T. Fielding" <fielding@gbiv.com>, "HTTP Working Group" <ietf-http-wg@w3.org>
Message-ID: <41025.1384908077@critter.freebsd.dk>
In message <em2e0e431f-78f3-4127-8994-938562a8e560@bodybag>, "Adrien de Croy" w
rites:

>It's interesting to play out the scenario from a server vendor
>perspective.

For all practical purposes I am a server vendor.

The fact that Varnish picks contents to deliver via HTTP rather
than NFS is not really material in this context.

Varnish has two nondistinct user-populations:  People who need bits
showelled out fast and people who need to do weird stuff to their
HTML on the way out, sometimes to fix up stuff the backend can't,
but mostly in order to make the shovelling happen even faster.

Typical Varnish bragging right now, is that people shovel 10-30
GBit/sec HTTP per server.

Yes, there are calls for encryption, but people in my user segment
generally see encryption as the antithesis to performance, and they
mainly ask for it, because they think it will be easier to manage
if they have it all in one place.

Four dudes enjoyed a bit of fun at EuroBSDcon on Malta recently.

Representing NetFlix, ManWin, Nginx and Varnish, we are involved
in an awful lot of the HTTP bits on the net, something like every
two out of three bits, the vast majority without any encryption[2].

Needless to say, I don't speak for those other three guys, nor for
that matter do I speak for Varnish users.

My impression is that if we're going to make it hard, procedurally
or politically, to run HTTP/2.0 without the overhead of encryption,
an awful lot of these people will just not bother with HTTP/2.0.

Newspapers and their readers don't care to keep it secret that
they're checking what Miley Did Last Night, and the very few who
do care, will go through TOR.

The Danish Weather Service don't want to waste time and CPU power
authenticating anybody, when half of Denmarks population presses
"Reload" ever few seconds during a storm[1].

Whitehouse.gov *want* people to see the picture of the veggies in
the garden, and if somebody MITM's them, they will deal with it
"out-of-band" so to speak.

And porn sites are all about authenticating the user, not their own
servers, and they certainly don't want the overhead of any crypto
protocol for the actual pink bits.

Cryptography does nothing but hurt these sites business case, and
their users loose no privacy, that's not already surrendered by the
fact that bytes go from IP#1 to IP#2.

If you want to get these sites onboard, it's really very simple:
HTTP/2.0 has to be better for them than HTTP/1.1.

My prediction is that a TLS handshake before first object is unlikely
to be considered "better" and the added CPU load from encrytion is
not going to make anybody happy either.

If you think you can convince them otherwise, be my guest.

On the other hand, if we make a better HTTP/2.0 available on a
dedicated port, so we don't even waste RTTs on some UPGRADE kabuki
dance, a single release of Nginx and Varnish will make a LOT of
HTTP bits available for HTTP/2.0

And in that situation, I don't expect any browser will have necessary
glands to stick to any high horse position about mandating TLS
everywhere:

One does not simply walze away from news and porn.[3]

Poul-Henning

[1] Yes, that is kind of pathetic, but that seems to be what
people do in Denmark during stoms:
	http://www.dmi.dk/nyheder/arkiv/nyheder-2013/10/laeserne-susede-til-dmidk-under-orkanen/

[2] DRM is a different layer and not relevant here.

[3] Hottest thing in hipster-technology: Memes without pictures.

-- 
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, 20 November 2013 00:41:43 UTC

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