Re: multiplexing -- don't do it

attach HTTPP firefox-11.0 win7 extension.

On Sat, Apr 7, 2012 at 10:11 PM, tom <zs68j2ee@gmail.com> wrote:

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