Hi Christian,

On Wed, Mar 16, 2016 at 05:25:53PM +0100, Christian Ruppert wrote:
> Hi Lukas,
> 
> On 2016-03-16 16:53, Lukas Tribus wrote:
> >>The "option httpclose" was on purpose. Also the client could (during a
> >>attack) simply do the same and achieve the same result. I don't think
> >>that will help in such cases.
> >
> >So what you are actually and purposely benchmarking are SSL/TLS
> >handshakes, because thats the bottleneck you are trying to improve.
> 
> You're right, yes.

You also found the hard way why it's important to share TLS secrets
between multiple front nodes, or to properly distribute the load to
avoid handshakes as much as possible.

> >Both nginx [1] and haproxy currently do not support offloading TLS
> >handshakes to another thread or dedicating a thread to a TLS session.
> >
> >Thats why Apache will scale better currently, because its threading.
> 
> Hm, I haven't tried Apache yet but would that be a huge benefit compared to
> a setup using nbproc > 1?

Here I don't know. TLS handshakes are one large part of what made me think
that we must go multi-threaded instead of multi-process over the long term,
just because I want to be able to pin some tasks to some CPUs. Ie when TLS
says "handshake needed", we want to be able to migrate the task to another
CPU to avoid the huge latency imposed to all other processing (eg: 7ms in
your case).

But note that people who have to deal with heavy SSL traffic actually
deal with this in haproxy by using to levels of processing, one for
HTTP and one for TLS. It means that only TLS traffic can be hurt by
handshakes :

   listen secure
        bind :443 ssl crt foo.pem process 2-32
        mode tcp
        server clear 127.0.0.1:80

   frontend clear
        bind :80 process 1
        mode http
        use_backend my_wonderful_server_farm

   ...

And before linux kernel reintroduced support for SO_REUSEPORT (in
3.9), it was common to have the single process load-balance incoming
TCP connections to all other TLS processes. It then makes it possible
to chose the LB algo you want, including source hash so that a same
attacker can only affect one process for example.

Willy


Reply via email to