ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Реализация multiple limit_req


  • To: nginx-ru@xxxxxxxxx
  • Subject: Re: Реализация multiple limit_req
  • From: Валентин Бартенев <ne@xxxxxxxx>
  • Date: Wed, 14 Dec 2011 21:58:55 +0400
  • Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=vbart.ru; s=mail; h=Content-Transfer-Encoding:Content-Type:Message-Id:MIME-Version:In-Reply-To:References:Date:Subject:To:From; bh=3HOigMbXRa0A444lxQwpSziLn+PbmW+LB57DH8197eI=; b=TtX2Qu5x10Wb4wB1E7UkC4/Wv51ocNsvyo5cesbeIFcIRrVJJJIIhIuD4mJfwIM7ah4IN9xXculWuetZnewT3D+fXLWnlt3R6cTJ8RZbb8cf+Xv2jPWNSTj+TnkOLXC3rjtDgRqPXNaXNtUuDgc6cqiX2k4wBRQyxf1NrVyi7DLQbEwKsZ1nMKO07pMH/gTo6eXVcqj4w3xmZz42XlPB5Q6nmyjhaO1YTgleYYnLQVRaCbIJE0f2trwzwPneDxxRqT6NABGqpcn3OoJWOuti/8vwMfTDC0fdWKN/bb5Wya8xq0zAjSeNYiHIJSbqr/pQiPYqptvjo/ZxP8MLFJXX4Q==;
  • In-reply-to: <20111214162424.GW67687@xxxxxxxxxx>
  • References: <201112141805.02107.ne@xxxxxxxx> <201112141939.19616.ne@xxxxxxxx> <20111214162424.GW67687@xxxxxxxxxx>

On Wednesday 14 December 2011 20:24:24 Maxim Dounin wrote:
> On Wed, Dec 14, 2011 at 07:39:19PM +0400, Валентин Бартенев wrote:
> > On Wednesday 14 December 2011 18:22:26 Maxim Dounin wrote:
> > > Давай для начала распишем последствия обычного "последовательного"
> > > применения лимитов, чтобы было понятно что так нельзя.  Или,
> > > наоборот, можно, но с какими ограничениями.
> > > 
> > > Что касается принципа, то он мне не нравится: нам либо нужно всё
> > > это делать держа локи (deadlock expected), либо имеем race между
> > > проверкой и обновлением (и, опять же, локи придётся брать два
> > > раза, что тоже не очень хорошо).
> > 
> > В limit_conn у нас также локи берутся дважды, и тут, на первый взгляд,
> > всё можно сделать по тому же принципу.
> 
> В limit_conn они второй раз берутся, когда мы откатываем лимиты -
> либо по завершению запроса, либо по наступанию на лимит.  И race'а
> там соответственно нет.
>

Тут мы тоже можем сделать "откат лимитов", которые не были применены.

Срабатывает лимит - сохраняем его delay и указатель на него, проверяем дальше, 
если находим лимит с большим delay, сохраняем новые значения и делаем откат 
лимита, за которым был установлен предыдущий delay.

Если находим лимит, который должен отклонить запрос - отклоняем запрос и делаем 
откат лимита за которым был установлен delay (если ранее такой был), прекращаем
дальнейшую проверку.

Я лишь говорю о принципиальной возможность реализовать по предложенной схеме.
В остальном - убедил. См. ниже.

[...]
> 
> Вот как раз в примере выше - подобное поведение вполне нормально,
> при условии правильного порядка лимитов.  Мы хотим пускать людей
> на сайт, пока не превышен лимит на этот сайт, и мы хотим отсекать
> людей с ^R, чтобы они вообще никому никаких проблем не доставляли.
> Т.е. конструкция
> 
>     limit_req <per-ip>;
>     limit_req <per-host>;
> 
> не должна никак считать в per-host лимит запросы, отклонённые на основании
> "ip-адресом не вышел".  И в то же время должна считать суммарный
> лимит для хоста, и отклонять при необходимости запросы за него
> выходящие.
> 

Озадачил, я думал-думал, но пока так и не смог придумать удачного контр-примера,
который бы не решался правильным порядком. Если так и не смогу придумать, то
сделаю последовательную проверку до первого срабатывания. Плюсы очевидны: 
проще, 
меньше локов и, соответственно, быстрее.

--
Валентин Бартенев
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://mailman.nginx.org/mailman/listinfo/nginx-ru


 




Copyright © Lexa Software, 1996-2009.