Re: multiplexing -- don't do it

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
show:

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


Best regards
  Tom

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
>
>
>