Responding 444 is... a response. It is not anything else than a (non-standard, thus 'unknown', just like 499 nginx chose to illustrate client-side premature disconnection) HTTP status code as any other. Some speedup might come from using return instead of doing further processing, but there is still a connection, data sent, data processed and response sent. Basically resources are being burned up and not available for another request/client.
HTTP status code do not do anything by themselves, they are just part of a protocol legitimate clients implement. I do not think attackers care much about status code other than what they guess about the server. In case of DoS, your only hope is to divert/absorb the flow. Blabbering about status codes as a potential solution to DoS shows deep misunderstanding of what is being discussed and is pure nonsense. --- *B. R.* On Tue, Sep 27, 2016 at 6:44 PM, <li...@lazygranch.com> wrote: > I pulled this off the rate limiting thread since I think the 444 return is > a good topic all on its own. > > "But under a DoS attack I always feel those values would be better being > "444" since the server won't respond and cut's the connection rather than > waste bandwidth on a client who is opening and closing connections fast as > a > bullet." > > Looking at the times in my nginx access.log, I don't believe any > connection is cut. Rather nginx just doesn't respond. A browser will wait > an appropriate amount of time before it decides there is no response, but > the code from the hackers just keeps hammering the server. > > What I don't know is if the 444 return effects the nginx rate limiting > coding since you have effectively not returned anything, so what is there > to limit? > > The experiment would be to hammer your webserver from the server itself > rather than over the Internet, and see if it does get rate limited. That > would take network losses out of the picture. > > When I get a chance, I'm going to pastebin the logs from that attack I got > from the Hong Kong server so the times can be seen. > > _______________________________________________ > nginx mailing list > nginx@nginx.org > http://mailman.nginx.org/mailman/listinfo/nginx
_______________________________________________ nginx mailing list nginx@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx