- From: Adrien de Croy <adrien@qbik.com>
- Date: Tue, 21 Jun 2011 10:05:49 +1200
- To: Willy Tarreau <w@1wt.eu>
- CC: Poul-Henning Kamp <phk@phk.freebsd.dk>, Jan Starke <jan.starke@outofbed.org>, ietf-http-wg@w3.org
I think the inference was that some servers will struggle to provide service to others when they maintain 30.000 idle connections. But in the end, I don't see any real difference between sending the POST or even just sending nothing. The server will have some sort of timeout. It might be a different timeout used for waiting for anything vs waiting for a completion of a POST message body. but I think the timeout in general will be long enough for many connections to have been initiated. Things that mitigate that are features like connection rate limiting (per source IP), per-IP overall concurrent connection limits etc. Adrien On 21/06/2011 9:56 a.m., Willy Tarreau wrote: > On Mon, Jun 20, 2011 at 09:41:10PM +0000, Poul-Henning Kamp wrote: >> In message<20110620211911.GL2897@1wt.eu>, Willy Tarreau writes: >>> On Mon, Jun 20, 2011 at 05:03:32PM +0000, Poul-Henning Kamp wrote: >>>> There is no possible timeout value which will both serve slow clients >>>> in bad connectivity (iPhone4 ?) and prevent DoS attacks. >>> Yes in practice you can because even with bad connectivity you're generally >>> interested by covering holes as large as 30-60 seconds, >> Well your sever may not crash, but it does not serve legitimate >> traffic either. > I'm sorry, I don't see your point. Why are you saying that the server does > not serve legitimate traffic ? It will only break the dead connection but > still serve all other ones well, that's the point of timeouts. > > Also that's why some protocols with very long sessions implement an > application-level keep-alive (eg: SSH). That way it's possible to have > reasonable timeouts (eg. twice the keep-alive interval) without keeping > dead connections forever. > > Willy > > -- Adrien de Croy - WinGate Proxy Server - http://www.wingate.com WinGate 7 beta out now - http://www.wingate.com/getlatest/
Received on Monday, 20 June 2011 22:06:26 UTC