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

Re: multiplexing -- don't do it

From: tom <zs68j2ee@gmail.com>
Date: Sat, 7 Apr 2012 22:11:11 +0800
Message-ID: <CAEXHaupGTiM7KKpQU68QRq2_S0ZX2p+BaS5mpA4-=S5YokbkNg@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Mike Belshe <mike@belshe.com>, Nicolas Mailhot <nicolas.mailhot@laposte.net>, "William Chan (?????????)" <willchan@chromium.org>, ietf-http-wg@w3.org, jaguar xiong <xiong.jaguar@gmail.com>, Salvatore Loreto <salvatore.loreto@ericsson.com>, iwebpp@googlegroups.com
Hi Guys:

we studied on HTTP over UDP two years and implemented HTTPP scheme to run
HTTP over UDP on firefox.

attachment is HTTPP extension for firefox-11.0 on Win7.
once install it, if type
httpp://www.iwebpp.com:3000/<http://www.iwebpp.com/>will show:

Hello, iWebPP:
	This is Tom calling to Jagua from UDP.:)

and, when type http://www.iwebpp.com:3000/ <http://www.iwebpp.com/> will

Hello, iWebPP:
	This is Tom calling to Jagua from TCP.:)

Best regards

On Sat, Apr 7, 2012 at 3:37 AM, Willy Tarreau <w@1wt.eu> wrote:

> Hi Mike,
> On Fri, Apr 06, 2012 at 03:34:46PM +0000, Mike Belshe wrote:
> > Once again - the people arguing against encryption are the people that
> want
> > to exploit the user's data transmission stream for their own personal
> gain.
> I disagree with your view here. I'm against mandatory encryption because
> there
> are many places where it's not *needed* (eg: in the backoffice). And
> having two
> different protocols for the same thing seems like the wrong solution to me,
> while the model we currently have where HTTP is the framing protocol which
> uses a transport whether it's encrypted or not ensures that encryption is
> used
> only where appropriate.
> Also, I know you disagree with me on the point of the performance cost,
> but I
> have some haproxy users forwarding 10 Gbps of data 24*7 on a single
> machine by
> relying on TCP splicing which consists in avoiding memory copies. These
> data
> are files exchanged between some hosts and that are encrypted/decrypted on
> the
> user's PC, which means that encrypting the transport just adds a useless
> second
> encryption. You can forward at 10 Gbps right now on a single machine
> between 25
> and 50% CPU. By simply switching from splice() to recv()+send(), you
> double the
> CPU consumption. By adding decryption and encryption on top of that, you
> always
> add more work than just recv()+send(), even if you're using crypto
> accelerators
> etc... Forcing these services to apply encryption to data that are already
> stored encrypted and resulting in a significant increase in infrastructure
> costs is not going to help HTTP2 adoption at all, instead it will fragment
> the
> web.
> As we discussed last week, I'm sure that once we get HTTP to work over UDP,
> it will be much cheaper to perform point-to-point encryption because it's
> much cheaper to offload datagram encryption than stream encryption
> (basically
> the NICs will do it for free). But doing encryption over TCP is expensive,
> at
> least as much as several memcpy() of the same buffers, which precisely is
> what
> we try to avoid as much as possible at high bit rates.
> > If we want the Internet to be protect users - encrypt it.
> Remember again, right now people who lose money on their bank account on
> the Internet are already using end-to-end encryption. The issue has much
> more to do with malware running on their host, and fortunately the issue
> is less important in corporate networks because these malware are not
> commonly allowed to communicate to the C&C server over HTTPS there !
> If you want to protect internet users, do your best to stop malware !
> > It's a simple choice:  users vs interceptors.
> Interceptors are bad but they exist right now in part because of the lack
> of ability to securely connect to a mandatory proxy. This certainly needs
> to be addressed. They also exist because at some places it's not easy to
> deploy a proxy configuration (eg: your smartphone might not support having
> one in 3G, so your operator installs an accelerator to "improve" your
> browsing experience).
> We need to think why something which currently is an opt-in isn't proposed
> to end users before trying to block the features that people had to invent
> to solve this issue in the dirtiest way. Otherwise we'll fail again and
> we'll see them invent even dirtier tricks to get the work done.
> Regards,
> Willy
Received on Saturday, 7 April 2012 14:11:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:00 UTC