LINUX.ORG.RU

Ответ на: комментарий от int13h

Ну я как бы в курсе. Только вот в случае keep-alive-соебинения, соединения с IP адресом который превышает количество запросов в минуту остаётся висеть. А я бы хотел все эти соединения прибивать.

Viper ()
Ответ на: комментарий от int13h

Почему, что мешает ему закрыть соединение? Да и ничто не сможет соединения корректно закрыть кроме самого nginx или клиента.

Viper ()
Ответ на: комментарий от Viper

Ваш keep-alive timeout. Соединение завершится после окончания лимита последнего запроса. Соединение != запрос.

znenyegvkby ()
Ответ на: комментарий от znenyegvkby

Да я понимаю, только вот мне кажется логичным отключить от сервера тех, кто превышает лимит и не давать подключиться до тех пор, пока не появится возможность выполнить запрос исходя из лимитов. Но мне хотя бы первое. Но я понял, что в nginx это не сделать.

Viper ()
Ответ на: комментарий от Viper

Может как-то так

Example: Limit Connections Per Second
The following example will drop incoming connections if IP make more than 10 connection attempts to port 80 within 100 seconds (add rules to your iptables shell script)

#!/bin/bash
IPT=/sbin/iptables
# Max connection in seconds
SECONDS=100
# Max connections per IP
BLOCKCOUNT=10
# ....
# ..
# default action can be DROP or REJECT
DACTION="DROP"
$IPT -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --set
$IPT -A INPUT -p tcp --dport 80 -i eth0 -m state --state NEW -m recent --update --seconds ${SECONDS} --hitcount ${BLOCKCOUNT} -j ${DACTION}
# ....
# ..

http://www.cyberciti.biz/faq/iptables-connection-limits-howto/

int13h ★★★★★ ()
Последнее исправление: int13h (всего исправлений: 1)
Ответ на: комментарий от Viper

мне кажется логичным отключить от сервера тех, кто превышает лимит и не давать подключиться до тех пор, пока не появится возможность выполнить запрос исходя из лимитов

На ведь в этом и суть keep-alive. Уменьшаете затраты на установку нового соединения, и тем самым уменьшаете нагрузку на машину. А если keep-alive timeout больше интервала ограничения числа запросов на единицу времени, зачем закрывать соединение и снова открывать? По вашей логике вы будете каждый раз заново создавать соединение. По логике nginx соединение keep-alive вообще может работать неизвестное время в зависимости от активности клиента. Т.е. это N*m-ное кол-во сэкономленных ресурсов на установку N-соединений. Вы конечно можете их прибивать вручную через доп. слой, но в конечном счете вы только потеряете в производительности, но не выиграете.

znenyegvkby ()
Ответ на: комментарий от int13h

Тот тоже лимит соединений, а в одном соединении может быть множество запросов.
У меня всё сложнее, я блокирую через iptables совместно с ipset тех, кто злостно превышает лимиты по количеству запросов к контенту, nginx о таких пишет в лог. Вариант очевидный все пакеты проверять в ipset, но хотелось бы уменьшить количество проверок в ipset, для этого бы было достаточно проверять те пакеты которые имеют статус NEW, но возникает проблема, что по уже установленным соединениям могут продолжать насиловать сервер запросами.

Viper ()
Ответ на: комментарий от znenyegvkby

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

Viper ()
Ответ на: комментарий от Viper

Хм, тогда может быть проще и убивать эти соединения на уровне OS? То есть не воркеры, т.к. в вокреке хз сколько их, а сами соединения, утилитами типа tcpkill/killcx/cutter/etc, тем более что данные у вас все есть в логах. На уровне nginx, насколько мне известно, этого не сделать. По-крайней мере я не знаю, а plus версии у меня нет. М.б. в ней и есть такая возможность, но она противоречит логике keep-alive соединений, поэтому маловероятно.

znenyegvkby ()

а «return 444» не помогает ?

vel ★★★★★ ()
Ответ на: комментарий от vel

Похоже почти получается. Закрываются не все соединения, но то, на котором было превышение, похоже закрывается.

Viper ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.