| Привет! Если так письмо на русском не примете, я его, конечно, переведу на английский, но хотелось бы чуть-чуть времени сэкономить :) Итак, имеем сервер, на котором 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 |
ngx_http_limit_req_module.patch
Description: Binary data
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
