RE: retry on RST

[Lukas Tribus]

 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

  

retry on RST

[Pawel Veselov]

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.

Thanks,
  Pawel.