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:15:02 +0800
Message-ID: <CAEXHaupr1qdjrmWvh7if79ViHWinF6HEkA6Rgpcsc8RfZZhKhg@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
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
>>
>>
>>
>


Received on Saturday, 7 April 2012 14:15:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:59 GMT