On Mon, Mar 06, 2017 at 06:34:09PM -0800, Steven Davidovitz wrote: > Interestingly, as far as I can tell, we are running into the problem > described in this forum post: > http://discourse.haproxy.org/t/backend-encryption-and-reusing-ssl-sessions/503/4 > Switching the conn_data_shutw_hard call to conn_data_shutw in checks.c > decreased CPU usage completely. Forcing SSLv3 as in this email ( > https://www.mail-archive.com/haproxy@formilux.org/msg09105.html) also > worked.
This is very interesting! The problem with not using conn_data_shutw_hard() is that conn_data_shutw() will only *try* to notify the other side about an imminent close but at the same time we're going to close with SO_NOLINGER resulting in the close notification to be lost in the middle. And not using SO_NOLINGER is not an option as we can end up with tons of TIME_WAIT sockets on haproxy which clearly is not acceptable. But more importantly it means that we probably have a similar problem with production traffic if you don't use persistent connections to the server. But now I'm thinking about something, I'm wondering if in fact it would not be the lack of call to SSL_shutdown() which causes the connection not to be kept in haproxy's SSL context. In 1.8-dev this function changed a bit so that we first call SSL_set_quiet_shutdown() then SSL_shutdown(). > I haven't had time to dig further, and it may certainly be client > misconfiguration, but could you shed any light on why that might be a > problem? It might be useful to use another haproxy after the checks instead of your server to see if you observe the same effect. And if you can run a test with 1.8-dev it would be great. I'd rather backport just the change to ssl_sock_shutw() to 1.7 if it fixes the problem :-) BTW, given that only the checks are causing the trouble it's easy to start an independant process for this. Just change all bind addresses and let the backends run their checks to see the effect. Willy
