> Hi. > > Is it possible, and if not is planned, to allow haproxy to be > configured to retry connections on receiving RST and not just timeout? > > Linuxes drop the SYN if the listen socket is overflown, but can return > RST if configured so. IMHO, it's better to RST because then you know > that SYN is lost anyway, so there isn't a point to wait until the > timeout. However, haproxy just issues 502 in this case right away, even > though there is a good chance that next attempt will succeed.
Actually, Linux doesn't drop the SYN, but the ACK packet (when tcp_abort_on_overflow is 0), which gives the client the chance to retry [1]. I don't think a RST can ever by interpreted as: retry again right now. Setting tcp_abort_on_overflow to 1 therefor seems counterproductive in your case. Enabling tcp_abort_on_overflow and making the client (haproxy) retry on RST seems even more counterproductive and will effectively auto-DoS your service. I would rather tune backlog on the backend, configure the backends maxconn as per its capabilities and make sure server-side keep alive is enabled. Regards, Lukas [1] http://veithen.github.io/2014/01/01/how-tcp-backlog-works-in-linux.html
