Hi. On Mar 16, 2016 10:06 PM, "Willy Tarreau" < > > 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). >
While that would help a single server, how about when dealing with multi servers + anycast: Has there been any thoughts about sharing ssl/tls session cache between servers? Like how apache can use memcache to store its cache or how cloudfare used/patched openresty to do the same recently. > 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 > >
