Hi, > Le 14 sept. 2017 à 19:34, Lukas Tribus <lu...@gmx.net> a écrit : > > Hello, > > > Am 05.09.2017 um 10:00 schrieb Willy Tarreau: >> >> As I already mentionned (I don't remember to whom), I really don't see *any* >> benefit in this approach and only problems in fact. By the way, others have >> attempted it in the past and failed. > > I agree, when we are talking about the haproxy use case (which is > always network to network). > > I do find the combination between sendfile and ktls is very interesting > though, for web servers that are waiting for the disk, especially > event-loop based software like nginx. > > > For haproxy on the other side symmetric crypto performance is not the > problem; asymmetric crypto performance (the handshake) is, because it > it is blocking the event-loop. > > Pushing the handshake to worker thread(s) is a possible solution to this, > and I guess would probably eliminate the main reason people have to use > nbproc > 1 today. >
This is an excellent improvement. And traffic for established connections is no longer disturbed by handshake. > I believe this was discussed before and is indeed something Willy has > on his mind. I think is the case with ssl-mode-async in 1.8. It depend on openssl-version. I hope this will be generalisable in a native async HS. > > How difficult the OpenSSL API makes this, I'm not sure. The documentation > certainly leaves "room for improvement" in regard to threading: > > https://www.openssl.org/blog/blog/2017/02/21/threads/ > <https://www.openssl.org/blog/blog/2017/02/21/threads/> > https://github.com/openssl/openssl/issues/2165 > <https://github.com/openssl/openssl/issues/2165> > > ++ Manu
