patch proposal
Vladislav Shabanov
vlad.shabanov at gmail.com
Fri Apr 8 08:19:17 UTC 2016
Привет!
Если так письмо на русском не примете, я его, конечно, переведу на английский, но хотелось бы чуть-чуть времени сэкономить :)
Итак, имеем сервер, на котором
limit_req_zone $whitelisted_remote_addr zone=IPRATELIMIT_EXT_GET:20m rate=30r/s;
Всё как положено, есть белый список IP-адресов, остальные считаем плохими.
Там где идёт проброс запроса до fastcgi-сервера, есть
limit_req zone=IPRATELIMIT_EXT_GET burst=15;
Стандартный сценарий обращения нового посетителя к сайту:
1) GET /?fr=откуда_пришёл&foo=bar
Ему в ответ выставляют cookie fr с этим значением и отдают redirect на /?foo=bar
Редирект работает очень быстро и почти не грузит сервер.
2) GET /foo=bar
в этот момент браузер получает замедление из-за limit_req, слишком быстро спрашивает. Эти замедления никому не нужны, ни от чего не защищают.
Можно поставить nodelay, но тогда слишком активные боты не будут получать задержек и ситуация будет доходить до выдачи им ошибки 503.
Таким образом, мне нужно, чтобы при незначительном превышении частоты обращений nodelay не было, а при многократном превышении он, наоборот, был и помогал не доводить поисковых ботов до 503 ошибки.
Я сделал патч, который немного расширяет смысл параметра nodelay. Если нет nodelay или в конфиге просто указан nodelay без параметра, то всё работает по старому. Если же указать nodelay=N, то при excess меньшем, чем 1000*N, задержек нет, а как только excess перевалит это значение, задержки включаются. В моём случае достаточно использовать:
limit_req zone=IPRATELIMIT_EXT_GET burst=15 nodelay=1;
У меня не заржавеет каждый раз накладывать этот патч внутри, модуль меняется редко, но кажется, что такое может быть полезно не только мне.
С уважением,
Владислав Шабанов, GrinDin.ru <http://grindin.ru/>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160408/e3d2167c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ngx_http_limit_req_module.patch
Type: application/octet-stream
Size: 2069 bytes
Desc: not available
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160408/e3d2167c/attachment.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20160408/e3d2167c/attachment-0001.html>
More information about the nginx-devel
mailing list