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